Live data from Hacker News

Racket v7.2

blog.racket-lang.org

71–77 of 77 posts

Re: Racket v7.2

#71

Earlier quoted context omitted.

Regarding s-expressions, there are some perfectly reasonable alternatives ( http://chriswarbo.net/blog/2017-08-29-s_expressions.html ) For example: https://docs.racket-lang.org/sweet/index.html https://www.draketo.de/proj/wisp/ Although I prefer to embrace the s-expressions :)

Yeah, but that's not Racket (technically, the first one is, but it overrides the reader; the second is a Python-based transpiler of some syntax into S-exps) - it won't help someone new to the language, if only because it adds yet another dependency and mental conversion to keep in mind when reading examples and such. They're there if you want them, though.

Wisp seems to override the reader too (so no transpiler needed) https://www.draketo.de/proj/wisp/src/94bae1032ef07e441a942c5...

I agree about the extra dependency and indirection; although the syntaxes (syntaxen?) are equivalent, so examples can be translated automatically if copy/pasted.

> They're there if you want them, though.

Yep, although as I wrote on my blog:

"Whilst the parenthesis-heavy format of s-expressions is not necessary, it usually crops up in anything discussing Lisp and its derivatives, simply because it's much more popular than these alternatives. To me, that mostly indicates that concerns about "too many parentheses" are really a non-issue, despite being made by many who are new to the format."

Re: Racket v7.2

#72
post #63

Earlier quoted context omitted.

> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain. Based on their most recent blog on the subject ( https://blog.racket-lang.org/2019/01/racket-on-chez-status.h... ), the new backend is almost uniformly s…

The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance). http:/…

It's here: https://pkgs.racket-lang.org/package/racket-langserver

Re: Racket v7.2

#73

Earlier quoted context omitted.

So, I am an experienced developer but new to Lisp based stuff, which seems to be what racket is based on. Can you suggest any books to learn racket. edit: Spelling

Seems like the most common answer to this might be SICP (Structure and Interpretation of Computer Programs -- you'll find course videos pretty easily from Google; the ones from the authors are really great). Note that it's based on Scheme, which is a ancestor of Racket, but Racket has a language pack that papers over the differences and works with the code from the book. Official course website: https://mitpress.mit.…

> SICP

Thank you for this. Time and again I have come across this book, but always assumed that it was something like The art of Programming series, so never even opened it.

Going through the online version now.

Re: Racket v7.2

#74

Earlier quoted context omitted.

Yeah, but that's not Racket (technically, the first one is, but it overrides the reader; the second is a Python-based transpiler of some syntax into S-exps) - it won't help someone new to the language, if only because it adds yet another dependency and mental conversion to keep in mind when reading examples and such. They're there if you want them, though.

Wisp seems to override the reader too (so no transpiler needed) https://www.draketo.de/proj/wisp/src/94bae1032ef07e441a942c5... I agree about the extra dependency and indirection; although the syntaxes (syntaxen?) are equivalent, so examples can be translated automatically if copy/pasted. > They're there if you want them, though. Yep, although as I wrote on my blog: "Whilst the parenthesis-heavy format of s-expressio…

Very well said, and a good post, BTW. I have something similar, from when I started working with Clojure: https://klibert.pl/posts/tools_for_lisp_syntax.html

Re: Racket v7.2

#75
post #63

Earlier quoted context omitted.

> and c) has the audacity (combined, curiously, with humility) to just swap out the entire backend to eek out more performance Unfortunately they are not doing it for performance reasons. They are doing it solely to make the code base cleaner and easier to maintain. Based on their most recent blog on the subject ( https://blog.racket-lang.org/2019/01/racket-on-chez-status.h... ), the new backend is almost uniformly s…

The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance). http:/…

    The new backed is overall faster according to that post.
No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I’m talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to code compiled using the new back-end?)

I grant that there is some benefit in that the longer compile times result in an improvement in some benchmarks, but that doesn’t negate that the new back-end is still slower than the old one by every measure.

> Racket is much faster than python or PHP.

This is funny because although you will find benchmarks out there to support this point, in my experience of writing and using Racket programs it has never hold up. Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.

I love the Racket language, and there are some DSLs like Pollen that do things I simply can’t imagine attempting anywhere else. But it’s for sure my last choice for speed, based on personal experience.

Re: Racket v7.2

#76
post #63

Earlier quoted context omitted.

The new backed is overall faster according to that post. In addition, looking at raw Chez, the results are even more one-sided. Chez is always faster and often 2-8x faster. New racket is usually faster and where it isn't is mostly due to new IO. Sure, compile times get bigger -- Chez is doing way more optimization passes than Racket (Chez is the only scheme I know of that can get close to SBCL in performance). http:/…

The new backed is overall faster according to that post. No, according to that post, the new back-end itself is massively slower than current Racket by every single measure shown. To reiterate, I’m talking about startup and load times, memory use, expand and compile times, and build times (i.e. time to compile the back-end itself). All slower. (Are you sure you're not referring to code compiled using the new back-end…

> Most recent example: I participated in Advent of Code this year, and there was almost never a Racket solution posted that wasn't ten times slower (and in my opinion harder to read) than the simple & idiomatic Python solution.

Can you point me to some examples of this? I haven't done AoC and so don't know where to find solutions posted to compare. It should be very rare for idiomatic python or php to be faster than idiomatic racket.

Re: Racket v7.2

#77

I’ve used Racket in the past. Personally, I’d still never use it for production because the learning curve is fairly steep AND as this post highlights - there are still bugs being worked out in basic features like “set”. However, overall I like the language. So, overtime I think it’ll have its day in the sun.

> there are still bugs being worked out in basic features like “set”. You are misreading the release notes. What was fixed is a Redex model (a tool used in semantics to model computer languages). A change to the modeling of `set!` (assignment) was made. It has no impact on Racket itself.

There was indeed a bug fix to the actual Racket implementation, but in extremely hard-to-find corner cases, which was why it was only found via model-driven random testing.
Post reply on HN