It’s a useful question but making it sound like you’re blaming the person involved doesn’t really help anyone. A bit of sympathy for someone’s lost work might make people more willing to think about your message.
Also, I’ve had Firefox recover stuff I’ve typed into a web form after a power outage killed it mid-keystroke, and I’ve had vim fuck up state in its recovery files. An email client is just as capable of going poof if it doesn’t Do It Right.
It’s a useful question but making it sound like you’re blaming the person involved doesn’t really help anyone. A bit of sympathy for someone’s lost work might make people more willing to think about your message.
maybe, but it’s also more work to read through pleasantries rather than something more to the point.
Also, I’ve had Firefox recover stuff I’ve typed into a web form after a power outage killed it mid-keystroke, and I’ve had vim fuck up state in its recovery files. An email client is just as capable of going poof if it doesn’t Do It Right.
unpredictable things can happen in any context yes, but the relevant question here is would he have been just as likely to lose the work if he was typing in an email client?
Github started refusing to accept emails from me in reply to comment threads a little while ago, so the email client isn’t an option for me personally.
I had already moved most of my projects off there, but that was the thing that got me to move the rest off.
Sadly I can’t do anything about other peoples’ projects.
that makes sense, and it’s interesting that they had an email gateway before and then closed it down. in the case of @river it was about one of their own libraries, so they would have a different answer.
I like Racket, and coincidently wrote about it in my blog post this week which got to the front page of HN, so those are my biases. With that being said, I think a lot of the criticisms around Racket are valid. It is definitely still stuck in its pedagogical and academic roots. I mean both the Racket Reference and the Racket Guide both have a section devoted to notation. While learning the notation is super helpful, and makes reading and understanding the libraries much easier, most people would rather just see a few practical examples of each function and move on.
It pains me to say this but, if you are going to write code for a business or production use case you should just use Go, Java, C++, Python, Javascript, C#, or Swift. You’ll avoid the issues of having to constantly yak shave missing libraries to even start a project and avoid hiring issues. Unfortunately, this means that getting a new language to achieve critical mass is quite difficult if you’re only focused is on getting hired or hiring. It might just be that the only way to get any reasonable adoption of a new language in 2023 is to leverage existing tools like Zig did with LLVM, Kotlin with the JVM or F# with Dotnet. Is this a bad thing? Who knows?
While some of the issues Winny brought up are fixable (like creating an RFC process), some of these aren’t really possible to fix. The large executable size for example because Racket has to pack the whole VM with the binary. As someone who comes from the Python world this has never bothered me as I actually appreciate the fact that Racket has a way of producing an executable natively without third party tools, but I can see why this is an issue. Also Racket is slower to start up then Python or other scripting languages, largely due to having to compile all the macros and start up the VM.
With all this being said I believe Racket is still the most production of all the Schemes, just not for all use cases. SBCL and more than likely Clojure are better bets if you still want to stay in lisp land, or Hy if you want a lispy Python. Other Interesting Schemes too look at are…
Chez
Gerbil
I think Gerbil could potentially become a better Racket as it borrows a lot of what makes Racket good. Chez benefits a lot from the fact that Racket builds upon it, so it gets contributions from the Racket core team (You can also use the patched version of Chez scheme when you download Racket!). Chez scheme also benefits from a really slick core and having been developed by Kent Dybvig. I still like Racket all things considered, and I think it has other benefits as well, I.E the Pollen Language, The Rash Shell but I definitely see where this poster is coming from
I’ve been working with Clojure for over a decade and I have to say, the concerns about hiring are completely overblown. It always takes much less time for new hires to learn the language than it does for them to actually learn the ins and outs of our system.
Granted Racket isn’t Clojure, and part of the reason it’s easier to get up to speed on Clojure is that people often have familiar with the JVM vs learning a new runtime, but I think “you should just use Go, Java, C++, Python, Javascript, C#, or Swift” is not the right conclusion to draw from “hiring issues” concerns.
While Chez is a wonderful piece of engineering, I don’t know that it has much of a community around it. If you want something production ready you will need libraries and lots of them. Of course I am biased but I think the CHICKEN community is one of the nicest out there, and we have lots of libraries. Guile is probably a good bet in that regard, as well.
Agree that Chicken is top tier for libraries. I’ve also heard good things about Chez and Gambit, though haven’t played with them much for real.
Rambling a little off topic… do you have any feel for Guile lately in terms of quality and community? I have a narrative in my head that for the longest time it was very much not a particularly good/useful language, being more or less a GNU-endorsed perl-wannabe, but at some point in the second half of the 2010’s it got a new maintainer who was a lot more enthusiastic and knowledgeable about PL design and has gotten much better since then. But I just realized that most of this narrative comes from one friend I am no longer in contact with and I’m too lazy to track down details myself, all I really remember is looking at it Back In The day and saying “it’s not even R5RS compliant? git gud”.
I started using Guile back in 2012, and at that point it had recently gained a compiler and VM in addition to an interpreter. It was pretty OK but I came across it while looking for a Scheme I could embed into a C program, which was the dominant use-case for Guile at the time. Since then, there’s been significant work on the compiler, most notably the switch to a continuation passing style IL and a set of optimization passes for it, that has made performance pretty competitive with other Scheme implementations. Now people prefer to write entire programs in Guile, such as the Guix package manager and distro, and use the FFI when they need something from C land. Guile itself is slowly rewriting parts of its runtime in Scheme and reducing its C footprint. There’s also a JIT compiler, delimited continuations, atomic operations, non-blocking I/O, and other nice modern things. R5RS support is great, and you can also use R6RS and R7RS but they aren’t complete yet AFAIK. A WASM compiler backend is currently in development (initially targeting R7RS small but will eventually support all of Guile), as is a new garbage collector. Andy Wingo’s extensive professional career working on the V8 and SpiderMonkey JS implementations has driven pretty much all of these technical improvements while the success of Guix has driven community growth and library availability (which isn’t as good as Chicken or Racket but is getting a lot better.) Hope this helps provide some context!
This is consistent with my understanding; Guile 1.x had a reputation for being very amateurish and was only used because of its GNU status. When Andy Wingo took over the project, he put a ton of effort into making it a respectable implementation with a bytecode VM and JIT. His blog contains some excellent explanations of complex technical topics made approachable.
On the other hand, for me the main reason I haven’t used Guile is that it’s a GNU project, so political reasons rather than technical ones.
Thanks for the extensive comment. I personally don’t know enough about Guile to comment. I only use it sporadically when a Gnucash upgrade breaks my custom reports :)
I’ve loved Racket as a teaching language for my introduction to functional programming course but I’ve noticed very little production code out there. I’ve never promoted it as a “career” language but I do wonder if I’ll find something else that supplants it that is more practical while still being a great language to teach and learn with.
I have no real opinion on this but think it’s an informative take.
winny asked me a question on one of my racket libraries
I spent about 2 hours writing a very long reply in the github box and something happened and I lost it
just ended up not responding.
why were you typing into a shitty website that can go poof rather than an email client?
https://www.youtube.com/watch?v=PRGszw0KubQ
don’t take it so personally. it’s actually a valuable question for people to think about, but nobody wants to.
It’s a useful question but making it sound like you’re blaming the person involved doesn’t really help anyone. A bit of sympathy for someone’s lost work might make people more willing to think about your message.
Also, I’ve had Firefox recover stuff I’ve typed into a web form after a power outage killed it mid-keystroke, and I’ve had vim fuck up state in its recovery files. An email client is just as capable of going poof if it doesn’t Do It Right.
maybe, but it’s also more work to read through pleasantries rather than something more to the point.
unpredictable things can happen in any context yes, but the relevant question here is would he have been just as likely to lose the work if he was typing in an email client?
It might be more work, but it might also make people people bother listening to you.
I don’t know, I thought I was pretty polite in the latter half of my last comment
Github started refusing to accept emails from me in reply to comment threads a little while ago, so the email client isn’t an option for me personally.
I had already moved most of my projects off there, but that was the thing that got me to move the rest off.
Sadly I can’t do anything about other peoples’ projects.
that makes sense, and it’s interesting that they had an email gateway before and then closed it down. in the case of @river it was about one of their own libraries, so they would have a different answer.
I like Racket, and coincidently wrote about it in my blog post this week which got to the front page of HN, so those are my biases. With that being said, I think a lot of the criticisms around Racket are valid. It is definitely still stuck in its pedagogical and academic roots. I mean both the Racket Reference and the Racket Guide both have a section devoted to notation. While learning the notation is super helpful, and makes reading and understanding the libraries much easier, most people would rather just see a few practical examples of each function and move on.
It pains me to say this but, if you are going to write code for a business or production use case you should just use Go, Java, C++, Python, Javascript, C#, or Swift. You’ll avoid the issues of having to constantly yak shave missing libraries to even start a project and avoid hiring issues. Unfortunately, this means that getting a new language to achieve critical mass is quite difficult if you’re only focused is on getting hired or hiring. It might just be that the only way to get any reasonable adoption of a new language in 2023 is to leverage existing tools like Zig did with LLVM, Kotlin with the JVM or F# with Dotnet. Is this a bad thing? Who knows?
While some of the issues Winny brought up are fixable (like creating an RFC process), some of these aren’t really possible to fix. The large executable size for example because Racket has to pack the whole VM with the binary. As someone who comes from the Python world this has never bothered me as I actually appreciate the fact that Racket has a way of producing an executable natively without third party tools, but I can see why this is an issue. Also Racket is slower to start up then Python or other scripting languages, largely due to having to compile all the macros and start up the VM.
With all this being said I believe Racket is still the most production of all the Schemes, just not for all use cases. SBCL and more than likely Clojure are better bets if you still want to stay in lisp land, or Hy if you want a lispy Python. Other Interesting Schemes too look at are…
I think Gerbil could potentially become a better Racket as it borrows a lot of what makes Racket good. Chez benefits a lot from the fact that Racket builds upon it, so it gets contributions from the Racket core team (You can also use the patched version of Chez scheme when you download Racket!). Chez scheme also benefits from a really slick core and having been developed by Kent Dybvig. I still like Racket all things considered, and I think it has other benefits as well, I.E the Pollen Language, The Rash Shell but I definitely see where this poster is coming from
I’ve been working with Clojure for over a decade and I have to say, the concerns about hiring are completely overblown. It always takes much less time for new hires to learn the language than it does for them to actually learn the ins and outs of our system.
Granted Racket isn’t Clojure, and part of the reason it’s easier to get up to speed on Clojure is that people often have familiar with the JVM vs learning a new runtime, but I think “you should just use Go, Java, C++, Python, Javascript, C#, or Swift” is not the right conclusion to draw from “hiring issues” concerns.
While Chez is a wonderful piece of engineering, I don’t know that it has much of a community around it. If you want something production ready you will need libraries and lots of them. Of course I am biased but I think the CHICKEN community is one of the nicest out there, and we have lots of libraries. Guile is probably a good bet in that regard, as well.
Agree that Chicken is top tier for libraries. I’ve also heard good things about Chez and Gambit, though haven’t played with them much for real.
Rambling a little off topic… do you have any feel for Guile lately in terms of quality and community? I have a narrative in my head that for the longest time it was very much not a particularly good/useful language, being more or less a GNU-endorsed perl-wannabe, but at some point in the second half of the 2010’s it got a new maintainer who was a lot more enthusiastic and knowledgeable about PL design and has gotten much better since then. But I just realized that most of this narrative comes from one friend I am no longer in contact with and I’m too lazy to track down details myself, all I really remember is looking at it Back In The day and saying “it’s not even R5RS compliant? git gud”.
I started using Guile back in 2012, and at that point it had recently gained a compiler and VM in addition to an interpreter. It was pretty OK but I came across it while looking for a Scheme I could embed into a C program, which was the dominant use-case for Guile at the time. Since then, there’s been significant work on the compiler, most notably the switch to a continuation passing style IL and a set of optimization passes for it, that has made performance pretty competitive with other Scheme implementations. Now people prefer to write entire programs in Guile, such as the Guix package manager and distro, and use the FFI when they need something from C land. Guile itself is slowly rewriting parts of its runtime in Scheme and reducing its C footprint. There’s also a JIT compiler, delimited continuations, atomic operations, non-blocking I/O, and other nice modern things. R5RS support is great, and you can also use R6RS and R7RS but they aren’t complete yet AFAIK. A WASM compiler backend is currently in development (initially targeting R7RS small but will eventually support all of Guile), as is a new garbage collector. Andy Wingo’s extensive professional career working on the V8 and SpiderMonkey JS implementations has driven pretty much all of these technical improvements while the success of Guix has driven community growth and library availability (which isn’t as good as Chicken or Racket but is getting a lot better.) Hope this helps provide some context!
This is consistent with my understanding; Guile 1.x had a reputation for being very amateurish and was only used because of its GNU status. When Andy Wingo took over the project, he put a ton of effort into making it a respectable implementation with a bytecode VM and JIT. His blog contains some excellent explanations of complex technical topics made approachable.
On the other hand, for me the main reason I haven’t used Guile is that it’s a GNU project, so political reasons rather than technical ones.
GNU is less and less anything like “one thing” and Guile and Guix are in one of the most reasonable corners.
On the one hand, I have great respect for Andy and Ludo.
On the other hand, Guile and Guix use autotools.
Thanks for the extensive comment. I personally don’t know enough about Guile to comment. I only use it sporadically when a Gnucash upgrade breaks my custom reports :)
Wow it does. Thank you for the info!
I’ve loved Racket as a teaching language for my introduction to functional programming course but I’ve noticed very little production code out there. I’ve never promoted it as a “career” language but I do wonder if I’ll find something else that supplants it that is more practical while still being a great language to teach and learn with.
I still want to learn racket for an Advent of Code but more as an exercise and not to ship anything real with.
One of the big problems with the scheme world is portability
it’s too difficult to write code that can run unmodified on multiple scheme implementations. and it does not need to be.