> Internally, Racket's intermediate compatibility layer over operating-system facilities has been moved into its own library, "rktio", so it can be used in future Racket implementations.

Presumably by "future racket implementations" they mean the Racket 7 move to Chez Scheme: https://news.ycombinator.com/item?id=13656397

Also, this seems like a neat thing for people needing to deploy racket code x-platform:

> Racket supports cross-compilation of executables in more cases, including executables that depend on packages for foreign libraries.

> Presumably by "future racket implementations" they mean the Racket 7 move to Chez Scheme:

Presumably, it's broader than that, and applies to any new VMs enabled by the Racket-in-Racket effort, not just the expected move to Chez as the primary VM.

Good point. I've wondered if the "write more of Racket in Racket" effort required by the move to Chez Scheme will result in an easier path to Racketscript. IIRC, Clojurescript was helped along by something similar.

Is anyone aware of any languages targeting the Racket VM? Any thoughts on whether the Racket VM would be a more pleasant VM target than, say, the JVM or the .Net CLR?

The VM itself without the "racket is a language for building languages" thing? Not that I know of. That being said, Racket has a LOT of languages built on it.

For example, this site (Hacker News) is built in Arc, which is built on an old version of Racket.

EDIT: Also worth noting that Racket will move to an even more performant runtime (Chez Scheme) at some point in the future.

The "Racket VM" is designed from the ground up for other languages to be built on top of it (hence the #lang line at the beginning of every file) so it would likely be much better. Hackett[1] is a Haskell-like lang built on top of racket, for a nontrivial example.

[1] https://github.com/lexi-lambda/hackett

Anybody use Racket in production? Every time I think about it, the lack of libraries holds me back.

I have in the past, as a web server.

It used Racket's inbuilt Threads, http constructors, and the only external package, db-lib, to talk to Postgres.

Supported about ~12,000 long-lasting connections/min for the first 48hrs, without dropping or being overly slow.

Lack of some libraries weren't really an issue, because:

* Typed, Lazy and normal Racket can all talk to each other easily.

* Re-inventing the wheel is ridiculously easy and quick in Racket.

* Re-writing something from SLIB [0], is a five minute thing, if you need to make any changes.

* Racket has a decent FFI, and wrapping C is simple. (There is also progress for talking to Java)

Add to that, for most people Python is easy. And when they get used to parentheses, most of my team were surprised to find Racket is a lot like Python, which meant fast iteration, with better performance than Python, but less opinion.

[0] http://people.csail.mit.edu/jaffer/SLIB

> Every time I think about it, the lack of libraries holds me back.

Perhaps it seems that it lacks libraries compared to the NPM repository, or to Java, but last time checked, there are 779 packages listed for Racket:

https://pkgs.racket-lang.org/

Have you taken a look to see if you find what you need?

For a parallel example: At first I was reluctant to develop in Common Lisp due to what appeared to be "too few libraries", again, it's just an appearance when you compare to the amount of libraries for a more mainstream platform like Java or C++. However, for CL i found all the libraries i needed (and then some); i wouldn't be surprised if for Racket you can find everything you need.

It's usually not so much the number of packages itself, as it is the degree of maturity or support. It is indirectly connected to count in a sense that, say, you might have a dozen packages doing the same thing for Java or Node, of which three have more than one maintainer, and one is mature and stable - and so you can use that latter one without worry. Whereas in smaller ecosystems, you often end up with just one package being your only option, and so you just live with the fact that it has a single maintainer (who can decide to quit for whatever personal reasons any day), and has been version 0.x for years.

However, in Racket (and Scheme, Lisp, Clojure, LFE, etc.), due to the extra flexibility, the language lets you extend the library in a much easier way (than in Java or C++), so becoming a contributor to said library becomes a viable proposition.

Curious too, but mostly about Racket's performances in recent releases, I've always been told it's rather slow.

Slow is relative. Slow compared to Java? In some cases yes, and in others not so bad: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Slow compared to, say, Python3? Generally Racket wins out commandingly: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

EDIT: Normal disclaimers about lies, damned lies, and benchmarks apply :-)

I agree. Moreover, like the examples in the benchmargame, usually for code that only crunch numbers Racket is 10x-20x times faster than Python. For code that use a lot of strings or hash-tables, Racket is usually slightly slower, 20%-50%. YMMV.

It's also important to compare the idiomatic version of the code in Racket versus the idiomatic version of the code in Python. If you make a line by line translation, you can get an awful performance.

Also, remember that by default the DrRacket IDE use the mode "debugging" and "preserve stacktrace". They are very handy for debugging but they make the code much slower. The recommendation is to run the benchmarks in the command line. But if you disable "debugging" and "preserve stacktrace" the results are quite good.

“… After all, facts are facts, and although we may quote one to another with a chuckle the words of the Wise Statesman, ‘Lies—damned lies—and statistics,’ still there are some easy figures the simplest must understand, and the astutest cannot wriggle out of.”

Leonard Henry Courtney, 1895.

If people out there are satisfied with Ruby and Python3 performance, then they will be even more satisfied with Racket, which should run at 2x speed at least...

I can't find the thread but about a year ago a moderator here said HN uses racket.

Arc [0], built atop Racket.

[0] https://en.wikipedia.org/wiki/Arc_(programming_language)

I don't use it in production but I took carmack's advise and started teaching my nephews. They love it!

We used Bigloo for a while (with a considerable amount of in-house developed code/libraries). That project has since ended, but it was fun while it lasted.

ahem ^

Students everywhere thank you

praise the racket overlords, I'm very grateful for this release also

I think it's better to link to the announcement page: https://download.racket-lang.org/v6.10.html

Thanks! We've updated the link from https://download.racket-lang.org.

Sorry to go meta, but why do people have to mess with the font weight? 99% of the time you should just leave it at 400. (The font is bold on the whole page)

complete guess, their doc generation system used this by default, now racket visual identity is tied to it