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.
While reading the release notes, I was also surprised, that they finally have this kind of multi-threading. I knew about places, but they were kind of inflexible, as you couldn't easily send a lambda in Racket, and serializable-lambda was infectious, so one ended up having to pre-define all logic and at runtime only sending data not functions to other places, which was a shame. One could not really build a thing that distributes work via multiple places with that. Or at least no one managed to do that and no one could tell me how to do it. I hope that with the new concurrency stuff this is now possible, even if it may not be as conceptually clean as places were supposed to be.
Ultimately, multi-threading is one reason, why I mostly used GNU Guile, instead of Racket in recent years. Guile's story of using multiple cores is much more solid, using its futures and possibly fibers via a library. I have used futures, which are backed by a pool of threads underneath, to implement a toy parallelized decision tree algorithm/model, that had linear (or close to) speedup.
What kinds of things do you write in Racket? I’m a clojure dev and so I’m a big fan of lisp. I’m just curious what kinds of projects you would use Racket for
i'm also curious.. do you use clojure because of jvm? i want to learn some kinda lisp, but there are so many choices. why not just common lisp or the one with emacs.
> 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 agree. I remember very few bugs caused by the rewrite, but I don't remember recent ones.
For example, I found a bug running the tests of the r7rs package, it was simplified to a bug in "plain" Racket and later fixed, 3 days after the initial report. It was in June 2019 https://github.com/racket/racket/issues/2675 Note that at that time, the default version of Racket was he old one (before the rewrite).
Nobody would consider Chrome or Firefox to be immature or lacking polish because they have replaced entire compilers several times over the past few years? I don't have an exact count, but they probably do this every 3-5 years which puts them way ahead of Racket.
I'd also note that Chez Scheme was a commercial implementation bought and open-sourced by Cisco. It wasn't something they threw together. Because it is a complete scheme v6 implementation they are building on instead of rolling their own implementation in C. Coding against a stable Scheme API has to be easier and less buggy than what they had before (not to mention Chez being much faster at a lot of stuff).
I think you should read the old posts as to why Racket transitioned it's guts from primarily C to Chez Scheme. It would save a lot of time in the discussion here if you became familiar with that transition.
The short story is the same as anything written in C: it's an unwieldy language.
They might be making a distinction between the language and the current implementation. In fact I would call going through multiple different fundamental implementations without changing the semantics, an argument in favor of the maturity of the language.
For Scheme languages I recommend Racket or Gerbil. Racket is great for beginners since the IDE is pretty good and the standard libraries and contributed libraries are good. Gerbil is good for systems programming. network utilities, etc.
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 liked it many years ago but when I noticed how slow and heavy my code was I left it. It manages to be slower than Python. Perhaps the Chez Scheme rewrite helped with that but now if I need a Lisp I have Common Lisp which is super fast and lightweight enough.
These are small benchmarks, so don’t over-generalize from this data point alone, but Racket absolutely crushes Python in terms of speed and goes speedily enough against other popular performance-focused languages:
Matthew Flatt, the Racket lead, says that Racket’s performance should be fairly comparable to Java, much faster than Python, slower than Julia/Rust/etc. That’s been a helpful model for me: if Java is fast enough, Racket will do fine.
But if you run the code inside the default IDE call DrRacket, you must go to the menu Language>Choose_Language... then click "Show_Details" and disable "Debugging".
With debugging enabled, you get nicer error messages, but it blocks a lot of optimizations and the program get slow.
Arc was re-written to Common Lisp (SBCL) around last year, for performance reasons.
> [Clarc] is much faster and also will easily let HN run on multiple cores. It’s been in the works for years, mainly because I rarely find time to work on it, but it’s all pretty close to done.
> there’s now an Arc-to-JS called Lilt, and an Arc-to-Common Lisp called Clarc. […]
> open-sourcing the Arc implementation (i.e. Clarc) would be much easier [than the HN site]. [Because…]
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 :)
Naughty Dog used Racket and their own in house lisp (prior to that) to write their games.
Could be mistaken but IIRC Jak and Daxter was the first console game to have a fully streaming world and they achieved it using a technique inspired by their hot reloading dev setups
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.
Go definitely popularized concurrency for the modern era, but coroutines themselves are ancient tech. Melvin Conway coined the term in 1963 and Simula had them by '67.
It’s also worth noting that the specific 'coroutine' model most languages are adding today (JS, Rust, Python) is based on C#'s async/await.
Go actually rejected that approach in favor of Green Threads (Goroutines, not coroutines), so technically it popularized the alternative to what everyone else is doing.
And green threads were already present in JVM early days, with red threads being the actual OS threads.
Solaris LWP and Windows Fibers were two other examples of OSes providing the infrastructure for a task based programming, although they had some issues.
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 really loved the course too. That's why I kept working for it! It always made me sad when students hated the course, which was most of the ones I met in office hours. I think the students who really loved the course did well enough that they didn't come to office hours, so I never met them!
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."
University is to open the people's horizons, to learn how to learn, too see computing systems in action that most people on programming bootcamps never deem possible, unless they are curious to learn about computing history.
I use it professionally. My favorite is its seemingly complete lack of bad behavior:
"3" + 1 is neither "4", "31", nor 4. It's illegal.
0 is not false, causing endless confusion on filters and &&s.
For loops don't alter the iterated value within a closure to the max value when it's finally called.
And some positives:
Immutable/functional is the default, but mutability is easy too.
Nice optional, keyword, and variable arity support.
Straight forward multithreading, semaphores, shared state, and unshared state.
Excellent module system:
- renames both in and out, including prefixes, all applied to arbitrary scopes of identifiers (I may be using inaccurate terminology)
- nested submodules
- automatic tests and/or "main" submodules
.....etc.......
If I could be grated a wish though it would be for nice struct syntax, but I think that's in Racket's successor Rhombus; haven't personally tried it yet.
I also sometimes wish it was slightly Haskell-ier in various ways, as did the talented individual who created Hackett.
If I were to guess why it's not used, it's because it's not used, which has a kind of downward-spiral force thing going on with it. If you're a random guy in charge of 200 dudes at BigCo, your first thought probably isn't "We should rewrite this whole thing in Racket!", it's probably more like "We should fire everyone and have Claude rewrite our codebase into Rust!" and tell your boss you saved 200*0.5M a year and ask for a comparative bonus. But if you're solo and in charge of designing, implementing, and maintaining a system with 1 or 2 people over the next 20 years, you can use whatever language you want, and Racket's a pretty good choice.
Sometimes it takes a couple of years, before a seed grows. I for one had a professor, who said: "I am not here to teach you C or Java. I am here to teach you computer programming." and then went on to take us on a tour through various paradigms, and included Prolog, back then Dr.Scheme (which turned into Racket), C, Java and Python. At the time I didn't understand Scheme at all. Didn't understand the idea of passing a function as an argument, so deeply rooted in the imperative world I was. But a couple of years later, I came upon HN and comments mentioning SICP ... Didn't that professor teach us something about that? What if I took a look and started learning from this book everyone is recommending?
And there it was. I worked on exercises of SICP and finished approximately 40% of the book's exercises and had a very solid grasp of Scheme and Racket, and any hobby project I would take out Racket to try and build it. Along the way I learned many things, that I would still not know today, had I stuck with only mainstream imperative languages. I wouldn't be half the computer programmer, that I am today, without going the SICP and Scheme way. I also worked through The Little Schemer. What an impressive little book it is!
So it is far from what you claim. In fact even a little exposure to Scheme once upon a time can make all the difference.
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).
Racket is my first choice for most code I write these days and I've published a fair number of libraries into the raco package manager ecosystem in hopes other people using Racket might find them useful too.
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.
I wish Standard ML had a strong ecosystem and things like a good dependency manager/package manager. I really liked it. But there is even less of an ecosystem around it than some other niche languages, and I've gone into the rabbit hole of writing everything myself too often, to know that at some point I will either hit the limit of my energy burning out, or the limits of my mathematical understanding to implement something. For example how to make a normal distribution from only having uniform distribution in the standard library. So many approaches to have an approximation, but to really understand them, you need to understand a lot of math.
Anyway, I like the language. Felt great writing a few Advent of Code puzzles in SMLNJ.
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.
Clojure is widely used, opinionated, promotes immutability, has lots of libraries and lively community. It is overall great language, really nicely designed, 100% worth using.
If you want the best performance and need to build executables without JVM then SBCL is a better choice, although probably takes longer to learn.
I wrote my fair share of Clojure, SBCL just had a look at.
Although if your executables are script-like, you can use babashka, which lets you write shell scripts in clojure. Good stdlib, full macro support, shell out to other commands, just a great tool.
I love babashka. I could never convince my company to use clojure for a big project, so now I’m exposing all of my coworkers to clojure by making a set of nice specific-to-our-company utilities in babashka.
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.
> 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.
I have a similar picture so far in my work experience. Basically, none of my coworkers ever touched a lispy language. If I said words like "continuation", "environment of a closure", "continuation-passing style" or "macros and metaprogramming", I would get blank stares. Or if I complained about that lambdas in Python are stunted things, they would not understand, because they were only familiar with mainstream OOP and every noun a class paradigm and wouldn't get the ideas where to use lambdas or even inner/nested functions.
This kind of stuff is definitely not part of the usual CS curriculum at universities here (Germany). And of course even more pure fantasy to imagine that to be taught in any boot camps or other higher schools than universities.
Well, maybe some day I will work with people, who have this knowledge, and maaaaybe together we can make something happen employing the ideas and such a language, that implements these concepts well. Or even just work with people, who know FP and have explored building things with it, like I did.
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?
Ultimately, multi-threading is one reason, why I mostly used GNU Guile, instead of Racket in recent years. Guile's story of using multiple cores is much more solid, using its futures and possibly fibers via a library. I have used futures, which are backed by a pool of threads underneath, to implement a toy parallelized decision tree algorithm/model, that had linear (or close to) speedup.
> 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?
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.
For example, I found a bug running the tests of the r7rs package, it was simplified to a bug in "plain" Racket and later fixed, 3 days after the initial report. It was in June 2019 https://github.com/racket/racket/issues/2675 Note that at that time, the default version of Racket was he old one (before the rewrite).
I'd also note that Chez Scheme was a commercial implementation bought and open-sourced by Cisco. It wasn't something they threw together. Because it is a complete scheme v6 implementation they are building on instead of rolling their own implementation in C. Coding against a stable Scheme API has to be easier and less buggy than what they had before (not to mention Chez being much faster at a lot of stuff).
The short story is the same as anything written in C: it's an unwieldy language.
Still have core memories of doing assignments in Racket with the Dr. Racket IDE
For Scheme languages I recommend Racket or Gerbil. Racket is great for beginners since the IDE is pretty good and the standard libraries and contributed libraries are good. Gerbil is good for systems programming. network utilities, etc.
https://lambdaland.org/posts/2023-12-20_functional_langauge_...
https://lambdaland.org/posts/2024-09-27_threaded_interpreter...
Matthew Flatt, the Racket lead, says that Racket’s performance should be fairly comparable to Java, much faster than Python, slower than Julia/Rust/etc. That’s been a helpful model for me: if Java is fast enough, Racket will do fine.
But if you run the code inside the default IDE call DrRacket, you must go to the menu Language>Choose_Language... then click "Show_Details" and disable "Debugging".
With debugging enabled, you get nicer error messages, but it blocks a lot of optimizations and the program get slow.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Racket is only hard if it's not your first language. Kids can also learn it.
https://youtu.be/ydyztGZnbNs?t=412
https://en.wikipedia.org/wiki/Arc_(programming_language)
> [Clarc] is much faster and also will easily let HN run on multiple cores. It’s been in the works for years, mainly because I rarely find time to work on it, but it’s all pretty close to done.
> there’s now an Arc-to-JS called Lilt, and an Arc-to-Common Lisp called Clarc. […]
> open-sourcing the Arc implementation (i.e. Clarc) would be much easier [than the HN site]. [Because…]
more and sources of Dang quotes: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...
https://news.ycombinator.com/item?id=41683969
Students might use some simplified or customized languages produced with Racket. The syntax needs not be lispy; #lang algol60 is built in :)
Could be mistaken but IIRC Jak and Daxter was the first console game to have a fully streaming world and they achieved it using a technique inspired by their hot reloading dev setups
And HN is written in Arc.
So does the website you're on count as popular software?
https://zoo.cs.yale.edu/classes/cs201/Spring_2021/lectures/R...
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)
https://www.youtube.com/watch?v=h9YAOaBWuIk
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.
It’s also worth noting that the specific 'coroutine' model most languages are adding today (JS, Rust, Python) is based on C#'s async/await.
Go actually rejected that approach in favor of Green Threads (Goroutines, not coroutines), so technically it popularized the alternative to what everyone else is doing.
Solaris LWP and Windows Fibers were two other examples of OSes providing the infrastructure for a task based programming, although they had some issues.
Besides the sibling comment, we already knew them from Solo Pascal and Modula-2 among other 1980's languages.
Co-routines were a famous way to simulate paralelism when you only got a single CPU.
https://defn.io/
I look forward to using the new threading.
I don't know if the strong students had the intended approach since they were never in office hours asking for help!
https://htdp.org/
https://plai.org/
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.
If it had been,"write a real-time driver for a memory-limited piece of hardware", you may have had a different preference.
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/
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
"3" + 1 is neither "4", "31", nor 4. It's illegal.
0 is not false, causing endless confusion on filters and &&s.
For loops don't alter the iterated value within a closure to the max value when it's finally called.
And some positives:
Immutable/functional is the default, but mutability is easy too.
Nice optional, keyword, and variable arity support.
Straight forward multithreading, semaphores, shared state, and unshared state.
Excellent module system:
- renames both in and out, including prefixes, all applied to arbitrary scopes of identifiers (I may be using inaccurate terminology)
- nested submodules
- automatic tests and/or "main" submodules
.....etc.......
If I could be grated a wish though it would be for nice struct syntax, but I think that's in Racket's successor Rhombus; haven't personally tried it yet.
I also sometimes wish it was slightly Haskell-ier in various ways, as did the talented individual who created Hackett.
If I were to guess why it's not used, it's because it's not used, which has a kind of downward-spiral force thing going on with it. If you're a random guy in charge of 200 dudes at BigCo, your first thought probably isn't "We should rewrite this whole thing in Racket!", it's probably more like "We should fire everyone and have Claude rewrite our codebase into Rust!" and tell your boss you saved 200*0.5M a year and ask for a comparative bonus. But if you're solo and in charge of designing, implementing, and maintaining a system with 1 or 2 people over the next 20 years, you can use whatever language you want, and Racket's a pretty good choice.
And there it was. I worked on exercises of SICP and finished approximately 40% of the book's exercises and had a very solid grasp of Scheme and Racket, and any hobby project I would take out Racket to try and build it. Along the way I learned many things, that I would still not know today, had I stuck with only mainstream imperative languages. I wouldn't be half the computer programmer, that I am today, without going the SICP and Scheme way. I also worked through The Little Schemer. What an impressive little book it is!
So it is far from what you claim. In fact even a little exposure to Scheme once upon a time can make all the difference.
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).
https://joeldueck.com/projects.html
There's nothing wrong with an academic/research language like Racket, Oberon, and Standard ML.
Anyway, I like the language. Felt great writing a few Advent of Code puzzles in SMLNJ.
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.
If you want the best performance and need to build executables without JVM then SBCL is a better choice, although probably takes longer to learn.
I wrote my fair share of Clojure, SBCL just had a look at.
I love babashka. I could never convince my company to use clojure for a big project, so now I’m exposing all of my coworkers to clojure by making a set of nice specific-to-our-company utilities in babashka.
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).
I have a similar picture so far in my work experience. Basically, none of my coworkers ever touched a lispy language. If I said words like "continuation", "environment of a closure", "continuation-passing style" or "macros and metaprogramming", I would get blank stares. Or if I complained about that lambdas in Python are stunted things, they would not understand, because they were only familiar with mainstream OOP and every noun a class paradigm and wouldn't get the ideas where to use lambdas or even inner/nested functions.
This kind of stuff is definitely not part of the usual CS curriculum at universities here (Germany). And of course even more pure fantasy to imagine that to be taught in any boot camps or other higher schools than universities.
Well, maybe some day I will work with people, who have this knowledge, and maaaaybe together we can make something happen employing the ideas and such a language, that implements these concepts well. Or even just work with people, who know FP and have explored building things with it, like I did.
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 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).
* 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.)
Because its on top of Racket, you get usual high-level language faculties for basically free.
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.
> impersonators make generating fast code faster
should be
> impersonators make generating fast code harder
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?
I would love a similar tool for Racket.
https://github.com/evdubs/renegade-way