The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.
> To address larger problems with the implementation and to improve performance, we started in 2017 rebuilding Racket on top of Chez Scheme. Rebuilding took some time, and we only gradually deprecated the old “BC” implementation in favor of the new “CS” implementation, but the transition is now complete. Racket BC is still maintained, but as of August 2025, we distribute only Racket CS builds
So they're billing Racket as "Mature Practical Extensible Robust and Polished". Of those I will give them "Extensible" and "Robust". You can't say you're mature and polished and practical if you've just rewritten the entire thing and deprecated the legacy codebase to support new features that have been in other languages since forever.
Maybe they were talking about Racket 8.0 and didn't change the website yet?
How rewriting something internally makes Racket not mature? Sounds like refactoring to me and with an extensive test suite there's nothing to be hysterical about.
Maybe I just have a different working definition of these words. To me "mature" means "fully developed" and "polished" means "achieved a high level of refinement". To me, rewriting it all to introduce a major feature that fills in a longstanding hole in the language doesn't say "mature and polished". Because often times many bugs are introduced into a codebase on a major rewrite despite extensive test suites, especially at the interfaces between features. Typically people might prefer a mature codebase to one that's just been rewritten precisely because it hasn't been vetted over years. "mature rewrite" sounds like an oxymoron to me, and I guess no one else agrees but I find it strange. That is all.
I think they don't always communicate well with industry practitioners, and your reactions are great evidence of that.
Racket is lead by professors, and (as is sometimes the case in systems research) some of them are very highly skilled software developers, well above HN average. But they have not been working in industry, and some have never worked in industry, so they don't always know what notes to hit, and they don't always know current subtleties of practice.
My best example of this is when someone kept saying the platform was "batteries included". My reaction was, my god, no, please don't say that: the first time the wrong person sees that, invests time with that expectation, and finds all the ways that is absolutely not true by industry convention, they will rip the ecosystem a new one.
Set expectations properly, and you attract the right people, who will love it, and they will also disproportionately be great programmers.
That said, the software engineering quality situation is much better than the impression you seem to have. They've done a very solid job of rehosting Racket internals, and of generally maintaining backward-compatibility over the years. Much better than Python, for example. (Also, Racket docs are usually much better than most ecosystems I have used in recent years.)
Fears about refactoring introducing bugs are fine and valid - but after eight years, haven't really happened. Seems the extensive test suite did its job.
This isn't a case of Python 2 v 3. Packages weren't broken en masse. The API remained stable.
If anything, the rewrite has proved that it is mature. Because they could perform a refactor without breaking everyone's everyday.
I first experimented with Lisp back in the mid-80’s, and have returned to it time and again—not as a language for serious projects, but just as a way of learning new techniques and new ways to think about writing software. I’ve tried using Racket on a number of occasions going back to way before it was called that, and something about the software just puts me off. Perhaps I could get past that if I stuck with it, but I just can’t see myself writing a large project using Racket.
I've wanted to try racket a few times but always found the "IDE" to be really unintuitive, clunky and weird. What gives? Is that by design or is it just that nothing better has been created so far?
The Racket Langserver obviously enables use in other editors that support the LSP. https://github.com/jeapostrophe/racket-langserver For editors that lack LSP support, scheme support is generally sufficient.
All that aside, DrRacket the IDE has some nice features that just don't exist in other editors. I don't know of another IDE that has an integrated macro stepper.
I've often heard this, but I don't really know of many people in the PL dev community who build their language in Racket. Also, I've taught a PL course and I tried to use Racket as a component, but students mostly just struggled with the LISP-y ness of it all, as they were primarily used to Java and Python. In all, I'm not really sure who Racket is for.
I suppose, Racket is for CS grads / post-grads / researchers / professors. That is, not for those who just learn CS basics, but for those learnèd enough.
Students might use some simplified or customized languages produced with Racket. The syntax needs not be lispy; #lang algol60 is built in :)
it was only using ChezScheme as an optimizing compiler backend.
(i created a PR to refactor their build system to reify the bootstrap process all the way down from GHC. it basically generalized the normal build workflow of Idris2 to be able to animate the entire bootstrap chain from GHC. sadly, it was pretty much ignored, and later abandoned: https://github.com/idris-lang/Idris2/pull/1990)
>> Can Idris 2 compile itself?
> Yes, Idris 2 is implemented in Idris 2. By default, it targets Chez Scheme,
> so you can bootstrap from the generated Scheme code, as described in Section
> Getting Started.
in this case the generated scheme code is just a strange form of executable file that happens to need ChezScheme to be executed.
i.e. an ELF64 idris2 linux binary vs. an idris2.scm file that needs ChezScheme to come alive.
as for Idris2 implemented in Idris2: well, yes, that's true for the current version of Idris2. but the first version of Idris2 was written in Idris1. and the first version of Idris1 was written in Haskell.
Racket is a fun language. My university uses the bundled teaching languages for first year CS courses. Some people really hate it, and others silently like it.
Might have been Waterloo's Introduction to Functional Programming (CS 135). I have TA'd (technically ISA'd) that course several times and helped countless students in office hours. The struggling students didn't just hate Racket, they hated the whole HTDP philosophy of following a "design recipe" and writing documentation prior to implementing a function. Most of those struggling students essentially waited till the last minute to do the documentation, completely flouting the intention of the course.
I don't know if the strong students had the intended approach since they were never in office hours asking for help!
I admit I'm one of those students who never used Racket in a non-academic setting (but mostly because I needed to contribute to already-existing projects written in different languages), and I was taught Racket from one of its main contributors, John Clements at Cal Poly San Luis Obispo. However, learning Racket planted a seed in me that would later grow into a love of programming languages beyond industry-standard imperative ones.
I took a two-quarter series of classes from John Clements: the first was a course on programming language interpreters, and the second was a compilers course. The first course was taught entirely in Racket (then called DrScheme). As a guy who loved C and wanted to be the next Dennis Ritchie, I remember hating Racket at first, with all of its parentheses and feeling restricted by immutability and needing to express repetition using recursion. However, we gradually worked our way toward building a Scheme meta-circular evaluator. The second course was language-agnostic. Our first assignment was to write an interpreter for a subset of Scheme. We were allowed to use any language. I was tired of Racket and wanted to code in a much more familiar language: C++. Surely this was a sign of relief, right?
It turned out that C++ was a terrible choice for the job. I ended up writing a complex inheritance hierarchy of expression types, which could have easily been implemented using Racket's pattern matching capabilities. Additionally, C++ requires manual memory management, and this was before the C++11 standard with its introduction of smart pointers. Finally, I learned how functional programming paradigms make testing so much easier, compared to using object-oriented unit testing frameworks and dealing with mutable objects. I managed to get the project done and working in C++, but only after a grueling 40 hours.
I never complained about Racket after that.
In graduate school, I was taught Scala and Haskell from Cormac Flanagan, who also contributed to Racket. Sometime after graduate school, I got bit by the Smalltalk and Lisp bugs hard....now I do a little bit of research on programming languages when I'm not busy teaching classes as a community college professor. I find Futamura projections quite fascinating.
I'm glad I was taught programming languages from John Clements and Cormac Flanagan. They planted seeds that later bloomed into a love for programming languages.
that's an often repeated misconception about lisps.
lisps are pretty good at low-level programming, but then you'll need to make some compromises like abandoning the reliance on the GC and managing memory manually (which is still a lot easier than in other languages due to the metaprogramming capabilities).
there are lisps that can compile themselves to machine code in 2-4000 LoC altogether (i.e. compiler and assembler included; https://github.com/attila-lendvai/maru).
i'm not saying that there are lisp-based solutions that are ready for use in the industry. what i'm saying is that the lisp langauge is not at all an obstacle for memory-limited and/or real-time programs. it's just that few people use them, especially in those fields.
and there are interesting experiments for direct compilation, too:
BIT: A Very Compact #Scheme System for #Microcontrollers (#lisp #embedded)
http://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05....
"We demonstrate that with this system it is clearly possible to run realistic Scheme programs on a microcontroller with as little as 3 to 4 KB of RAM. Programs that access the whole Scheme library require only 13 KB of ROM."
"Many of the techniques [...] are part of the Scheme and Lisp implementation folklore. [...] We cite relevant previous work for the less well known implementation techniques."
Everyone gets to choose which language they use for their personal projects.
Where are all the Racket personal projects?
N.B. I say this as someone who personally contributed small fixes to Racket in the 90s (when it was called mzscheme) and 00s (when it was called PLT-Scheme).
I view Racket as an academic language used as a vehicle for education and for research. I think Racket does fine in its niche, but Racket has a lot of compelling competitors, especially for researchers and professional software engineers. Those who want a smaller Scheme can choose between plenty of implementations, and those who want a larger language can choose Common Lisp. For those who don't mind syntax different from S-expressions, there's Haskell and OCaml. Those who want access to the Java or .NET ecosystems could use Scala, Clojure, or F#.
There's nothing wrong with an academic/research language like Racket, Oberon, and Standard ML.
Delimited continuations as a programming construct were somewhat of interest when I learned about them, but not even my university discussed them.
I don't think I ever had a colleague that even ever heard of the concept, let alone applied it. Of the "smart people", they typically only have heard of plain continuations, if you are lucky.
The debugger in Racket was useful when I used it years ago.
Unfortunately, it's kind of difficult to beat an entire planet cranking out libraries in other languages as many interesting programs are written for an ecosystem; if 90% of your project is building FFIs to make something work, perhaps you can better just choose the language of fools dun jour.
I don't think Scheme is the most academic language, today. Such honor would go to a language supporting a computable version of homotopy types, which I would guess only 1000 people in the world would be capable of using assuming production grade implementations (of which none exist).
Delimited continuations are quite similar to effect systems that seem to be getting a lot of interest lately. So who knows, maybe they will become more mainstream in the future.
back in the day when we wrote enterprise bullshit in common lisp (!), we had put together a proof of concept where we used delimited continuations to write business processes.
business processes were written in basically full common lisp with very few limitations, and with a few extra primitives to use (and 10x slower due to being interpreted, but that didn't matter at all). when a process reached a point where it was waiting for some external event (e.g. displaying a GUI for a user and waiting for their feedback, or sleeping until a deadline), then it got serialized into the (SQL) database.
it was pretty cool! when a user logged in, there was a list of processes waiting for him that he could click to see and interact with. all this with the transactional guarantees of the sql backend because the business objects were also stored in the same database.
https://github.com/hu-dwim/hu.dwim.delico was the continuation lib, hu.dwim.perec was the object relational mapper, and hu.dwim.serializer was used to turn CL objects into SQL blobs (with some properties extracted as reified SQL schema elements to be able to search for the suspended processes).
I used it to write a macro processor for C which allowed me to write some macros with s-expressions and have it expand to a lot of C code. That way I could actually write real macros for C.
I have also written GUI apps for various things. Kind of like what I did with TCL back in the day.
I wrote a little maths game for my son.
I also wrote a static site generator in it that allowed me to execute racket code at compile time (interpreting each markdown file as a source file).
It's a general purpouse language. Reusig an old comment, I used it for
* A bot to reply emails that uses IMAP, SMTP and web scrapping. (It's not 100% automatic. It replies only the easy cases and adds labels so I reply the tricky ones.)
* An program to cleanup Moodle backups that uses gzip and xml. I compiled it and send it to my coworkers. (The backups have too much info, so before restoring it in another site it's better to remove the unused parts.)
I wrote custom language for designing Age of Empires 2 Random Maps. Basically AoE2 already supports it, but the underlying language is very very primitive. While I am not aware of anyone actually using what I made, it was mostly nice learning experience. https://github.com/Erbenos/aoe2-rms
Because its on top of Racket, you get usual high-level language faculties for basically free.
As the other reply said, it is general purpose. It has a focus on education tooling, and language design (languages can be easily implemented on Racket)
I think SBCL has better support for annotations. You can claim that a variable is an int and the compiler will thrust you and generante fast code.
You can use Typed Racket to add annotations. The compiler will verify your that your claims are consistent and perhaps add some runtime checks when you read data or use other external sources. It will remove most of the internal checks, but not all of them.
(Probably some features of Racket like impersonators make generating fast code faster, but on the other hand allows Typed Racket and other variants/libraries to ensure external objects behave correctly.)
Disclaimer: I use "Plain" Racket, so both descriptions may be slightly wrong.
The education tooling is all optional (so their only impact is perceptual) DrRacket, teaching languages, and supporting libraries are all optional. (see Minimal Racket - just the compiler and package manager https://download.racket-lang.org/releases/9.0/#:~:text=SHA25... )
I'd like to know what tooling is missing from Racket that is available in major general purpose languages like C#, Java, or Common Lisp implementations?
The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.
I feel like version 9 just getting parallel threads kind of contradicts the homepage when it says Racket is "Mature" and "Polished".
It's not at all strange, Python and OCaml are mature and polished and they still have tackled the same issue very recently.
This is addressed in the blog post linked from the release announcement: https://blog.racket-lang.org/2025/11/parallel-threads.html
That post is even more worrisome!
> To address larger problems with the implementation and to improve performance, we started in 2017 rebuilding Racket on top of Chez Scheme. Rebuilding took some time, and we only gradually deprecated the old “BC” implementation in favor of the new “CS” implementation, but the transition is now complete. Racket BC is still maintained, but as of August 2025, we distribute only Racket CS builds
So they're billing Racket as "Mature Practical Extensible Robust and Polished". Of those I will give them "Extensible" and "Robust". You can't say you're mature and polished and practical if you've just rewritten the entire thing and deprecated the legacy codebase to support new features that have been in other languages since forever.
Maybe they were talking about Racket 8.0 and didn't change the website yet?
How rewriting something internally makes Racket not mature? Sounds like refactoring to me and with an extensive test suite there's nothing to be hysterical about.
Maybe I just have a different working definition of these words. To me "mature" means "fully developed" and "polished" means "achieved a high level of refinement". To me, rewriting it all to introduce a major feature that fills in a longstanding hole in the language doesn't say "mature and polished". Because often times many bugs are introduced into a codebase on a major rewrite despite extensive test suites, especially at the interfaces between features. Typically people might prefer a mature codebase to one that's just been rewritten precisely because it hasn't been vetted over years. "mature rewrite" sounds like an oxymoron to me, and I guess no one else agrees but I find it strange. That is all.
I think they don't always communicate well with industry practitioners, and your reactions are great evidence of that.
Racket is lead by professors, and (as is sometimes the case in systems research) some of them are very highly skilled software developers, well above HN average. But they have not been working in industry, and some have never worked in industry, so they don't always know what notes to hit, and they don't always know current subtleties of practice.
My best example of this is when someone kept saying the platform was "batteries included". My reaction was, my god, no, please don't say that: the first time the wrong person sees that, invests time with that expectation, and finds all the ways that is absolutely not true by industry convention, they will rip the ecosystem a new one.
Set expectations properly, and you attract the right people, who will love it, and they will also disproportionately be great programmers.
That said, the software engineering quality situation is much better than the impression you seem to have. They've done a very solid job of rehosting Racket internals, and of generally maintaining backward-compatibility over the years. Much better than Python, for example. (Also, Racket docs are usually much better than most ecosystems I have used in recent years.)
The rewrite started in 2017.
Fears about refactoring introducing bugs are fine and valid - but after eight years, haven't really happened. Seems the extensive test suite did its job.
This isn't a case of Python 2 v 3. Packages weren't broken en masse. The API remained stable.
If anything, the rewrite has proved that it is mature. Because they could perform a refactor without breaking everyone's everyday.
Wait til you hear about NodeJS not supporting parallel threads until version 12...
Racket is awesome. Really fun language and a good lisp for learning.
Still have core memories of doing assignments in Racket with the Dr. Racket IDE
I first experimented with Lisp back in the mid-80’s, and have returned to it time and again—not as a language for serious projects, but just as a way of learning new techniques and new ways to think about writing software. I’ve tried using Racket on a number of occasions going back to way before it was called that, and something about the software just puts me off. Perhaps I could get past that if I stuck with it, but I just can’t see myself writing a large project using Racket.
when you say "software" do you mean the language features or the tooling?
i only know about racket because Carmack was doing Oculus stuff with it once 10 years ago:
https://youtu.be/ydyztGZnbNs?t=412
HN is written in Arc, and Arc is (was?) written in Racket.
https://en.wikipedia.org/wiki/Arc_(programming_language)
It was actually ported to a Common Lisp based implementation a while back.
https://news.ycombinator.com/item?id=41683969
I've wanted to try racket a few times but always found the "IDE" to be really unintuitive, clunky and weird. What gives? Is that by design or is it just that nothing better has been created so far?
The IDE is not the language.
Racket has good support in VSCode (via magic Racket and the Racket langserver), Emacs (Racket Mode) and Vim. https://download.racket-lang.org/releases/9.0/doc/guide/othe...
The Racket Langserver obviously enables use in other editors that support the LSP. https://github.com/jeapostrophe/racket-langserver For editors that lack LSP support, scheme support is generally sufficient.
All that aside, DrRacket the IDE has some nice features that just don't exist in other editors. I don't know of another IDE that has an integrated macro stepper.
Go to racket-mode.com for the very nice Emacs-integration.
Geiser works well for Racket also.
Lisp is its own meta-language, and Racket is even more meta. It's a language construction kit, essentially.
I've often heard this, but I don't really know of many people in the PL dev community who build their language in Racket. Also, I've taught a PL course and I tried to use Racket as a component, but students mostly just struggled with the LISP-y ness of it all, as they were primarily used to Java and Python. In all, I'm not really sure who Racket is for.
I suppose, Racket is for CS grads / post-grads / researchers / professors. That is, not for those who just learn CS basics, but for those learnèd enough.
Students might use some simplified or customized languages produced with Racket. The syntax needs not be lispy; #lang algol60 is built in :)
You list only academic positions. Has no popular software been written in it yet?
Arc was ported to Common Lisp last year, but before that was Racket.
And HN is written in Arc.
So does the website you're on count as popular software?
Six degrees of "Kevin..", I mean, Racket
Actually it's great for learning CS basics.
https://zoo.cs.yale.edu/classes/cs201/Spring_2021/lectures/R...
fyi https://blog.cloudflare.com/topaz-policy-engine-design/
Idris is bootstrapped on scheme if I recall correctly
it's bootstrapped off of GHC.
it was only using ChezScheme as an optimizing compiler backend.
(i created a PR to refactor their build system to reify the bootstrap process all the way down from GHC. it basically generalized the normal build workflow of Idris2 to be able to animate the entire bootstrap chain from GHC. sadly, it was pretty much ignored, and later abandoned: https://github.com/idris-lang/Idris2/pull/1990)
From the Idris 2 documentation:
Also, check this talk:https://www.youtube.com/watch?v=h9YAOaBWuIk
well, i wouldn't call that beeing bootstrapped.
in this case the generated scheme code is just a strange form of executable file that happens to need ChezScheme to be executed.
i.e. an ELF64 idris2 linux binary vs. an idris2.scm file that needs ChezScheme to come alive.
as for Idris2 implemented in Idris2: well, yes, that's true for the current version of Idris2. but the first version of Idris2 was written in Idris1. and the first version of Idris1 was written in Haskell.
Bogdan Popa has quite a bit of interesting information about Racket on his blog.
https://defn.io/
I look forward to using the new threading.
Racket is a fun language. My university uses the bundled teaching languages for first year CS courses. Some people really hate it, and others silently like it.
What was the name of the class?
Might have been Waterloo's Introduction to Functional Programming (CS 135). I have TA'd (technically ISA'd) that course several times and helped countless students in office hours. The struggling students didn't just hate Racket, they hated the whole HTDP philosophy of following a "design recipe" and writing documentation prior to implementing a function. Most of those struggling students essentially waited till the last minute to do the documentation, completely flouting the intention of the course.
I don't know if the strong students had the intended approach since they were never in office hours asking for help!
It's likely following HTDP:
https://htdp.org/
It could be following PLAI:
https://plai.org/
But that's not normally run as an introductory course, which is what OP mentioned Racket being used for.
And all of them agrees to never use it after university, which is quite telling.
I admit I'm one of those students who never used Racket in a non-academic setting (but mostly because I needed to contribute to already-existing projects written in different languages), and I was taught Racket from one of its main contributors, John Clements at Cal Poly San Luis Obispo. However, learning Racket planted a seed in me that would later grow into a love of programming languages beyond industry-standard imperative ones.
I took a two-quarter series of classes from John Clements: the first was a course on programming language interpreters, and the second was a compilers course. The first course was taught entirely in Racket (then called DrScheme). As a guy who loved C and wanted to be the next Dennis Ritchie, I remember hating Racket at first, with all of its parentheses and feeling restricted by immutability and needing to express repetition using recursion. However, we gradually worked our way toward building a Scheme meta-circular evaluator. The second course was language-agnostic. Our first assignment was to write an interpreter for a subset of Scheme. We were allowed to use any language. I was tired of Racket and wanted to code in a much more familiar language: C++. Surely this was a sign of relief, right?
It turned out that C++ was a terrible choice for the job. I ended up writing a complex inheritance hierarchy of expression types, which could have easily been implemented using Racket's pattern matching capabilities. Additionally, C++ requires manual memory management, and this was before the C++11 standard with its introduction of smart pointers. Finally, I learned how functional programming paradigms make testing so much easier, compared to using object-oriented unit testing frameworks and dealing with mutable objects. I managed to get the project done and working in C++, but only after a grueling 40 hours.
I never complained about Racket after that.
In graduate school, I was taught Scala and Haskell from Cormac Flanagan, who also contributed to Racket. Sometime after graduate school, I got bit by the Smalltalk and Lisp bugs hard....now I do a little bit of research on programming languages when I'm not busy teaching classes as a community college professor. I find Futamura projections quite fascinating.
I'm glad I was taught programming languages from John Clements and Cormac Flanagan. They planted seeds that later bloomed into a love for programming languages.
To be fair, "write an interpreter for a subset of scheme" is a core use case for lisp-family languages.
If it had been,"write a real-time driver for a memory-limited piece of hardware", you may have had a different preference.
Guile is GNU's extension language, and a Scheme.
It is meant for low level programming, like how it is used inside GDB.
Or high level, like how it is used in Make or Google's schism.
If you want memory limited, then you can turn it around in uLisp [0] without really changing the dev experience.
[0] http://www.ulisp.com/
that's an often repeated misconception about lisps.
lisps are pretty good at low-level programming, but then you'll need to make some compromises like abandoning the reliance on the GC and managing memory manually (which is still a lot easier than in other languages due to the metaprogramming capabilities).
there are lisps that can compile themselves to machine code in 2-4000 LoC altogether (i.e. compiler and assembler included; https://github.com/attila-lendvai/maru).
i'm not saying that there are lisp-based solutions that are ready for use in the industry. what i'm saying is that the lisp langauge is not at all an obstacle for memory-limited and/or real-time programs. it's just that few people use them, especially in those fields.
e.g. i'd easily prefer a lisp to put together a specialized byte-code interpreter to shrink firmware size for small embedded devices (e.g. for a radio https://github.com/armel/uv-k5-firmware-custom/discussions/4...).
and there are interesting experiments for direct compilation, too:
BIT: A Very Compact #Scheme System for #Microcontrollers (#lisp #embedded) http://www.iro.umontreal.ca/~feeley/papers/DubeFeeleyHOSC05.... "We demonstrate that with this system it is clearly possible to run realistic Scheme programs on a microcontroller with as little as 3 to 4 KB of RAM. Programs that access the whole Scheme library require only 13 KB of ROM." "Many of the techniques [...] are part of the Scheme and Lisp implementation folklore. [...] We cite relevant previous work for the less well known implementation techniques."
BIT inspired PICOBIT (last changed in 2015): https://github.com/stamourv/picobit racket (only a .so into an already running VM): http://download.racket-lang.org/docs/5.1.3/html/raco/ext.htm... scheme: gambit, chicken
If it taught them the core concepts of writing good software, that's a win in my book.
Agree? Or maybe none of them graduate into a role where they get to decide what language to use?
Everyone gets to choose which language they use for their personal projects.
Where are all the Racket personal projects?
N.B. I say this as someone who personally contributed small fixes to Racket in the 90s (when it was called mzscheme) and 00s (when it was called PLT-Scheme).
I view Racket as an academic language used as a vehicle for education and for research. I think Racket does fine in its niche, but Racket has a lot of compelling competitors, especially for researchers and professional software engineers. Those who want a smaller Scheme can choose between plenty of implementations, and those who want a larger language can choose Common Lisp. For those who don't mind syntax different from S-expressions, there's Haskell and OCaml. Those who want access to the Java or .NET ecosystems could use Scala, Clojure, or F#.
There's nothing wrong with an academic/research language like Racket, Oberon, and Standard ML.
Delimited continuations as a programming construct were somewhat of interest when I learned about them, but not even my university discussed them.
I don't think I ever had a colleague that even ever heard of the concept, let alone applied it. Of the "smart people", they typically only have heard of plain continuations, if you are lucky.
The debugger in Racket was useful when I used it years ago.
Unfortunately, it's kind of difficult to beat an entire planet cranking out libraries in other languages as many interesting programs are written for an ecosystem; if 90% of your project is building FFIs to make something work, perhaps you can better just choose the language of fools dun jour.
I don't think Scheme is the most academic language, today. Such honor would go to a language supporting a computable version of homotopy types, which I would guess only 1000 people in the world would be capable of using assuming production grade implementations (of which none exist).
Delimited continuations are quite similar to effect systems that seem to be getting a lot of interest lately. So who knows, maybe they will become more mainstream in the future.
back in the day when we wrote enterprise bullshit in common lisp (!), we had put together a proof of concept where we used delimited continuations to write business processes.
business processes were written in basically full common lisp with very few limitations, and with a few extra primitives to use (and 10x slower due to being interpreted, but that didn't matter at all). when a process reached a point where it was waiting for some external event (e.g. displaying a GUI for a user and waiting for their feedback, or sleeping until a deadline), then it got serialized into the (SQL) database.
it was pretty cool! when a user logged in, there was a list of processes waiting for him that he could click to see and interact with. all this with the transactional guarantees of the sql backend because the business objects were also stored in the same database.
https://github.com/hu-dwim/hu.dwim.delico was the continuation lib, hu.dwim.perec was the object relational mapper, and hu.dwim.serializer was used to turn CL objects into SQL blobs (with some properties extracted as reified SQL schema elements to be able to search for the suspended processes).
What is the use case for this?
I use it for trading options.
https://github.com/evdubs/renegade-way
I used it to write a macro processor for C which allowed me to write some macros with s-expressions and have it expand to a lot of C code. That way I could actually write real macros for C.
I have also written GUI apps for various things. Kind of like what I did with TCL back in the day.
I wrote a little maths game for my son.
I also wrote a static site generator in it that allowed me to execute racket code at compile time (interpreting each markdown file as a source file).
It's a general purpouse language. Reusig an old comment, I used it for
* A bot to reply emails that uses IMAP, SMTP and web scrapping. (It's not 100% automatic. It replies only the easy cases and adds labels so I reply the tricky ones.)
* An program to cleanup Moodle backups that uses gzip and xml. I compiled it and send it to my coworkers. (The backups have too much info, so before restoring it in another site it's better to remove the unused parts.)
I wrote custom language for designing Age of Empires 2 Random Maps. Basically AoE2 already supports it, but the underlying language is very very primitive. While I am not aware of anyone actually using what I made, it was mostly nice learning experience. https://github.com/Erbenos/aoe2-rms
Because its on top of Racket, you get usual high-level language faculties for basically free.
You can solve the versioning problem on your GitHub page by using Nix.
As the other reply said, it is general purpose. It has a focus on education tooling, and language design (languages can be easily implemented on Racket)
What are some difference between the education tooling around Racket and that which enables "industrial" applications Common Lisp is known for?
I think SBCL has better support for annotations. You can claim that a variable is an int and the compiler will thrust you and generante fast code.
You can use Typed Racket to add annotations. The compiler will verify your that your claims are consistent and perhaps add some runtime checks when you read data or use other external sources. It will remove most of the internal checks, but not all of them.
(Probably some features of Racket like impersonators make generating fast code faster, but on the other hand allows Typed Racket and other variants/libraries to ensure external objects behave correctly.)
Disclaimer: I use "Plain" Racket, so both descriptions may be slightly wrong.
That's a good question.
The education tooling is all optional (so their only impact is perceptual) DrRacket, teaching languages, and supporting libraries are all optional. (see Minimal Racket - just the compiler and package manager https://download.racket-lang.org/releases/9.0/#:~:text=SHA25... )
I'd like to know what tooling is missing from Racket that is available in major general purpose languages like C#, Java, or Common Lisp implementations?
https://blog.cloudflare.com/topaz-policy-engine-design/
The developers spoke at RacketCon this year https://youtu.be/7Twlh-Opq5E?si=JkWxLib8HTnjVjPI