(This current submission is really nice; you get to hear more from Matthew about what’s going on.)
Chez Scheme (pronounced “shay-scheme”) is the most performant and compliant Scheme implementation out there. [1] For a long time it was closed-source, but was recently open-sourced.
It now forms the foundation of the Racket language. (So, I guess that means HN relies on it, provided Arc is using a recent version of Racket.) I asked Matthew why he picked Chez to base Racket off of, and I want to say that he picked it because it implemented continuations really really well and had a good garbage collector too. I could be wrong.
It's encouraging to see all this solid (if unglamorous) software engineering work happening, for a powerful platform that also has active research going on.
(Maybe I'll find a way to resume using Scheme/Racket. The last few years, I've been using Python, JS, and Rust, partly for employability reasons. They have their merits, but I'm aware of what I'm missing.)
It's been a long time since I went through SICP, so someone with more recent knowledge should correct me. But I think you can get through most (almost all?) of SICP with what's in the Scheme standard, which is a pretty small subset of almost any Scheme implementation. In particular, I don't recall much that uses anything specific to MIT Scheme.
I'll always have a soft spot for Racket, because of how the IDE literally draws arrows for you, overlaid on top of the code, linking the various occurrences of a (hovered) variable together.[1][2] Seriously, how cool is that? Alas, it's unclear how to begin to implement such a feature in a performant way in a DOM-based editor like vscode (I'm not a web developer, so maybe I'm wrong about this.)
[2] > Lexical Structure: The lexical structure is shown with arrows overlaid on the program text. When the mouse cursor passes over a variable, DrRacket draws an arrow from the binding location to the variable, or from the binding location to every bound occurrence of the variable.
True, that wasn't my intent and you are right to draw this out into the open.
I have had the pleasure if witness a couple Matthew Butterick talks first hand and they are excellent. He is a great speaker and thinker. I have also seen the subject the article lose his cool a couple times. Which is not cool. Esp given his prominent place in the community. At this point and think he should make himself a bystander.
Neither of those restarted their Lisp when one pressed a run button. The Lispm IDEs were always running and always in the same environment as the programs. A whole different story.
Being inspired doesn't mean 100% the same experience.
Just like Notebooks are miles away from that experience, and yet they allow millions of programmers to have an experience that wouldn't have otherwise, even with Lisp Machines/Interlisp-D providing a much better one.
I still fail to see how the Racket IDE is inspired by Lisp Machines specifically.
Do you have any pointers where this is discussed?
What do you think is inspired by some Lisp Machine? REPLs existed before. Editors existed before. IDEs existed before. Lisp IDEs existed before. For example Interlisp had a Lisp IDE in the early 70s, long before it was morphed into something like a Lisp Machine with Interlisp-D.
No idea how to do this in a VSCode extension, but you could place a full-screen <canvas> over the whole editor with pointer-events: none. Then, you could use offsetLeft/Top or getBoundingClientRect() on relevant text elements to figure out where to draw lines on the canvas.
Did not try Racket specifically, but I did quite a lot of work with Dr. Scheme 15/20 years ago, which I think is Racket's ancestor?
It would allow you to define variables which were actual images. The image was a thumbnail in the code, which you could assign and print. It was mind blowing.
Also your Lambda keywords could be replaced with an actual Lambda symbol, which was the pinnacle of coolness.
This, as well as the super snappy and responsive split REPL, made the overall development experience with Scheme feel super futuristic and just a pure enjoyment all around.
It's got myriad other issues, but Mathematica is a lot like this. You can have "rich" literals like a sound file or and image or a 3d model and see and manipulate along with the source, which has a couple of different levels of syntactic sugar, from being an ugly text-only lisp up to stuff that looks like it comes from a well-illustrated text book.
What's missing from my life is a good FOSS equivalent. There are several wonderful tools which do similar things, e.g. Jupyter, org-babel, TeXmacs, Sage, mathics. None of them feel quite right though.
I once had fantasies about starting an open source project for Common Lisp that would attempt to implement a little bit of the Wolfram data display stuff. I stopped paying for LispWorks, so I no longer have CAPI for GUIs, so that is not going to happen. Racket’s UI support would make Racket a good platform for an open source project like this. (I won’t work on it, LLMs are so much more fascinating than any other tech, and use up my free time).
I did recently pay for an entire year of Wolfram Desktop in the hope of really getting into it. I have code experiments for all the stuff I love (machine learning, deep learning, LLM, semantic web, etc.) but to be honest using the Wolfram Language does not give me the joy that I get using Common Lisp,and various Schemes, and, for some things Python is the most practical language.
i bought a year sub to the “deluxe” pack of mathematica for like 300usd. it was pretty good, but one glaring weakness is lack of lazy streams. This came to my attention when i attempted problem 7ish in project euler, which asked something like “sum all the fibonacci numbers less than a million” or something. Woulda been perfectly elegantly done in Haskell using a stream and only TAKEing what I needed, but in mathematica I need an imperatice monstrosity using Do, For, While, etc. I was absolutely disgusted and didnt bother renewing.
racket is also one of the very few free lisps with a visual debugger and stepper, which is crazy when you realize how widely available that is in modern languages
Most likely because they got students to implement that for their thesis work, and free Common Lisp are seldom used for thesis stuff.
Like in many free tooling most people rather do with what they have instead of improving them, hence why all great developer experiences are either commercial or corporate sponsored.
I have also have a soft spot for Racket, although professionally I lean on Common Lisp to get stuff done.
The once a year RacketCon conference was two weekends ago, and in addition to the technical talks, I enjoyed hearing the 4 academics who are primary implementers and maintainers taking questions from the audience about why Racket is not targeted at industry. I am just finishing up writing a Racket book, that really just consists of my own little code experiments (no big deal). You can read it free online https://leanpub.com/racket-ai/read
> I enjoyed hearing the 4 academics who are primary implementers and maintainers taking questions from the audience about why Racket is not targeted at industry.
That's interesting. That seems like a flip from a few years ago. What was the summary regarding this?
My understanding of what the 4 academic devs were saying: Racket is a rich environment for language experiments, academic work, and is attracting some interest in wider commercial use. I think they hope that more 3rd parties do some of the work for supporting industrial applications. I didn’t take notes of the panel discussion, but this is how I remember the dialog.
The question came from a young member of the audience.
It was phrased something like:
"Why isn't Racket used in industry like OCaml is used by Jane Street."
And what can you answer to that? Of course the Racket would like for some both commercial users as well as sponsors.
In fact [1] Racket changed its license from LGPL to Apache 2.0 or the MIT license to make sure it can be used commercially.
The fact is that language popularity isn't determined by quality of language/implementation alone. Having companies like Apple (Swift) and Google (Go) backing a language helps tremendously.
The major issue Racket has is the same one other functional languages have: its hard to find any developers who know those languages or are willing to work in them. There are compelling arguments for functional programming[0] and I enjoyed programming in both Racket and Chez Scheme in college but I never bothered putting it on my resume because functional programming isn't widely used.
The corporate world is mostly obsessed with OOP to the extent that every new imperative/procedural language like Go or Rust has to pretend to be OOP to get corporate adoption. Functional languages can't pretend to be OOP so they can't get past the corporate filter except at a handful of firms that use them for competitive advantage.
It also isn't easy to get the few functional programming jobs that do exist because they're often looking for developers who already have professional functional programming experience and that isn't easy to get unless you're already at a company that uses functional programming.
[0]: One of the most compelling pro-functional programming arguments is this one which argues that mutable state (being able to alter a variable's value after you set it) and variables being able to be null are harmful like GOTO statements: https://spectrum.ieee.org/functional-programming
I don't have notes of what I said (recording will be up soon) but that isn't what I was trying to say at all. We value use in industry and have made significant effort to enable it (like relicensing everything). It is true, of course, that we're academics, and so we need to learn from others about how to better enable industrial use of Racket, but that is not because we don't care about it.
I'm sure there is this one person who builds a webdev ecosystem in racket. sorry, can't really recall his name. I'm pretty sure he has a lot of valuable input.
What I said was (in part) "I am sure there are ways we can improve to attract people inside of academia, outside of academia, in open source, in commercial development, and we want to improve in all of those ways".
Apropos nothing, can we get SICP added to SCP? I’ve always thought it would be a fantastic entry. "Artifact SCP-31415, code name SICP, is a book on an obscure programming language. Students have been observed to die of fright when confronted with it, and those that escape have visible scars from what appear to be tiny blade-like curved objects. Some, however, end up becoming superstar programmers; therefore it’s been an object of fascination for the ages…"
Is any software of note built on top of either software? All i can think of are these forums which, while enormously culturally influential, seem unremarkable from a technical perspective.
Even though your question is a bit pointed, I think it is worth understanding what software is built upon Chez and Racket. The answers would be instructional to everyone. Here is some stuff, that I _do_ know -- there is probably a lot more usage in the wild:
Racket is used extensively in education and research relating to Scheme and programming languages in general. Lots of work on gradual typing, programming language semantics comes out of the Racket community. Many colleges around the world use Racket. Scheme/Racket is very pared down language and lends itself to this kind of work -- the principles of whatever you are studying shine through quite easily in a way that it may not if you were using C, Rust, Python etc. in the problem domain.
As noted elsewhere in the comments, Idris 2, an important dependently typed language outputs to Chez/Racket Chez. Previously it output C code which was then compiled.
In general, Chez is probably a great language to use as a "base". It lends itself to embedding and is performant. Lua and some Javascript implementations come to mind as comparables. In general, we might not know much about Chez being used a lot in the wild because it could be tucked deep into various proprietary company products.
I do not know why Cisco hired Kent Dybvig, the prime designer/implementer of Chez Scheme, or why they chose to host its repo. I suspect that answering this question would reveal significant production programs written using Chez Scheme.
In the way those Dyson bladeless fans pull more air through. In your case, many folks know you (some from UIUC too like me) and know your upvote is worth reading, ending up upvoting too.
My point, based on the assumption that indeed Arc runs on an old Racket version, is that it doesn't serve as a good example, in my mind, in terms of what you could build with Racket today.
This is a quite common pattern in the Lisp and Scheme world where examples of real world usage are given, but they're effectively outdated.
Racket has a strong respect for back compatibility, so it should work in the current version. There has been a lot of improvements in the compiler (in particular changing the "back end" from C to Chez Scheme) but it's stil back compatible and sligthly faster.
Arc mutates inmutable pairs (cons), it worked initially because at the C level mutable and immutable pairs were the same struct. Now there is a primitive unsafe-set-immutable-car! [1] for cases like this. It's a weird primitive and should be used with a lot of care as explained in the docs.
[Another try in case this is the type of answer you wanted.]
In Racket the batteries are included. Two examples of programs I had to write like two years ago for work:
* 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.)
In both cases, and all the features were installed by default. There are many user defined libraries that can be downloaded as packages, but I didn't need to use them.
For what it's worth, I am actually a fan of Racket, or at least was. It's what I reach for when I want a Scheme. But I lost enthusiasm for the language when the Rhombus project was announced. I now mainly use F# and Elixir for my side projects. Racket doesn't really provide anything over those two languages for most use cases.
And it's tough to get support as there's very few people who know the stack well enough, and those people are the busiest and also professors, so their time is limited.
Which are the three things you would miss the most if you had to use Racket? It's interesting to know the pain points.
For support you can ask in https://racket.discourse.group/ , most questions are answered the same day. I don't know if someone is available for consulting/hiring.
That's hard to say. Racket is a rather complete language, as is F# and Elixir. And F# and Racket are extremely capable multi-paradigm languages, supporting basically any paradigm. Elixir is a bit more restricted in terms of its paradigms, but that's a feature oftentimes, and it also makes up for it with its process framework and deep VM support from the BEAM.
I would say that the key difference is that F# and Elixir are backed by industry whereas Racket is primarily backed via academia. Thus, the incentives and goals are more aligned for F# and Elixir to be used in industrial settings.
Also, both F# and Elixir gain a lot from their host VMs in the CLR and BEAM. Overall, F# is the cleanest language of the three, as it is easy to write concise imperative, functional, or OOP code and has easy asynchronous facilities. Elixir supports macros, and although Racket's macro system is far more advanced, I don't think it really provides any measurable utility over Elixir's. I would also say that F# and Elixir's documentation is better than Racket's. Racket has a lot of documentation, but it can be a little terse at times. And Elixir definitely has the most active, vibrant, and complete ecosystem of all three languages, as well as job market.
The last thing is that F# and Elixir have extremely good notebook implementations in Polyglot Notebooks (https://marketplace.visualstudio.com/items?itemName=ms-dotne...) and Livebook (https://livebook.dev/), respectively. I would say both of these exceed the standard Python Jupyter notebook, and Racket doesn't have anything like Polyglot Notebooks or Livebook. (As an aside, it's possible for someone to implement a Racket kernel for Polyglot Notebooks, so maybe that's a good side project for me.)
So for me, over time, it has slowly whittled down to F# and Elixir being my two languages that I reach for to handle effectively any project. Racket just doesn't pull me away from these too languages as it doesn't really offer anything over them, and I would also say that Racket is a bit too locked to DrRacket. I tried doing some GUI stuff in Racket, and despite it having an already built framework, I have actually found it easier to write my own due to bugs found and the poor performance of Racket Draw. However, I do reach for Racket anytime I want a Scheme for learning purposes.
I agree that sometimes the docs of Racket are complete but too short. When I had to write code to download a webpage, I had to guess how to use the 10 arguments of the functions, in particular how to split https://www.example.com/here/thispage.html I think that the docs of PHP has a huge collection of user submitted examples, that sometimes are good and sometimes are bad, but most of the times there is one that saves you a lot of time.
Porting Racket to the the CLR and BEAM (and JVM) would be nice. I'm not sure the garbage collectors have all the necessary support for weird stuff like weak boxes and ephemerons. IIRC ephemerons were backported from the Racket fork to Chez Scheme a few years ago.
A Jupyter-like interface would be nice. My wife is using Python in Google Colab an she loves it. About the Racket kernel in Polyglot: Should it be written in some CLR language or it can be a thin wrapper around the main Racket executable?
Edit:
I searched in Discourse, and I found these two posts about using Racket in Jupyter.
It's been a bit since I looked at this last, but the notebook kernel would be written in a .NET language but can freely defer to whatever else underneath the hood. So F# could provide the glue to the notebook interface while deferring to some Racket server, such as a REPL server. I might investigate this myself.
Racket today and for several years now has already been using Chez Scheme, so any of the latest versions you download will be built that way. On all platforms. So, just download away, and you're good to go.
Rather, this announcement is about going the other way around, and about merging changes back into Chez: when Racket was migrated to Chez several years ago, as a matter of practicality they had to fork it and significantly modify it to maintain feature parity with the existing implementation. The changes were very large; multiple new supported ISAs and ABIs, new compiler optimizations, an entirely new build system, etc. For years, nobody was totally clear about what would happen with this fork, but the hope was that it would all go back to the upstream Chez codebase. That is finally happening, and so this post is not about merging code from Chez into upstream Racket, but rather merging code from Racket back into upstream Chez.
The hope is changes will soon be available as a new major Chez Scheme release, version 10.0, and so the fork and the upstream version will finally be unified. (Racket will likely continue to use its own fork of Chez scheme as a practical matter of engineering, but presumably it will only need very minor tweaks and small patches, if any, for it to work.)
Cisco bought Kent Dybvig's company some years back and open sourced Chez Scheme (they likely have more profitable products than a performant Scheme compiler and don't need the thousands they could make on such a product).
Does this mean that the Racket and Chez teams will merge as well? I always liked Racket, and use it on spare time once in a blue moon (not enough hours in the day), but I am out of the loop on Chez vs Racket.
It means that Matthew Flatt will become a committer to Chez Scheme, and they plan to include Racket-driven changes. Of course, we plan to maintain Chez Scheme's high standards for quality and preserve all the things about it that are good outside Racket as well.
Thanks for the insight! I love Racket, I just never have enough time for it. I read parts of Realm of Racket some years back, and it taught me some CS concepts that I forgot after college, which have stuck with me, and have helped me answer questions in interviews weirdly enough. I wish CS was taught in the context of "let's make a game" as one option because learning the concepts in such a way for some (like myself) is fantastic, you'll never forget it.
Wasn't chez scheme the dialect that let you compile scheme code at runtime as a first class thing? I remember looking into this stuff when I had it in my idea to make a configurable text editor.
It is certainly not new. There are some things that Racket doesn't allow, but they are very much not "compile new code". For example, you can't replace the meaning of existing modules at runtime, nor can you modify the implementation of functions that are on the stack already (both things that some runtime systems for some languages allow). But `eval` has been there since the beginning.
Consider the case where a compiler compiles Scheme to C via C.
The C compiler is available at compile time, but who knows
if the user has a C compiler. Such compilers often solve the
problem by using some kind of interpreter at runtime.
Compilers that compile directly to machine code do not have similar problems.
For fun, do you know a Common Lisp implementation that compiles via C?
How do they implement `eval`?
Yes that's an obvious problem, but manageable I suppose by installing a toolchain or insisting on one when you install.
The post I was replying to was about scheme's in general though, not scheme->c implementations, right? Anything with an intermediate language or machine language output avoids this problem...
At any rate, the CL's I've used most have native compilers. I think GCL is CL via c, but can't remember the details of its implementation. In any case 'eval and 'compile are not equivalent, and the system may change whether or not 'eval compiles first or just interprets, depending on settings.
As you point out, it's quite common for Common Lisp compilers to produce machine code directly. In the Scheme world that's more rare and made Chez Scheme stand out. I think, that's what LAC-Tech hinted at - but I am not sure.
I've guess I've used MIT and Chez which were native, and chicken and bigloo which are (from memory) going via c. So maybe biased my feeling that native wasn't that unusual. But yes, imprecision in the original may have caused confusion.
Not sure how complete that list is, but that has 4 native compilers and 3 scheme-to-c, which I guess leaves the other dozen or so interpreted, but that gets muddied with intermediate languages and retargetable (e.g. gambit).
I'm not sure what is meant in this thread by “interpreter”. A Scheme compiler that transpiles to C or JavaScript might “interpret” if neither of these systems is available at runtime. In general, apart from student-written course projects, Scheme systems do some level of compilation (e.g., identifying variables), because this is relatively easy to do, and avoids wasting execution time. Most if not all production Lisp and Scheme systems, if they interpret at all, do so by compiling to an intermediate representation, and interpreting that.
Lisps that are based purely on compilation implement (eval form) similarly to this:
(funcall (compile nil `(lambda () ,form)))
Lisps that are not based purely on compilation can have an eval function that walks the source code and interprets it. Or there could be a VM.
So the question is really, how do Lisps that compile to C implement the dynamic compile function? Typically it's all part of the same framework as file compilation.
There is a run-time dependency on the C compiler: for run-time compile to work, it has to be installed. The compile function writes something to a file, or perhaps a pipe. The compiler is invoked and produces a .o file; the function then loads that into the image and bind it to a funcall-able object.
It's a dependency that's a bit hard to swallow, since a C toolchain is hundreds of megabytes nowadays.
103 comments
[ 3.7 ms ] story [ 150 ms ] thread(This current submission is really nice; you get to hear more from Matthew about what’s going on.)
Chez Scheme (pronounced “shay-scheme”) is the most performant and compliant Scheme implementation out there. [1] For a long time it was closed-source, but was recently open-sourced.
It now forms the foundation of the Racket language. (So, I guess that means HN relies on it, provided Arc is using a recent version of Racket.) I asked Matthew why he picked Chez to base Racket off of, and I want to say that he picked it because it implemented continuations really really well and had a good garbage collector too. I could be wrong.
[1]: https://ecraven.github.io/r7rs-benchmarks/
(Maybe I'll find a way to resume using Scheme/Racket. The last few years, I've been using Python, JS, and Rust, partly for employability reasons. They have their merits, but I'm aware of what I'm missing.)
https://docs.racket-lang.org/sicp-manual/
(SICP Scheme isn't quite standard, and there's also some SICP-specific libraries.)
[1] Example gif: https://docs.racket-lang.org/define-attributes/examplecodear...
[2] > Lexical Structure: The lexical structure is shown with arrows overlaid on the program text. When the mouse cursor passes over a variable, DrRacket draws an arrow from the binding location to the variable, or from the binding location to every bound occurrence of the variable.
(so, not much chance of adding that to my Chez extension ;)
I have had the pleasure if witness a couple Matthew Butterick talks first hand and they are excellent. He is a great speaker and thinker. I have also seen the subject the article lose his cool a couple times. Which is not cool. Esp given his prominent place in the community. At this point and think he should make himself a bystander.
If you don’t mind Smalltalk, the modern Pharo ecosystem is also amazing.
Just like Notebooks are miles away from that experience, and yet they allow millions of programmers to have an experience that wouldn't have otherwise, even with Lisp Machines/Interlisp-D providing a much better one.
What do you think is inspired by some Lisp Machine? REPLs existed before. Editors existed before. IDEs existed before. Lisp IDEs existed before. For example Interlisp had a Lisp IDE in the early 70s, long before it was morphed into something like a Lisp Machine with Interlisp-D.
It would allow you to define variables which were actual images. The image was a thumbnail in the code, which you could assign and print. It was mind blowing.
Also your Lambda keywords could be replaced with an actual Lambda symbol, which was the pinnacle of coolness.
This, as well as the super snappy and responsive split REPL, made the overall development experience with Scheme feel super futuristic and just a pure enjoyment all around.
What's missing from my life is a good FOSS equivalent. There are several wonderful tools which do similar things, e.g. Jupyter, org-babel, TeXmacs, Sage, mathics. None of them feel quite right though.
I did recently pay for an entire year of Wolfram Desktop in the hope of really getting into it. I have code experiments for all the stuff I love (machine learning, deep learning, LLM, semantic web, etc.) but to be honest using the Wolfram Language does not give me the joy that I get using Common Lisp,and various Schemes, and, for some things Python is the most practical language.
Like in many free tooling most people rather do with what they have instead of improving them, hence why all great developer experiences are either commercial or corporate sponsored.
GNU Emacs disagrees.
I know Eight Megabytes of Continuous Memory Swap since those 8MB actually mattered.
It's "Eight Megabytes And Constantly Swapping".
Someone said they might be possible with CodeMirror https://codemirror.net/
(Just in general - not specifically for racket- I’d love to see this for rust and elixir)
They are possible, but not using the "normal" editor window, you need a "custom" one: https://code.visualstudio.com/api/extension-guides/custom-ed...
The once a year RacketCon conference was two weekends ago, and in addition to the technical talks, I enjoyed hearing the 4 academics who are primary implementers and maintainers taking questions from the audience about why Racket is not targeted at industry. I am just finishing up writing a Racket book, that really just consists of my own little code experiments (no big deal). You can read it free online https://leanpub.com/racket-ai/read
That's interesting. That seems like a flip from a few years ago. What was the summary regarding this?
"Why isn't Racket used in industry like OCaml is used by Jane Street."
And what can you answer to that? Of course the Racket would like for some both commercial users as well as sponsors.
In fact [1] Racket changed its license from LGPL to Apache 2.0 or the MIT license to make sure it can be used commercially.
The fact is that language popularity isn't determined by quality of language/implementation alone. Having companies like Apple (Swift) and Google (Go) backing a language helps tremendously.
[1] https://blog.racket-lang.org/2019/11/completing-racket-s-rel...
The corporate world is mostly obsessed with OOP to the extent that every new imperative/procedural language like Go or Rust has to pretend to be OOP to get corporate adoption. Functional languages can't pretend to be OOP so they can't get past the corporate filter except at a handful of firms that use them for competitive advantage.
It also isn't easy to get the few functional programming jobs that do exist because they're often looking for developers who already have professional functional programming experience and that isn't easy to get unless you're already at a company that uses functional programming.
[0]: One of the most compelling pro-functional programming arguments is this one which argues that mutable state (being able to alter a variable's value after you set it) and variables being able to be null are harmful like GOTO statements: https://spectrum.ieee.org/functional-programming
What I said was (in part) "I am sure there are ways we can improve to attract people inside of academia, outside of academia, in open source, in commercial development, and we want to improve in all of those ways".
https://github.com/KingMob/SCP-061
Racket is used extensively in education and research relating to Scheme and programming languages in general. Lots of work on gradual typing, programming language semantics comes out of the Racket community. Many colleges around the world use Racket. Scheme/Racket is very pared down language and lends itself to this kind of work -- the principles of whatever you are studying shine through quite easily in a way that it may not if you were using C, Rust, Python etc. in the problem domain.
As noted elsewhere in the comments, Idris 2, an important dependently typed language outputs to Chez/Racket Chez. Previously it output C code which was then compiled.
See: https://en.wikipedia.org/wiki/Racket_(programming_language)#...
In general, Chez is probably a great language to use as a "base". It lends itself to embedding and is performant. Lua and some Javascript implementations come to mind as comparables. In general, we might not know much about Chez being used a lot in the wild because it could be tucked deep into various proprietary company products.
* https://franz.defn.io/
* https://remember.defn.io/
* https://defn.io/2023/08/10/ann-franz-source-available/
HN itself runs on Racket.
In the way those Dyson bladeless fans pull more air through. In your case, many folks know you (some from UIUC too like me) and know your upvote is worth reading, ending up upvoting too.
Isn't it an ancient version of Racket, though?
This is a quite common pattern in the Lisp and Scheme world where examples of real world usage are given, but they're effectively outdated.
[1] https://docs.racket-lang.org/reference/unsafe.html#%28def._%...
In Racket the batteries are included. Two examples of programs I had to write like two years ago for work:
* 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.)
In both cases, and all the features were installed by default. There are many user defined libraries that can be downloaded as packages, but I didn't need to use them.
And it's tough to get support as there's very few people who know the stack well enough, and those people are the busiest and also professors, so their time is limited.
For support you can ask in https://racket.discourse.group/ , most questions are answered the same day. I don't know if someone is available for consulting/hiring.
I would say that the key difference is that F# and Elixir are backed by industry whereas Racket is primarily backed via academia. Thus, the incentives and goals are more aligned for F# and Elixir to be used in industrial settings.
Also, both F# and Elixir gain a lot from their host VMs in the CLR and BEAM. Overall, F# is the cleanest language of the three, as it is easy to write concise imperative, functional, or OOP code and has easy asynchronous facilities. Elixir supports macros, and although Racket's macro system is far more advanced, I don't think it really provides any measurable utility over Elixir's. I would also say that F# and Elixir's documentation is better than Racket's. Racket has a lot of documentation, but it can be a little terse at times. And Elixir definitely has the most active, vibrant, and complete ecosystem of all three languages, as well as job market.
The last thing is that F# and Elixir have extremely good notebook implementations in Polyglot Notebooks (https://marketplace.visualstudio.com/items?itemName=ms-dotne...) and Livebook (https://livebook.dev/), respectively. I would say both of these exceed the standard Python Jupyter notebook, and Racket doesn't have anything like Polyglot Notebooks or Livebook. (As an aside, it's possible for someone to implement a Racket kernel for Polyglot Notebooks, so maybe that's a good side project for me.)
So for me, over time, it has slowly whittled down to F# and Elixir being my two languages that I reach for to handle effectively any project. Racket just doesn't pull me away from these too languages as it doesn't really offer anything over them, and I would also say that Racket is a bit too locked to DrRacket. I tried doing some GUI stuff in Racket, and despite it having an already built framework, I have actually found it easier to write my own due to bugs found and the poor performance of Racket Draw. However, I do reach for Racket anytime I want a Scheme for learning purposes.
I agree that sometimes the docs of Racket are complete but too short. When I had to write code to download a webpage, I had to guess how to use the 10 arguments of the functions, in particular how to split https://www.example.com/here/thispage.html I think that the docs of PHP has a huge collection of user submitted examples, that sometimes are good and sometimes are bad, but most of the times there is one that saves you a lot of time.
Porting Racket to the the CLR and BEAM (and JVM) would be nice. I'm not sure the garbage collectors have all the necessary support for weird stuff like weak boxes and ephemerons. IIRC ephemerons were backported from the Racket fork to Chez Scheme a few years ago.
A Jupyter-like interface would be nice. My wife is using Python in Google Colab an she loves it. About the Racket kernel in Polyglot: Should it be written in some CLR language or it can be a thin wrapper around the main Racket executable?
Edit:
I searched in Discourse, and I found these two posts about using Racket in Jupyter.
https://racket.discourse.group/t/racket-meet-up-saturday-7-m...
https://racket.discourse.group/t/running-racket-in-the-cloud...
(I'm too busy to help just now, and I never made the VB6 -> VB.net transition.)
[1] Assuming that the merge has happened since the announcement was on Oct 16
https://github.com/cisco/ChezScheme
There is more work to be done before release 10.0.
Rather, this announcement is about going the other way around, and about merging changes back into Chez: when Racket was migrated to Chez several years ago, as a matter of practicality they had to fork it and significantly modify it to maintain feature parity with the existing implementation. The changes were very large; multiple new supported ISAs and ABIs, new compiler optimizations, an entirely new build system, etc. For years, nobody was totally clear about what would happen with this fork, but the hope was that it would all go back to the upstream Chez codebase. That is finally happening, and so this post is not about merging code from Chez into upstream Racket, but rather merging code from Racket back into upstream Chez.
The hope is changes will soon be available as a new major Chez Scheme release, version 10.0, and so the fork and the upstream version will finally be unified. (Racket will likely continue to use its own fork of Chez scheme as a practical matter of engineering, but presumably it will only need very minor tweaks and small patches, if any, for it to work.)
I know racket is very static in this regard.
IIRC every lisp and scheme I've used has supported this. It's pretty typical, but not universal.
But some implementations use an interpreter for evalulating code at runtime. ChezScheme uses the compiler.
What I was saying is that every implementation I have used did this, not that all of them do. It seem common.
FWIW I've done a lot more CL than scheme, though.
Compilers that compile directly to machine code do not have similar problems.
For fun, do you know a Common Lisp implementation that compiles via C? How do they implement `eval`?
The post I was replying to was about scheme's in general though, not scheme->c implementations, right? Anything with an intermediate language or machine language output avoids this problem...
At any rate, the CL's I've used most have native compilers. I think GCL is CL via c, but can't remember the details of its implementation. In any case 'eval and 'compile are not equivalent, and the system may change whether or not 'eval compiles first or just interprets, depending on settings.
[update] I was curious, so had a look at https://get.scheme.org/
Not sure how complete that list is, but that has 4 native compilers and 3 scheme-to-c, which I guess leaves the other dozen or so interpreted, but that gets muddied with intermediate languages and retargetable (e.g. gambit).
On a different tangent, I am suddenly reminded of:
https://blog.racket-lang.org/2011/10/on-eval-in-dynamic-lang...
So the question is really, how do Lisps that compile to C implement the dynamic compile function? Typically it's all part of the same framework as file compilation.
There is a run-time dependency on the C compiler: for run-time compile to work, it has to be installed. The compile function writes something to a file, or perhaps a pipe. The compiler is invoked and produces a .o file; the function then loads that into the image and bind it to a funcall-able object.
It's a dependency that's a bit hard to swallow, since a C toolchain is hundreds of megabytes nowadays.