Live data from Hacker News

Racket v9.0

blog.racket-lang.org

41–50 of 129 posts

Re: Racket v9.0

#41
post #22

Earlier quoted context omitted.

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/199…

From the Idris 2 documentation:

    >> 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.
Also, check this talk:

https://www.youtube.com/watch?v=h9YAOaBWuIk

Re: Racket v9.0

#42
post #36

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.

Re: Racket v9.0

#43

The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.

I feel like version 9 just getting parallel threads kind of contradicts the homepage when it says Racket is "Mature" and "Polished".

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

Re: Racket v9.0

#44
post #29
post #20

Earlier quoted context omitted.

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 i…

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.

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

Re: Racket v9.0

#46

The big news here is that Racket now can run threads in parallel. While there were ways to get parallelism before (like places), this is much more lightweight and familiar. Anything that expands the areas where Racket is viable is good news to me since I like writing stuff in Racket.

I feel like version 9 just getting parallel threads kind of contradicts the homepage when it says Racket is "Mature" and "Polished".

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

Re: Racket v9.0

#47

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 k…

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

Re: Racket v9.0

#48
Speaking of lisp, if I wanted to use a lisp nowadays, what would be the best choice, common lisp, clojure or some scheme implementation?

Re: Racket v9.0

#49
post #11

Earlier quoted context omitted.

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.

Post reply on HN