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.
clojure works on the jvm, or without (babashka, technically graalvm i think), or in the browser (clojurescript). i think there is a .net implementation, not sure.
then you get clojure inspired languages that are quick to learn if you know clojure (janet, C runtime, fennel on the Lua platform).
And soon a clojure optimized for integration with C++ (Jank).
Bonus, clojure is relatively simple language. (it's a small language where most things are immutable, with a small-ish set of functions operating on a small-ish set of provided data structures).
common lisp is cool but looks way (waaay) more complex. so you will need to invest way more to learn it (might be worth it, dont know). i technically "learned" it but never felt the impetus to use it.
i occasionally do some stuff in emacs lisp. but i'll mainly be running clojure & babashka (and rust). currently refreshing my ocaml, and learning ada (this thing is great, should have learned it a long time ago). also nim.
I personally use Clojure because I got a job doing it, I hadn’t touched it before my current position. I would pick it now over Common Lisp and Elisp because I prefer the syntax (I like the brackets in addition to parentheses) but also the Java integration and build tooling make things easier to get going.
I use clojure over common lisp because I find the ecosystem (libraries) a bit more approachable (feels like there is more web oriented stuff in clojure, plus gui support with javafx.) That said, the actual experience of working in common lisp is better (bit better repl/recompilation, conditions, native compilation.) Personally, I don't find scheme as practical for writing programs as either of these two options (too fragmented and/or niche.)
> 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 all lisp lovers tackling concurrency and parallelism, a reminder there's also LFE - a lisp for Erlang VM. Which happens to have solved all these issues decades ago. LFE was created by one of the Erlang co-creators. https://lfe.io
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.
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.
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.
Nice examples! With a few tricks, I made the Racket program x5 faster. I think you tried to use the simplest program, so I tried to add as few cheats as possible. I added a happy path for fixnums and keep the slow path in case the iterations gets too big:
(define (count-collatz n [cnt 1])
(if (fixnum? n)
(cond
[(= n 1) cnt]
#;[(zero? (unsafe-fxremainder n 2)) (count-collatz (unsafe-fxquotient n 2) (+ 1 cnt))]
[(zero? (fxand n 1)) (count-collatz (unsafe-fxquotient n 2) (+ 1 cnt))]
[else (count-collatz (+ (* 3 n) 1) (+ 1 cnt))])
(cond
[(= n 1) cnt]
[(even? n) (count-collatz (/ n 2) (+ 1 cnt))]
[else (count-collatz (+ (* 3 n) 1) (+ 1 cnt))])))
My program has two versions, the version with `fxand` is slightly faster than the versions with `fxremainder`. I have to used two `unsafe-` functions, but a smart enough optimizer should have fixed them. So I'm adding this example to my wishlist.
I think it would be very hard for the optimizer would be to replace `/` with `quotient`, but the rest look possible.
I wonder how, given that anything that brings Python and performance together, usually means it is actually C code, or similar, as PyPy is seldom reached for.
Raket is compiled, thus maybe not the right build parameters?
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.
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).
> 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.
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).
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.
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.
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."
People always point out this as a failure, when it is the contrary.
A programming language being managed doesn't mean we need to close the door to any other kind of resource management.
Unless it is something hard real time, and there are options there as well, we get to enjoy the productivity of high level programming, while at the same time having the tools at our disposal to do low level systems stuff, without having to mix languages.
C++ is one of my favourite languages, and I got into a few cool jobs because of my C++ knowledge.
However, given the option I would mostly reach for managed compiled languages as first choice, and only if really, really required, to something like C++, and even then, probably to a native library that gets consumed, instead of 100% pure C++.
I didn’t know you like C++. I’ve been reading your posts for a few years now and your advocacy of the Xerox PARC way of computing. I’ve found that most Smalltalkers and Lispers are not exactly fond of C++. To be fair, many Unix and Plan 9 people are also not big C++ fans despite C++ also coming from Bell Labs.
Back when C++ was becoming famous, my favourite programming language was Object Pascal, in the form of Turbo Pascal, having been introduced to it via TP 5.5 OOP mini booklet.
Shortly thereafter Turbo Pascal 6 was released, and I got into Turbo Vision, followed by Turbo Pascal 1.5 for Windows 3.1, the year thereafter.
I was a big Borland fan, thus when you got the whole stuff it was Object Pascal/C++, naturally C was there just because all C++ vendors started as C vendors.
On Windows and OS/2 land, C++ IDEs shared a lot with Smalltalk and Xerox PARC ideas in developer experience, it wasn't the vi + command line + debuggers are for the weak kind of experience.
See Energize C++, as Lucid was pivoting away from Common Lisp, with Cadillac what we would call a LSP nowadays, where you could do incrementatl compilation on method level and hot reload
You're right altougth C++ was born on UNIX at Bell Labs there is that point of view, and also a reason why I always had much more fun with C++ across Mac OS, OS/2, Windows, BeOS, and Symbian, with their full stack frameworks and IDE tooling.
However with time I moved into managed languages, application languages, where it is enough to make use of a couple of native libraries, if really required, which is where I still reach for C++.
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.
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.
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).
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.
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.
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.
What you use depends on the needs of the project. That might mean Racket, Guile, Clojure, SBCL or something else. It all depends on what you need to do.
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.
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.
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'd say anything you use Clojure for except for Clojurescript.
And I guess expect for stuff where you really want Java integration?
There's a Java interface. I've never used it though.
https://docs.racket-lang.org/jni/index.html
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.
personal case -
clojure works on the jvm, or without (babashka, technically graalvm i think), or in the browser (clojurescript). i think there is a .net implementation, not sure.
then you get clojure inspired languages that are quick to learn if you know clojure (janet, C runtime, fennel on the Lua platform).
And soon a clojure optimized for integration with C++ (Jank).
Bonus, clojure is relatively simple language. (it's a small language where most things are immutable, with a small-ish set of functions operating on a small-ish set of provided data structures).
common lisp is cool but looks way (waaay) more complex. so you will need to invest way more to learn it (might be worth it, dont know). i technically "learned" it but never felt the impetus to use it.
i occasionally do some stuff in emacs lisp. but i'll mainly be running clojure & babashka (and rust). currently refreshing my ocaml, and learning ada (this thing is great, should have learned it a long time ago). also nim.
There is a .NET version, but hardly gets much love, it is already a challenge for F#, and the Iron languages are gone as well.
Unfortunely the CLR seems to have changed meaning from Common Language Runtime to C# Language Runtime, regarding Microsoft focus on the ecosystem.
I personally use Clojure because I got a job doing it, I hadn’t touched it before my current position. I would pick it now over Common Lisp and Elisp because I prefer the syntax (I like the brackets in addition to parentheses) but also the Java integration and build tooling make things easier to get going.
I use clojure over common lisp because I find the ecosystem (libraries) a bit more approachable (feels like there is more web oriented stuff in clojure, plus gui support with javafx.) That said, the actual experience of working in common lisp is better (bit better repl/recompilation, conditions, native compilation.) Personally, I don't find scheme as practical for writing programs as either of these two options (too fragmented and/or niche.)
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.
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.
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
For all lisp lovers tackling concurrency and parallelism, a reminder there's also LFE - a lisp for Erlang VM. Which happens to have solved all these issues decades ago. LFE was created by one of the Erlang co-creators. https://lfe.io
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.
It's usually faster than Python for numeric stuff, and has a similar speed for strings. See for example https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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.
See for example
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
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:
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.
Nice examples! With a few tricks, I made the Racket program x5 faster. I think you tried to use the simplest program, so I tried to add as few cheats as possible. I added a happy path for fixnums and keep the slow path in case the iterations gets too big:
My program has two versions, the version with `fxand` is slightly faster than the versions with `fxremainder`. I have to used two `unsafe-` functions, but a smart enough optimizer should have fixed them. So I'm adding this example to my wishlist.I think it would be very hard for the optimizer would be to replace `/` with `quotient`, but the rest look possible.
I wonder how, given that anything that brings Python and performance together, usually means it is actually C code, or similar, as PyPy is seldom reached for.
Raket is compiled, thus maybe not the right build parameters?
when you say "software" do you mean the language features or the tooling?
The tooling.
I love Racket. Just for fun, I wrote a Racket book, read online: https://leanpub.com/racket-ai/read
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 just bought your book. Thanks for writing it. I look forward to reading it!
https://youtu.be/LXhsutNKhec?si=OTC6sn5GNp1-ZxqU
Racket is only hard if it's not your first language. Kids can also learn it.
Very impressive video. This is making me want to start my daughter out on scratch or Racket when the time comes.
His keyboard sounds amazing too. Buttery smooth pearls.
After learning to type, he learned vim through https://vim-adventures.com/
Just FYI, if you want to help your daughter as she grows up. Typing skills, VIM and Racket. He doesn't know anything else about computers.
A wonderful video!
Thanks for helping my son learn it.
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.
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).
> 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.
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 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)
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…]
more and sources of Dang quotes: https://lisp-journey.gitlab.io/blog/hacker-news-now-runs-on-...
It was actually ported to a Common Lisp based implementation a while back.
https://news.ycombinator.com/item?id=41683969
Btw reading Racket documentation is a pleasure each time, both visually and intellectually. So great effort
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.
fyi https://blog.cloudflare.com/topaz-policy-engine-design/
That was a great read from Cloudflare.
These days, I prefer Lean 4. Its macro system is inspired by racket and it has powerful types
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 :)
Actually it's great for learning CS basics.
https://zoo.cs.yale.edu/classes/cs201/Spring_2021/lectures/R...
You list only academic positions. Has no popular software been written in it yet?
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
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
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.
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.
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?
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.
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 loved that course so much. I remember some seemed to hate it because "when are we ever going to use Scheme in real life?"
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!
Waterloo’s CS135! I’m in it right now.
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
People always point out this as a failure, when it is the contrary.
A programming language being managed doesn't mean we need to close the door to any other kind of resource management.
Unless it is something hard real time, and there are options there as well, we get to enjoy the productivity of high level programming, while at the same time having the tools at our disposal to do low level systems stuff, without having to mix languages.
C++ is one of my favourite languages, and I got into a few cool jobs because of my C++ knowledge.
However, given the option I would mostly reach for managed compiled languages as first choice, and only if really, really required, to something like C++, and even then, probably to a native library that gets consumed, instead of 100% pure C++.
I didn’t know you like C++. I’ve been reading your posts for a few years now and your advocacy of the Xerox PARC way of computing. I’ve found that most Smalltalkers and Lispers are not exactly fond of C++. To be fair, many Unix and Plan 9 people are also not big C++ fans despite C++ also coming from Bell Labs.
Back when C++ was becoming famous, my favourite programming language was Object Pascal, in the form of Turbo Pascal, having been introduced to it via TP 5.5 OOP mini booklet.
Shortly thereafter Turbo Pascal 6 was released, and I got into Turbo Vision, followed by Turbo Pascal 1.5 for Windows 3.1, the year thereafter.
I was a big Borland fan, thus when you got the whole stuff it was Object Pascal/C++, naturally C was there just because all C++ vendors started as C vendors.
On Windows and OS/2 land, C++ IDEs shared a lot with Smalltalk and Xerox PARC ideas in developer experience, it wasn't the vi + command line + debuggers are for the weak kind of experience.
See Energize C++, as Lucid was pivoting away from Common Lisp, with Cadillac what we would call a LSP nowadays, where you could do incrementatl compilation on method level and hot reload
"Lucid Energize Demo VHS 1993"
https://www.youtube.com/watch?v=pQQTScuApWk
https://dreamsongs.com/Cadillac.html
Or the Visual Age for C++ version 4, which introduced a database, image like system for doing C++ in workflows similar to Smalltalk.
https://www.edm2.com/index.php/A_Review_of_VisualAge_C%2B%2B...
https://www.edm2.com/index.php/VisualAge_C%2B%2B_4.0_Review
Then there is C++ Builder, still going on, even though the way Borland went down spoiled its market mindshare,
https://www.embarcadero.com/products/cbuilder
You're right altougth C++ was born on UNIX at Bell Labs there is that point of view, and also a reason why I always had much more fun with C++ across Mac OS, OS/2, Windows, BeOS, and Symbian, with their full stack frameworks and IDE tooling.
However with time I moved into managed languages, application languages, where it is enough to make use of a couple of native libraries, if really required, which is where I still reach for C++.
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.
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.
If it taught them the core concepts of writing good software, that's a win in my book.
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.
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.
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.
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.
https://defn.io/page/projects/
https://joeldueck.com/projects.html
Speaking of lisp, if I wanted to use a lisp nowadays, what would be the best choice, common lisp, clojure or some scheme implementation?
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.
Racket of course!
More seriously, there is no one ‘best lisp’.
What you use depends on the needs of the project. That might mean Racket, Guile, Clojure, SBCL or something else. It all depends on what you need to do.
I’ve been playing around with Janet for scripting use cases and it’s pretty cool.
Common Lisp. It's the hacker-est Lisp with a thriving hacker-est community.
I want to thank Go for popularizing coroutines. Seems like every language now has adopted it and I love that.
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.
Only for the newer generation.
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.
What is the use case for this?
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.
Too late to edit:
> impersonators make generating fast code faster
should be
> impersonators make generating fast code harder
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?
Java has the VisualVM. https://visualvm.github.io/
I would love a similar tool for Racket.
between CL, some say it's the debugging and interactive experience: https://gist.github.com/vindarel/c1ef5e043773921e3b11d8f4fe1...
https://blog.cloudflare.com/topaz-policy-engine-design/
The developers spoke at RacketCon this year https://youtu.be/7Twlh-Opq5E?si=JkWxLib8HTnjVjPI
I use it for trading options.
https://github.com/evdubs/renegade-way
[dead]