Racket v9.0

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

Agree? Or maybe none of them graduate into a role where they get to decide what language to use?

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.

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.

It's likely following HTDP:

https://htdp.org/

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 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 :)

Idris is bootstrapped on scheme if I recall correctly

    >> 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.

fyi https://blog.cloudflare.com/topaz-policy-engine-design/

These days, I prefer Lean 4. Its macro system is inspired by racket and it has powerful types

What are some difference between the education tooling around Racket and that which enables "industrial" applications Common Lisp is known for?

You can solve the versioning problem on your GitHub page by using Nix.

The developers spoke at RacketCon this year https://youtu.be/7Twlh-Opq5E?si=JkWxLib8HTnjVjPI

This is addressed in the blog post linked from the release announcement: https://blog.racket-lang.org/2025/11/parallel-threads.html

Wait til you hear about NodeJS not supporting parallel threads until version 12...

It's not at all strange, Python and OCaml are mature and polished and they still have tackled the same issue very recently.

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.

I'd say anything you use Clojure for except for Clojurescript.

The tooling.

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.

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.

Geiser works well for Racket also.

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.