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.
Still have core memories of doing assignments in Racket with the Dr. Racket IDE
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.
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.
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.
I look forward to using the new threading.
Racket is only hard if it's not your first language. Kids can also learn it.
His keyboard sounds amazing too. Buttery smooth pearls.
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.
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 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.
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).
> [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-...
Students might use some simplified or customized languages produced with Racket. The syntax needs not be lispy; #lang algol60 is built in :)
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.
I don't know if the strong students had the intended approach since they were never in office hours asking for help!
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.
"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.
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.
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.
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.
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.
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.
Solaris LWP and Windows Fibers were two other examples of OSes providing the infrastructure for a task based programming, although they had some issues.
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.
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).
* 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.)
Because its on top of Racket, you get usual high-level language faculties for basically free.
