As an imperative, stateful and even sometimes OOP developer, always finding functional programming very elegant but never really using it for real, Racket was the Lisp dialect that finally hooked me in.
I think the reason was because it came with batteries included and I could create complex applications using only the standard library or very few packages.
I know some Lisp/Scheme, but never really did any projects in it. What did you use to learn Racket (both the language and the ecosystem)? If I had to read a single book/tutorial, what will give me the most bang for my time?
I tried reading the official docs, but while they're great for reference, probably not the best in terms of tutorials/learning.
Complex applications was probably an overstatement but I've created featureful IRC and Discord bots, a database management application and right now I'm creating a graphical browser for the Gemini protocol.
All my other previous attempts at using functional languages, like for instance Haskell, ended up in trivial applications, usually based in numerical analysis.
It's in a very early stage, because I'm porting it from a previous Python code base, so it's not yet available. That said, I'll leave here two links for Racket software that inspire me.
1. Gemini server with tons of features, that I use personally:
My latest project was: Get some emails using IMAP, login to my site, find and scrap some data related to the sender of the email, and send a reply using SMTP. The logic is not very complicated, it uses 4 or 5 of the standard libraries and I avoid writing a hundred emails per day.
Python has described itself as a "batteries included" language for many years -- Python was the language that popularized that term for describing programming languages. So I don't think your personal definition of that term (easy executables) is universal. Everything I can find online indicates that it refers to the wide capabilities of the language's standard library.
I don't think parent's definition of "batteries included" is as narrow as you're suggesting, and I also think yours is too narrow.
It's a claim that the standard language distribution is sufficient to accomplish common goals of new users, without hunting down additional libraries or tools.
As you say, the Python community coined the term, but their notion of its meaning perhaps slants a little too far towards their language distribution's strengths (standard library) and maybe suffers from lacunae towards their language distribution's weaknesses (a clearly-articulated way to create a GUI executable using the standard language distribution).
For one, it has a platform-independent GUI library as part of the standard library, which Python (like most other programming languages) hasn't. That makes it interesting for writing GUI applications or using it for experimental programs which might require )or benefit from) a GUI later.
Racket has also a standardized package management, which is much easier to use than the different Python facilities.
Racket has a much better performance compared to Python and that in turn makes it possible to implement many algorithms directly in Racket which would be a C extension in Python, which makes it more complex to use them.
Another thing is that Racket, as a member of the Lisp family, has also a deep low-level support. For example, it supports multi-threading with both green threads and os-level threads, futures, synchronization, making it possible to write parallel algorithms, which isn't practically possible in standard Python.
> The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects.
I scripted in C for the longest time, after thousands of lines it was in muscle memory, and I could reuse boilerplate. I was profoundly embarrassed to then discover Perl; I felt late to the party, like I'd thawed out of a glacier.
Then Python, which stuck. I tried various lisps, Haskell, Ruby, Lua for scripting, and kept returning to Python.
I realized Python was truly boring, and I needed scripting to be fun, to keep my interest up. I relearned Ruby. Ruby is fun.
I had three worksites and I also had a few pet projects that would go on 100 computers. Python failed at every level (So did Haskell). I learned Racket just to improve my programming (It did) I then was like let's see how Racket works and it worked perfectly. I was able to deploy my programs and I never had an issue.
While I don't work with Racket much now, I will be eternally grateful for the concepts it taught, functional programming, recursion through the little schemer, how to design programs and break them up into small chunks, and writing tests. Gradual typing allowed me to make my programs more robust, and the type checking built into typed Racket helped catch errors without having to run a separate utility like mypy.
The community isn't the largest, but you can still get an answer to the questions that you have, and having a GUI built in the standard library (which is rare amongst Schemes) allowed me to do some pretty cool things like implement Conways game of life https://gitlab.com/diegocrespo/conways-game-of-life/-/tree/m....
I've been keeping an eye on Racket for a few years now, and recently gave their documentation tool Scribble[1] a try, as an alternative to writing LaTeX directly. But honestly I found the experience difficult if you need some custom behavior, and falling back to Racket was very confusing as a relative newcomer to Lisp (with mostly Elisp experience). It doesn't help that their documentation, while detailed, is not very beginner friendly. So I went back to org-mode for exporting to PDF via LaTeX.
Pollen [1] is pretty neat, it's amazing what Matthew Butterick has done with it to create his books. Beautiful Racket [2] truly is beautiful and inspiring.
You're not kidding, that's probably the most beautiful book in HTML I've ever seen. The typography is gorgeous, the navigation is intuitive and easy to use, downloadable code samples, links for every paragraph with a feedback form (!), and the writing style is clear and approachable.
It's definitely on my to-read list. Thanks for sharing!
I did the exact same thing, trying for a better LaTeX. But my experience was different: I found it very easy to customize and programmatically generate content. However, I have used Racket and lisps/schemes before, so that is likely the difference. I encourage you to try programming with Racket outside of Scribble to get a better handle on it!
I gave up creating anything with scribble or pollen, not sure which one it was, when I had the nagging urge to change the font and could not figure out how to do that. Composing different parts of the document was OK, but I simply could not find anything about changing the font. I am sure, if I had asked, I would have gotten an answer, but in that moment, it killed my motivation to get into it further.
Probably Scribble, which is pretty opinionated. Pollen basically gives you tools to design your own markup and makes no assumptions about the published result.
If anyone missed it, Racket has finally (it has been planned and worked for few years now) moved by default to Chez Scheme (ie Racket CS) on v8.0 (Feb 2021) which has improved in most cases performance.
I think the aim was more for supportability.
I assume if you enjoy Scheme; you would like to write more of your language in Scheme and less of it in C.
Although that is somewhat contradicted by the plans to create a new syntax for Racket going forward.
Chez Scheme by itself seems to be extremely fast.
Yes, and now, after three year and countless hour spent the new version (RacketCS) is running slower than the old one! Congratulations to Racket development team - well done! :)
Benchmarks beg to differ: https://blog.racket-lang.org/2021/01/racket-status.html. But those may be (being the official ones) biased, so a third-party running them will be nice. Also performance wasn't the only reason. Maintainability and easier development were as well, which for language like Racket, I believe, are more important.
IIRC the benchmarks is the union of few benchmarks sets that were floating around, like some usual benchmarks for Scheme implementations [1] and old versions of the The Computer Language Benchmarks Game [2]
gus_massa knows this, but building Racket from source (which is basically just running a lot of Racket code) is now faster with Racket CS than with Racket BC.
For me, Racket will always be the language used to create the best programming pun of all times:
> Write your next Ethereum Contract in Pyramid Scheme
> I create Pyramid: A dialect of the Scheme programming language that targets the Ethereum Virtual Machine(EVM). Pyramid Scheme is implemented using the appropriately-named Racket.
I think Racket is the only modern lisp which has a sufficiently large community. What, if any, do you think should be the flagship project for introducing Racket?
Interestingly you're writing this on a forum which runs on (or used to run?) on Racket. HN was written in Arc[0] which was implemented atop Racket[1]. And that's a good example case of using Racket as it is proponent of language-oriented programming[2].
Writing a domain-specific language on Racket is kinda Racket's main selling point. If you don't trust me, you can trust the people who made Arc and HN. Afterall back in 2007 you had other options. Some of them vastly popular even now (Rails, Django, PHP, Scala, ...).
I think both Clojure and Common Lisp are modern lisps too, both have large user communities. Common Lisp is mostly different in that it is much more agnostic than Scheme, for example it as no constraints in using imperative patterns. On the other hand, it also has acquired libraries for purely functional data types, which is one of the main innovations of Clojure.
Pollen is just a very extensible and composable slate for you to compose content. Under the hood, Pollen may be equivalent to the Scribble language without the fixed export structures and styles.
That the outputs look very good may be correlated with the author and other prominent users caring for typography and web delivery.
As-is, my impression is that generation of multiple pages seems slower than scribble/manual, but the community has been exploring use of databases to speed up caches. In this respect, I've been eyeing the work of this member in particular: https://github.com/otherjoel
All this speaks very good of the seemingly limitless flexibility of the Racket ecosystem.
So do I. However, whenever I think of changes I would like to do to guile I end up with a language a lot closer to racket... Immutable pairs, immutable hash tables, immutable strings (which racket has not), user extensible pattern matching and a proper looping facility (preferrablymore powerful than rackets).
Add to that some better facilities for mixing languages and it is a very nice language that is very close to racket. Yet for some reason I find guile more fun.
Yeah. I should have been more clear. I meant as the default. There are all kinds of nice optimizations that can be done with immutable strings compared to mutable ones. Which I probably don't have to tell you, Gustavo :) I have been reading every patch you have made to chez, not understanding half of it but loving every moment.
There are some very valid reasons [1] why we should stay away from Racket: toxic community, toxic people... And come on: no one has ever really used Racket to write some decent nontrivial web application, documentation is awful (and, please, don't count HN here, cause HN is written in Arc).
Could you please stop creating accounts to post like this? I realize you have some strong opinions about Racket. I have no doubt that there is some truth in there. But what you're doing here is absolutely not what this forum is supposed to be for, and you're hurting it. If you would please stop, we'd be grateful.
He acknowledged that Racket has excellent documentation, a wide-ranging toolset, etc. All the good stuff you've heard elsewhere.
He criticizes the language-oriented model (in comparison to languages that people are familiar with but that allow embedded Deals, like Lua or Ruby) because creating a new DSL is antithetical to code that communicates with other programmers. This is fair, and a common criticism of Lisps: the complete freedom of the macro system means that individual programmers can create their own dialects quite easily, and other users of that code have a harder time working with it than in languages where there's not as much metaprogramming.
On the "toxic" front, one of the core team apparently asked a waitress a cringy question about higher education, referred to some other educators (at the creator's institution) as doofuses and the like, and was arrogant.
And at the end of it all, though he doesn't see a use for Racket's language-oriented model, he recommends learning and using it.
because creating a new DSL is antithetical to code that communicates with other programmers.
DSLs communicate wonderfully with the business users paying for the program. It also allows a programmer to match the jargon / industry speak used by the users.
I know that Cadence's ASIC design tools are based on a custom Lisp dialect. I've seen a presentation at a Lisp conference from an architect who was representing myriad building regulations as Lisp expressions e.g. minimum clearance between toilet and bathroom door. There was another presentation about Lisp software for simulating aircraft engine performance based on various input parameters.
I don't know how close these applications are to Racket's ideal but I imagine they're somewhere on that spectrum.
I've seen a presentation at a Lisp conference from an architect
If you start talking to older architects and civil engineers who where active in the early to mid 90s, you'll be surprised how many of them know (or at least knew) Lisp.
Not Racked based, but I'd say Cucumber/Gherkin. Yes it is absolutely overkill for small teams, but if you have a dedicated person who is not really a programmer but who is managing requirements between the developers and the stakeholders, Cucumber is amazing in that scenario.
The ones I know of are locked in corporate IT departments, but Zed Shaw in his "The ACL is Dead" talk[1] from 2008 describes the use of one in relation to permissions on documents with rules specified in the DSL.
> He criticizes the language-oriented model (in comparison to languages that people are familiar with but that allow embedded Deals, like Lua or Ruby)
Oh, I whish ruby had a more formal way to switch to DSLs - I love ruby, but can't stand meta-heavy/DSL-heavy subsystems. The rspec test system is a prime example (saved to some small degree by its excellent and detailed documentation): https://rspec.info/
> On the "toxic" front, one of the core team apparently ... was arrogant.
An ingredient that may contribute to judgment of this video testimony, is that the same person that describes this toxic environment accuses someone providing a different personal impression of the community of engaging in "micro-agression" in the video comments.
Hey, you're improving! You actually modified your spiel instead of only copy/pasting the last iteration of your smear campaign like last time. Way to go :D
PS : what happened to the "you can't make a web app in Racket" part?
(The troll also acknowledges that Arc is a neat language— apparently, they think that racket is a terrible language to write bad applications, but I guess it’s good enough to write a language to write good web applications in!)
(I have heard a Racket described as the “second best programming language, the best programming language is the one you use Racket to build!)
Racket's documentation isn't something I've ever heard criticized. It's extensive, well-written, and even has various formats for users at different levels of familiarity. I don't think I've run into another language whose documentation gave me as much confidence.
I would say that racket has one of the best tutorials ever made for any language. Specially with the reduced versions inside DrRacket. Also some books like How to Design Programs.
How to Design Programs is maybe my all time favorite programming book. BUT it is incredibly dense and you can't go to it for your first book. Realms of Racket is a good one though.
Ok, GavinMcG, just try to write web application in racket, based on official documentation. I assure you that nothing will be clear to you, huge questions will just fly over your head, and if you then ask for help on the Racket group, the people there will make fun of you. Been there, done that! Believe me.
I watched this video (skimmed), it seems like the creator had a few incidents involving people in the racket community. I’m not a racket community participant or racket user, but every community has these issues. Honestly this feels like a really weird ax to grind against racket?
He's talking in measured terms about his own personal experience on his own personal vlog. It was probably cathartic for him (and for other people too.) No big deal.
It's not the most advanced IDE but it's good enough that I almost always use it when writing in Racket. Pretty much everything in the editor is set up so that languages implemented in Racket automatically get to take advantage of it which is really cool.
The repl is about on par with readline but with fancier output. Stuff like images and what racket calls "snips" are directly displayed in the repl. Snips implement their own rendering and interaction handling so you can do stuff like animation, plot charts, display an interactive map, etc. What I feel like it's missing is a way to collapse output/results like the console in firefox/chrome does and a way to reference the previous results (beyond just hitting the ctrl+up keybind) like in ipython.
There's a solid debugger and a tool to show each step of macro expansion if you need that while writing macros. Package manager is integrated into the editor. Autocomplete, syntax highlighting, auto indent/reinvent are all present and are fine.
It's got a bunch of little nice things like when you mouse over an identifier it draws an arrow to the where it was bound or required from a module. The reverse works too so you mouse over a binding/require and get arrows showing all the occurences. Another little thing is that it will automatically input the correct closing paren depending on context so if you're typing "(foo [bar (baz" and you then type ")" three times it'll input ")])".
What I find very nice with the IDE is that it can directly display images as function results.
That's useful for teaching but I think it might also be very handy for data visualization and symbolic representations. Perhaps even for debugging with complex data structures. I think this is a mayor innovation.
Here is an screenshot of the IDE and more info https://docs.racket-lang.org/drracket/interface-essentials.h... It includes syntax highlight (that is difficult because you can add your own syntax), online help, debugging, debugging of macros (that are the way to add your own syntax).
I can't talk about IDEs because I use Emacs for both languages, and it works well for me.
Clojure and Racket have quite a few similarities. They are both relatively minimal, and are both Lisp-1 (https://clojure.org/reference/lisps).
Racket as a Scheme has a stronger separation between compilation and run time, in order to maintain safe semantics. This has an effect on interactivity which is an important difference between Schemes and Lisps. It is easy to redefine a function in a running Clojure program and call into it without re-starting the whole program. In Racket, one does more often re-start a program.
Clojure is heavily opinionated towards functional programming. For example, all sequences are evaluated lazy, while Schemes do not do that by default. This is something it has in common with Haskell. But I also think this might be one of its many adaptations for use as a language in server and back-end environments, where sequences can become very large. These adaptations make Clojure very good for concurrency but less well-suited for true parallelism. It generates also slower code than Common Lisp.
Clojures standard implementation is tied to the Java virtual machine. This has advantages and disadvantages: A very large library of functions which programs can call into. Worse stack traces. Error reporting is limited in comparison to Common Lisp. No continuations like in Scheme. And it is much harder to call into C code when this is needed for speed, for for calling into system functions.
In Racket, it is easy to call into C code and to call into Rust code with C ABI. That means Racket can be used as a glue language, like Python (however it is not made for being embedded into C/C++ programs, that would be a flagship application for Guile).
Clojure programs have a large start-up time of potentially several seconds which is irrelevant for servers, but make int unsuitable for scripting (well, there is babashka, a Clojure implementation which improves on that https://github.com/babashka/babashka).
All in all, Clojure is fantastic for programming for the server and for concurrent tasks, and for learning functional programming.
Racket on the other hand is well suited for beginners, it has a large and well-rounded standard library and a lot of useful packages. It is easy to write a GUI with it, it is good for easy scripting, interacting with the OS, writing experimental algorithms, like Python very suitable as glue and so on.
Also, because Racket belongs to the Scheme family, if needed there is a whole host of Scheme implementations which can be used for any special needs, with very little change in the base language, so in that way Racket is one versatile power tool in a quite large tool shop.
There are also applications where I think Common Lisp is probably the best choice: Very mature implementations, very stable, availability of compilers which generate very fast code, especially a high performance in numerical algorithms, good imperative capabilities where they are needed, fastest start-up for scripts, very good documentation and books, independence from particular vendors or projects.
So it doesn't infer types for libraries not marked as `#lang typed/racket`? You need to write your own types like you would using a Javascript library from Typescript?
Edit: Found the relevant part of the docs[1], I like the automatic contract enforcement, although I guess it would be kinda hard to guess the perf impact...
I think the reason was because it came with batteries included and I could create complex applications using only the standard library or very few packages.
I tried reading the official docs, but while they're great for reference, probably not the best in terms of tutorials/learning.
All my other previous attempts at using functional languages, like for instance Haskell, ended up in trivial applications, usually based in numerical analysis.
1. Gemini server with tons of features, that I use personally:
https://sr.ht/~rwv/dezhemini/
2. Graphical Gopher browser:
https://github.com/erkin/gophwr
It's a claim that the standard language distribution is sufficient to accomplish common goals of new users, without hunting down additional libraries or tools.
As you say, the Python community coined the term, but their notion of its meaning perhaps slants a little too far towards their language distribution's strengths (standard library) and maybe suffers from lacunae towards their language distribution's weaknesses (a clearly-articulated way to create a GUI executable using the standard language distribution).
For one, it has a platform-independent GUI library as part of the standard library, which Python (like most other programming languages) hasn't. That makes it interesting for writing GUI applications or using it for experimental programs which might require )or benefit from) a GUI later.
Racket has also a standardized package management, which is much easier to use than the different Python facilities.
Racket has a much better performance compared to Python and that in turn makes it possible to implement many algorithms directly in Racket which would be a C extension in Python, which makes it more complex to use them.
Another thing is that Racket, as a member of the Lisp family, has also a deep low-level support. For example, it supports multi-threading with both green threads and os-level threads, futures, synchronization, making it possible to write parallel algorithms, which isn't practically possible in standard Python.
> The Python source distribution has long maintained the philosophy of "batteries included" -- having a rich and versatile standard library which is immediately available, without making the user download separate packages. This gives the Python language a head start in many projects.
https://www.python.org/dev/peps/pep-0206/
Then Python, which stuck. I tried various lisps, Haskell, Ruby, Lua for scripting, and kept returning to Python.
I realized Python was truly boring, and I needed scripting to be fun, to keep my interest up. I relearned Ruby. Ruby is fun.
http://www.randomhacks.net/2005/12/03/why-ruby-is-an-accepta...
The community isn't the largest, but you can still get an answer to the questions that you have, and having a GUI built in the standard library (which is rare amongst Schemes) allowed me to do some pretty cool things like implement Conways game of life https://gitlab.com/diegocrespo/conways-game-of-life/-/tree/m....
Congrats on the release!
[1]: https://docs.racket-lang.org/scribble/
[1] https://docs.racket-lang.org/pollen/
[2]: https://beautifulracket.com/
It's definitely on my to-read list. Thanks for sharing!
IIRC the benchmarks is the union of few benchmarks sets that were floating around, like some usual benchmarks for Scheme implementations [1] and old versions of the The Computer Language Benchmarks Game [2]
In particular you can see the comparison of "Racket" (aka Racket CS) and "Racket BC" with the current version of the The Computer Language Benchmarks Game in https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
(The set of problems and measurements of runtime are made by someone that is not in the Racket team.)
[1] That are somewhat bad for Racket because some of them use mutable pairs/cons.
[2] They are frozen to test backward compatibility and to ensure any progress is due to improvements in the compiler.
> Write your next Ethereum Contract in Pyramid Scheme
> I create Pyramid: A dialect of the Scheme programming language that targets the Ethereum Virtual Machine(EVM). Pyramid Scheme is implemented using the appropriately-named Racket.
http://www.michaelburge.us/2017/11/28/write-your-next-ethere...
[0]: http://arclanguage.org
[1]: http://arclanguage.org/install
[2]: https://beautifulracket.com/appendix/why-lop-why-racket.html
https://docs.racket-lang.org/pollen/
That the outputs look very good may be correlated with the author and other prominent users caring for typography and web delivery.
As-is, my impression is that generation of multiple pages seems slower than scribble/manual, but the community has been exploring use of databases to speed up caches. In this respect, I've been eyeing the work of this member in particular: https://github.com/otherjoel
All this speaks very good of the seemingly limitless flexibility of the Racket ecosystem.
Add to that some better facilities for mixing languages and it is a very nice language that is very close to racket. Yet for some reason I find guile more fun.
> immutable strings (which racket has not)
The reader makes strings in the sour code immutable by default. And if you have a mutable string you can use string->immutable-string https://docs.racket-lang.org/reference/strings.html#%28def._...
Maybe web services? https://youtu.be/ZvwE6_MMJjM
[1] https://www.youtube.com/watch?v=_wY7FBtr7_c
https://news.ycombinator.com/newsguidelines.html
He acknowledged that Racket has excellent documentation, a wide-ranging toolset, etc. All the good stuff you've heard elsewhere.
He criticizes the language-oriented model (in comparison to languages that people are familiar with but that allow embedded Deals, like Lua or Ruby) because creating a new DSL is antithetical to code that communicates with other programmers. This is fair, and a common criticism of Lisps: the complete freedom of the macro system means that individual programmers can create their own dialects quite easily, and other users of that code have a harder time working with it than in languages where there's not as much metaprogramming.
On the "toxic" front, one of the core team apparently asked a waitress a cringy question about higher education, referred to some other educators (at the creator's institution) as doofuses and the like, and was arrogant.
And at the end of it all, though he doesn't see a use for Racket's language-oriented model, he recommends learning and using it.
DSLs communicate wonderfully with the business users paying for the program. It also allows a programmer to match the jargon / industry speak used by the users.
I know that Cadence's ASIC design tools are based on a custom Lisp dialect. I've seen a presentation at a Lisp conference from an architect who was representing myriad building regulations as Lisp expressions e.g. minimum clearance between toilet and bathroom door. There was another presentation about Lisp software for simulating aircraft engine performance based on various input parameters.
I don't know how close these applications are to Racket's ideal but I imagine they're somewhere on that spectrum.
If you start talking to older architects and civil engineers who where active in the early to mid 90s, you'll be surprised how many of them know (or at least knew) Lisp.
1) https://vimeo.com/2723800
Oh, I whish ruby had a more formal way to switch to DSLs - I love ruby, but can't stand meta-heavy/DSL-heavy subsystems. The rspec test system is a prime example (saved to some small degree by its excellent and detailed documentation): https://rspec.info/
An ingredient that may contribute to judgment of this video testimony, is that the same person that describes this toxic environment accuses someone providing a different personal impression of the community of engaging in "micro-agression" in the video comments.
PS : what happened to the "you can't make a web app in Racket" part?
I really don’t know what this guy’s talking about in other comments. Web apps seem super easy to put together in Racket. For those curious, see:
https://docs.racket-lang.org/web-server/index.html
https://docs.racket-lang.org/continue/index.html
(The troll also acknowledges that Arc is a neat language— apparently, they think that racket is a terrible language to write bad applications, but I guess it’s good enough to write a language to write good web applications in!)
(I have heard a Racket described as the “second best programming language, the best programming language is the one you use Racket to build!)
I'm a newb to the paradigm, but fiding it useful to understand Javascript better.
Thanks.
The repl is about on par with readline but with fancier output. Stuff like images and what racket calls "snips" are directly displayed in the repl. Snips implement their own rendering and interaction handling so you can do stuff like animation, plot charts, display an interactive map, etc. What I feel like it's missing is a way to collapse output/results like the console in firefox/chrome does and a way to reference the previous results (beyond just hitting the ctrl+up keybind) like in ipython.
There's a solid debugger and a tool to show each step of macro expansion if you need that while writing macros. Package manager is integrated into the editor. Autocomplete, syntax highlighting, auto indent/reinvent are all present and are fine.
It's got a bunch of little nice things like when you mouse over an identifier it draws an arrow to the where it was bound or required from a module. The reverse works too so you mouse over a binding/require and get arrows showing all the occurences. Another little thing is that it will automatically input the correct closing paren depending on context so if you're typing "(foo [bar (baz" and you then type ")" three times it'll input ")])".
That's useful for teaching but I think it might also be very handy for data visualization and symbolic representations. Perhaps even for debugging with complex data structures. I think this is a mayor innovation.
Clojure and Racket have quite a few similarities. They are both relatively minimal, and are both Lisp-1 (https://clojure.org/reference/lisps).
Racket as a Scheme has a stronger separation between compilation and run time, in order to maintain safe semantics. This has an effect on interactivity which is an important difference between Schemes and Lisps. It is easy to redefine a function in a running Clojure program and call into it without re-starting the whole program. In Racket, one does more often re-start a program.
Clojure is heavily opinionated towards functional programming. For example, all sequences are evaluated lazy, while Schemes do not do that by default. This is something it has in common with Haskell. But I also think this might be one of its many adaptations for use as a language in server and back-end environments, where sequences can become very large. These adaptations make Clojure very good for concurrency but less well-suited for true parallelism. It generates also slower code than Common Lisp.
Clojures standard implementation is tied to the Java virtual machine. This has advantages and disadvantages: A very large library of functions which programs can call into. Worse stack traces. Error reporting is limited in comparison to Common Lisp. No continuations like in Scheme. And it is much harder to call into C code when this is needed for speed, for for calling into system functions.
In Racket, it is easy to call into C code and to call into Rust code with C ABI. That means Racket can be used as a glue language, like Python (however it is not made for being embedded into C/C++ programs, that would be a flagship application for Guile).
Clojure programs have a large start-up time of potentially several seconds which is irrelevant for servers, but make int unsuitable for scripting (well, there is babashka, a Clojure implementation which improves on that https://github.com/babashka/babashka).
All in all, Clojure is fantastic for programming for the server and for concurrent tasks, and for learning functional programming.
Racket on the other hand is well suited for beginners, it has a large and well-rounded standard library and a lot of useful packages. It is easy to write a GUI with it, it is good for easy scripting, interacting with the OS, writing experimental algorithms, like Python very suitable as glue and so on.
Also, because Racket belongs to the Scheme family, if needed there is a whole host of Scheme implementations which can be used for any special needs, with very little change in the base language, so in that way Racket is one versatile power tool in a quite large tool shop.
There are also applications where I think Common Lisp is probably the best choice: Very mature implementations, very stable, availability of compilers which generate very fast code, especially a high performance in numerical algorithms, good imperative capabilities where they are needed, fastest start-up for scripts, very good documentation and books, independence from particular vendors or projects.
Edit: Found the relevant part of the docs[1], I like the automatic contract enforcement, although I guess it would be kinda hard to guess the perf impact...
[1] https://docs.racket-lang.org/ts-guide/typed-untyped-interact...
Typed-racket has some form of refinement types now as well.