Post Aad9fbYlAgXHNofce0 by Ardubal@mastodon.xyz
(DIR) More posts by Ardubal@mastodon.xyz
(DIR) Post #AabVbAlSf8T1nRz1Iu by dekkzz76@emacs.ch
2023-10-09T19:04:49Z
0 likes, 0 repeats
@louis read this?https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang
(DIR) Post #AabVbBWFr9ti8ZsOEy by louis@emacs.ch
2023-10-09T19:56:40Z
0 likes, 0 repeats
@dekkzz76 Thanks for sharing this article. It is a very good read. I think there is not much to add, the author is right. We "like" Go because it gives us the power to do things the fast and easy way, postponing complexity to some other time.I've spent almost the whole last week to migrate a project from Go to Common Lisp. Needless to say that it was not only a huge fun, but also quite surprising how good the result is. Not only in terms of performance but also in expressiveness of the resulting code, and I don't consider myself anything more than an intermediate.To never have to compile, try, and debug the whole program from state 0, but building block by block and staying in a live image during the whole time was an eye-opener.Also, Common Lisp gives you a lot of choices. Which might be one of the pain points for devs (like me) coming from very opinionated languages. As a die-hard advocate of static typing, experiencing how I can build anything more complex than a simple script without having to deal with types (almost) at all puts a new perspective on the importance of static typing. Especially when you have to deal with external dynamic data sources (JSON, SQL) (i.e. json.Unmarshal doesn't tell me when the source is missing or adding fields, it just complains when types do not fit).Unlike the author I'm not a language expert, but from what I can say now after my last week's effort is that I'm a bit more sceptical when it comes to the infallibility of Go as the best choice for server-side project.Having said all that, I still "like" Go but wish that I've had seen the light a bit earlier.#CommonLisp
(DIR) Post #AabYFz9AxcnFXxfEsi by louis@emacs.ch
2023-10-09T20:26:29Z
0 likes, 0 repeats
@dekkzz76 Adding some more notes: the project I've migrated from Go to Common Lisp resulted in 50% less code (not using any macros!).Also, since I've developed it entirely in LispWorks, I did some tests with other implementations and it worked in SBCL and ECL out of the box (CLISP didn't work because bordeaux-threads doesn't support it).Here are the runtimes:SBCL:Evaluation took: 9.755 seconds of real time 1.033166 seconds of total run time (0.968865 user, 0.064301 system) [ Real times consist of 0.019 seconds GC time, and 9.736 seconds non-GC time. ] [ Run times consist of 0.019 seconds GC time, and 1.015 seconds non-GC time. ] 10.59% CPU 144 lambdas converted 1 page fault 100,349,712 bytes consedECL:real time : 83.908 secsrun time : 29.092 secsgc count : 4 timesconsed : 662005840 bytes(sort of disappointing)LispWorks:User time = 2.220System time = 0.118Elapsed time = 9.028Allocation = 60406728 bytes1620 Page faultsGC time = 0.009It seems LispWorks is the clear winner.#LispWorks #ECL #SBCL #CommonLisp
(DIR) Post #Aabd1DUJrHcfS4Ka4O by dekkzz76@emacs.ch
2023-10-09T21:14:31Z
0 likes, 0 repeats
@louis everything is just a tool, every tool has pros & consi spent 6 months as a business programmer on smalltalk where we never compiled either, code > test > code etc etc. it's why i hate compiling
(DIR) Post #Aabd1ECzBDLrgbEFgu by louis@emacs.ch
2023-10-09T21:18:41Z
0 likes, 0 repeats
@dekkzz76 Which Smalltalk did you use? I've signed up for a Pharo course in November by Inria. I played a bit with Pharo a while ago but performance was really not so good. However I think it is a great dev environment.
(DIR) Post #AabdhCir5wuJEw9Rc8 by bionicbabelfish@emacs.ch
2023-10-09T21:25:36Z
0 likes, 0 repeats
@louis @dekkzz76 the ECL numbers are surprising… any idea what would be going on there?
(DIR) Post #Aabe8qCWQHTLV0CpBA by louis@emacs.ch
2023-10-09T21:32:03Z
0 likes, 0 repeats
@bionicbabelfish @dekkzz76 I never really use ECL, so I don't know how to find out except running the package :) Also, I've tried to compile the package to a binary (asdf:make-build...) but always got the following error:Unable to create pipeC library explanation: Too many open files.
(DIR) Post #Aac1NcEavkGTTKBoFE by phenlix@mastodon.online
2023-10-10T01:52:52Z
0 likes, 0 repeats
@louis @dekkzz76 What version of Clisp did you use ? Bordeaux-threads most definitely supports it.
(DIR) Post #Aad5uNj4UGuB0QHgAK by louis@emacs.ch
2023-10-10T14:18:19Z
0 likes, 0 repeats
@phenlix @dekkzz76 Welcome to GNU CLISP 2.49.92 (2018-02-18)[1]> (ql:quickload 'bordeaux-threads)*** - Error while trying to load definition for system bordeaux-threads from pathname /Users/louis/quicklisp/dists/ultralisp/software/sionescu-bordeaux-threads-20230921222339/bordeaux-threads.asd: This implementation is unsupported.
(DIR) Post #Aad6a2xE6e08kJlxL6 by galdor@emacs.ch
2023-10-10T14:25:51Z
0 likes, 0 repeats
@louis @phenlix @dekkzz76 You need CLisp compiled with --with-threads. Which has the nice "highly experimental - use at your own risk" warning…No real point in using CLisp though.
(DIR) Post #Aad9fbYlAgXHNofce0 by Ardubal@mastodon.xyz
2023-10-10T15:00:28Z
0 likes, 0 repeats
@louis @dekkzz76 This looks as if it included compilation time or something like that. The differences are much too big, unless you do something special.