I'm glad Racket CS happened(even though I don't use Racket), because I was worried about the future of chezscheme's maintenance. It's a runtime with good portability(Guile Scheme, for instance, seems to pretend Windows doesn't exist), and I think it'd be a shame to see it fade away in the future.
There is a branch being pushed to while we speak on the guile git to update the mingw support. I don't know what it means in practice, but maybe windows support for guile 3 is getting closer.
I used Racket in an intro to CS course a few years ago and was told it’s designed to be a teaching language. Is there any reason to use racket over a more popular functional language? Does anyone use it in production?
The Racket distribution comes with several languages.
You were probably using the socalled teaching languages, which are small subsets of real Racket. Using a subset of the real language allows better and more beginner friendly error messages.
The real Racket language is a general purpose language with all the bells and whistles you could ever imagine.
The killer feature of racket is it is very easy to make Domain Specific Languages (including the teaching language) and related tooling.
However last time I looked the library ecosystem didn't seem great; there were many libraries but few that were actively maintained.
I think the counterargument is that in large projects, you will end up with DSLs whether you meant to or not. The philosophy of language oriented programming (LOP), as I take it or understand it, is that since you'll end up with them anyway, why not approach and build DSLs explicitly.
We (mostly Matthew) have opened plenty of pull requests, although not for the most recent changes since they rely on earlier ones that are not merged. The Chez maintainers move at a deliberate pace, and don't necessarily share all the same priorities as Racket. But we're very much in touch with them, and they've helped develop even some of the changes that aren't upstream.
I don't think it's likely that we'll move back to pure upstream Chez in the near future, but it's not quite a fork either.
It seems like if Racket-Chez continues to track Cisco-Chez that it won't really matter and we can continue to live under one roof.
I'll read the Racket on Chez papers. Are there plans for more backends? RISC-V, Wasm or Scheme (not Chez specific)? Wasm would be interesting as that would also enable a path to integrate with Graal. I understand that Wasm doesn't yet support native tail calls, so that would have to have to be addressed.
> A Racket-implemented layer of Racket CS must be translated to Scheme to run on top of Chez Scheme.
That contract between Racket and Chez for how Racket runs on Chez, I think that is fairly interesting from a language engineering perspective. It seems like it could be a nice RRRS (Revised Report on Racket on Scheme).
I am interested in LISP-type languages, but I have a serious case of decision paralysis.
GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).
While almost all can call easily into C, one thing where Guile really shines is that it can easily be embedded and be used for scripting and configuration in a program with C building blocks.
Racket really is nice if you don't know what you want to do and you want to be hacking on some code in less than five minutes. I think I have Racket installed on every computer I own.
Because I can understand the whole implementation. I am no programmer, but the racket source is somewhere between "magic" and "more magic" to me.
I managed to patch guile to fold equal? to eq? when the comparisons involved literal symbols, chars or fixnums. (Although maybe not in the best way, it still worked). I apparentlynnerd-sniped Andy so he implemented it properly as a part of the expander (I think). That took me less than an hour starting from a cursory understanding of the guile codebase.
I tend to enjoy Scheme more than Common Lisp for just hacking around, but I'm by no means an expert Lisp hacker. If you decide to check out Scheme though, Chicken Scheme has been awesome for me. It's very fast, compiles to C, had a ton of great "eggs" (modules / packages), and seems to have a somewhat friendly community with decent documentation.
I think the first question is scheme, or Common Lisp? The answer depends on what your style is. After trying both I like scheme better but I agonized over this decision for awhile, though I enjoy sbcl and CLISP is dear to my heart.
In terms of schemes you have a wide variety to pick from. Gerbil, Racket, Gambit, Chez, Chicken and many more. Racket is a great all around choice. There are schemes that do various things better than it, but it can do most things well. It has two great edX courses to learn from (How to design simple data, and how to design complex data) and is how I initially learned.
Chicken is one of my favorite schemes and is probably the one I would use if I wasn't using Racket. It's so portable since it compiles to C. I love the egg system, and I like the logo. Gerbil is a performant systems level scheme. I remember there being an article about someone in the Common Lisp community considering jumping to Racket, but ending up on Gerbil Scheme for what it's worth. I haven't used it
Chez is another super performant scheme, and is actually the backend for the Racket programming language as seen in the article above. It was only open sourced a few years ago so it might be difficult to find solutions or get answers. I've used Guile, I appreciate the mission, but I found it wanting. I've heard people ship Gambit scheme apps onto IOS so if you are looking at mobile apps that might be the way to go, I'm sure Chicken could do that to. I have also heard that Gambits Cffi is one of the best in the business, so if you need to interface with a lot of C code that might be the way to go.
There's pretty much no reason to use MIT Scheme unless for a course, despite its historical significance and influence. For one, it's no longer supported on Windows. I would recommend using Racket with the #sicp language extension.
> I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).
Scheme is not more minimalist than C.L. in practice; it's standardization is simply more fragmented and has nested layers, often by different organizations, that implementations can support, and then most implementations go well above even that.
Different Scheme implementations tend to share a common base but then tend to provide functionality above that, often shared between different implementations as well.
I personally would recommend Racket or Clojure. Both of them are much more opinionated and closer to Scheme than Lisp, which is a bit more loosey-goosey (i.e., not focused on functional programming), so to speak. If you really want Lisp and not a Scheme-like, then Common Lisp is the only choice.
I'm leaning towards GNU Guile these days, for a few reasons. Mostly because I am a GNU type of person, (almost all of my stack is gpl, for example) and Guile is now not only the preferred GNU extension language, but it is also the core part of GUIX, and a few other tools I really like (mcron, a cron replacement).
So to explain just a bit, often I do a lot of paralysis by analysis of tooling, but as a side effect one of the things I've learned to help me get past it is to filter first based on licensing. I like Nixos, and I think the principles there are going to go far into the future, but I don't like MIT/BSD licenses. So if I want the same kind of tech, but in GNU-land, that leaves me with GUIX (the os and the package manager). Decision made.
Only in the most extreme circumstances do I violate these principles (steam for gaming!) and am always looking for alternatives as they pop up.
I really like the idea of compiled lisp eg common lisp, but most of the gpl friendly versions are not in active development, besides maybe Clozure CL. Clisp website shows last update was in 2010, and for some reason that really rubs me the wrong way.
It's funny because I still really don't know that much about lisp, it's just on my "to get into" list, besides elisp.
Thats just redhat deciding that for fedora though, GDB itself on other distros will still have support for guile. Not sure how to interpret that, though I guess working on shrinking gdb is understandable.
It is a very multi-dimensional issue. While all these languages belong to the same family, they also take some time to learn, and each has its specific strengths. It is probably very helpful to think about what matters most to you, and pick what matches your needs best for the first language.
Here some axes of distinction:
1. supported programming styles
2. support for concurrency
3. performance of generated code and parallelism
4. floating-point performance
5. level of standardization
6. closeness to the system and capability to call into C functions, or functions with C ABI
7. suitability for scripting and stand-alone programs
8. GUI programming
9. Comprehensiveness and beginner-friendliness of documentation
10. REPL Programming
11. Libraries
12. Licenses
Here what I know about the languages you name:
(I also mention ABCL = Armed Bear Common Lisp a few times, just to illustrate that you also can run Common Lisp on the Java Platform).
1. supported paradigms - Clojure is very opiniated in supporting and demanding a purely functional style. It uses purely functional data structures. Racket and Scheme support a functional style well, but allow for seamless imperative code. Common Lisp is agnostic, one can program in a purely functional way and there are libraries with purely functional data structures, but it requires much more discipline.
2. Clojure has best support for concurrency and server-like tasks, it is made for that. Racket also supports green threads, apart from its places parallelism.
3. Racket, Chez, Common Lisp and so on support OS level threads and parallelism. Chez and Common Lisp stand out as they generate the most performant code - when it comes to raw computing power, single-threaded SBCL code will be faster than multi-threaded Clojure code. SBCL, for example, also allows to add compiler hints which generate unsafe code with better optimizations (for example, indicating that integer values will only be in a specific range).
4. SBCL has by far the best floating-point performance, I think Chez comes after that, and I'd expect Racket to improve further here. Racket has also been reviewed very favourably for scientific applications (https://khinsen.wordpress.com/2014/05/10/exploring-racket/ - Konrad Hinsen, the author, was an early contributor to Numerical Python).
5. Of all these, Common Lisp is standardized most. Especially Racket and Clojure are defined by their implementation.
6. Clojure and ABCL allow to call into Java. In turn, all of Common Lisp, Guile, Racket, Chez allow to call easily into C. There is a performance difference, I think, between most Schemes and SBCL: Calling into a C function has some extra cost because the stack is handled differently (I think it is because of continuations). I also tried to call into Rust functions from Racket and that works very nicely.
7. Clojure's startup time is simply too slow for scripting. It is also a bit hampered in that it runs on the JVM. There is babashka, which is interesting but has no mature status. Conversely, Common Lisp and Racket are well suited to scripting. It is also possible to compile SBCL and Racket programs into a single executable. I think SBCL supports this case best, for running Racket programs, an extra runtime library or a standard Racket installation is needed. Guile is also well-suited to scripting and is closer to the OS than some other Lisps.
8. Racket has a very nice support for GUI programming with a platform-independent functional API. Clojure and ABCL also allow to call into Swing and Fx code written in Java. I have not tried the rest but it looks relatively painful and brittle in comparison.
9. Racket has very comprehensive and high-quality documentation good for beginners. Clojure is also comprehensively documented, but might assume a bit more experience. Common Lisp is, as an open system, more eclectic, and ...
S7 is similar to guile 1.8, which was an interpreter written in C. Now guile has a pretty nice VM, a bytecode compiler, a JIT and is written in a lot more scheme.
One difference is that Quicklisp + ASDF often needs to be set up manually which can be a little bit more complicated (it is, however, contained in Debian as a package, for example).
Leiningen and Maven relay on version numbers for dependencies.
My understanding is that Quicklisp in practice uses a "rolling release" model similar to Arch Linux - you get a current distribution, where all packages are at their newest version, and if needed, one can also roll back to earlier versions of the whole distribution. That this works with elegance is related to one aspect of Common Lisp culture which is very, very different from, say, Python or Go: Common Lisp puts a lot of importance on backward compatibility and stable APIs, it is possibly the most backward-compatible of all dynamic languages.
Further, while Leiningen is a de facto standard which makes working with Clojure libraries essentially frictionles, Quicklist is just one modern way of multiple ways to include Common Lisp libraries.
This difference is owed to the trait that Common Lisp is much more an open system (which I consider a good thing), while Clojure is more uniform and "managed".
This is a very good post; kudos for writing it up.
Another thing which may be nice to talk about is where the communities are for each language (Racket on Slack and the mailing lists, Common Lisp has an irc...).
Nice article.
I think using Racket shoud be avoided because of its problematic community. I've had disgusting experiences interacting with people from Racket community in the past, but so far I thought I was the only one. Unfortunately, it doesn't seem that way. Recently, a computer Scientist Leandro Facchinetti described in his video his ugly experiences with top people in Racket community. The experience was such that he completely gave up his PHD and the use of Racket forever. You can view the video here: https://www.youtube.com/watch?v=_wY7FBtr7_c
In the video Leandro Facchinetti says: Speaking of people, it's very sad that I had same bad experiences with some people in the Racket community, especially the people up top because they are the kind of people who are smart and they know about it and they will not lose a chance to tell you. I'll give you some examples: I was at the Racket conference having dinner with one of the creators of the language and some other attendees and the creator of the language had some very good points about higher education and how it is kind of a scam in the U.S. but to prove his point he decided some questions to the waiter that were kind of uncomfortable and everyone at the table kind of cringed. Of course, the waiter was gratious about it but still...
As another example, I was talking to another one of the creators of the language and he called one of my collaborators a doofus and the educators at my university, which used to be John Hopkins University, a bunch of donkeys. I understand that he had some points to make about how educators work but this is not the way you make them, right?
It comes to a point that when I was talking to the students of these people, they're kind of afraid of talking to their advisors and I must admit that spending time with these people is one of the reasons why I decided to drop out of the PHD and leave academia all together, because if that's how it looks like to be successful in these communities I think I prefer to try to be successful somewhere else.
You should take that to the Racket community, I do not feel it is appropriate to discuss that here where the people you talk about do probably not know what is said about them.
Though people use Clojure for real work (just like PHP, Perl, Bash or Fortran), it has a narrow ideological focus which is radically different from the multi-paradigm nature of historic Lisps. It can be described as a domain-specific language for processing several kinds of immutable data structures as generic sequences, with Lisp-like syntax and meta-programming. You may learn something about Lisp from Clojure, but the big picture is missing; Clojure is "its own thing", mostly disconnected from the Lisp history, culture and practices. Clojure expertise will not transfer well to Lisp and vice versa.
Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct concurrent programs.
It is clearly geared to servers, for example sequences are always lazy. This is not always the best thing but for servers, it seems in general better.
However, there is a subtle point about parallelism: One typically wants concurrency and parallelism for one of three objectives:
1. Concurrency in servers
2. Graphical user interfaces
3. exploiting many cores for complex parallel computations, like number crunching
It turns out that Clojure is great for the first application. It also works for the second one.
However it is not that great for the third area of interest. The reason is performance. For example, floating point numbers passed in function arguments are often boxed. Also, due to the JVM it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector, even if the Clojure compiler partially tries to work around this.
And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure.
But I still think that immutability in-the-large is the right way to go.
It's a Lisp, in the Scheme subset. It's original design was primarily around Programming Language Theory education - formerly it was PLT Scheme. Much of it was designed for educational uses, but it's a really well-rounded system with plenty of packages, a decent package management system, better performance than most interpreted languages. It comes with an IDE easier to pick up for newbies than Emacs (the usual Lisp/Scheme environment), but also runs fine as a command line REPL and compiler.
It's kind of an oddball. While the development focus is mostly educational, specifically Programming Language theory, it's also very usable in the real world. There's a few tutorials on writing your own domain specific language in it. You can specify a language other than the default Racket, so one compiler/interpreter environment actually supports many Lisps and DSLs.
I'm a long time dev who recently picked up SICP to learn why everyone says learning Lisp/Scheme will make you a better programmer, and Racket is by far the most interesting environment I've worked in. I haven't even touched Python, which was my money-maker, in months.
Same. I learn so much when I try to do something with it.
You know what they say about emacs. "Emacs a great operating system, it's just lacking a decent text editor." Same with Racket. Racket is a great language development framework, the only thing missing is a decent language to write your program in.
It does take a lot more effort and expertise to design a language and a program. That's why it's fun for me, I get to dream more and need to learn more.
I'm inspired by the super interesting Racket papers [1] and PG's book "On Lisp". It helps that I got to use Racket to make a couple basic compilers in some uwaterloo classes too.. but I didn't even use macros for those projects, so I haven't really gotten started with Racket yet ;)
I think of it as the Python of Scheme (yes yes I know). Batteries included, well documented, big focus on ease-of-use.
It also has a Big Idea; it aims to be the practical realization of the grand idea that Lisps are the perfect platform to build programming languages on, and to take this so radically far that you can have entirely different programming languages that nevertheless share, not just a runtime, but all their libraries. Unfortunately, so far, nobody except Racket enthusiasts appear to have much interest in building languages on top of Racket - but it's absolutely possible and practical, and someone really did accomplish the astonishing feat of implementing Python (Python 2, alas) in Racket, in such a way that you could combine libraries from both languages.
This is nice to see. I’ve played around with Chez and Racket separately, and even though I’m now focusing on bare metal/JIT again, I look forward to using the new Racket.
Congrats on the release. What Racket really needs right now is a proper dependency manager with support for constraint solving and allowing multiple conflicting transitive dependencies. Cargo and yarn are the gold standard for this. A lot of Lisps tend to overly focus on language and compiler features and neglect the more boring tooling and infrastructure that makes a programming language successful.
Thanks for all your hard work Racket team and contributors.
Can we appreciate the meta? A fast low-level program was re-written in a high-level language to reduce maintenance costs. These days on HN you usually only hear about the opposite, eg. Figma rewriting server Typescript code in Rust to improve performance [1]. Not fair to compare Rust to C, I know, but interesting nonetheless.
The loss of JIT was interesting. How does eval work? Apparently Chez Scheme AOT compiles code at runtime. Comparatively a JIT will change the compilation at runtime based on codepaths. There's a thread about that here [2].
Part of the motivation of CS was to make it easier for people to contribute to the compiler. I'm excited to see how that plays out.
Thanks again everybody. I'll go back to toying around with macros and tiny Racket programs now.
eval works very similarly to how it worked before -- when you eval some code it compiled it and then runs it. Every* Scheme or Lisp system supports this kind of compilation-at-runtime, and Chez is no exception.
>A fast low-level program was re-written in a high-level language to reduce maintenance costs. These days on HN you usually only hear about the opposite
Related, though not quit the same, is the manner in which the Cog VMs for Squeak/Pharo are developed:
"The VMs are developed in Smalltalk, using all the dynamic and reflective facilities of the Squeak/Pharo Smalltalk system. As such, developing in Cog is a delight. The Smalltalk framework comprising the various Cog VMs is translated into C by its Slang component to produce VM source that is combined with platform-specific support sources and compiled via a C compiler to obtain a fast production VM."
Donald Knuth once said, “Premature Optimisation is the root of all evil!” But that message has obviously not yet reached the Racket community.
Because how else do you explain this madness: they spent three years developing a new version of Racket that et the end turned slower than the original! [1]
Meanwhile, for example, we can still count the number of web applications written in Racket on the fingers of one hand, and the number of Racket users in the racket group is rapidly decreasing from day to day.
Turns out the only users of Racket are people who live off Racket in a way that writes scientific articles that nobody cares about.
Very rare are those who use Racket for any practical purposes.
I wonder if it would have been better if this huge effort had been made to write clear documentation on how to use the Racket Web Library in a practical way? The current documentation for the web framework doesn't understand, I mean, even its creator, Jay McCarthy. I've never seen worse documentation on any software product than this for racket web library in my entire life.
On the other hand, we have this guy, Jesse Alama [2], who, like, wrote something about it. But there's literally not a single thing this guy published that he didn't charge her fattly. All his books and tutorials cost a lot and their quality is questionable.
But, unfortunately, these topics are a taboo in Racket community...
Racket positions itself mainly as an education and research platform. Yes, this is what puts food on the table of academics. I don't understand your criticism. Racket is very impressive in many ways, but making a run-of-the-mill webapp in two lines is not one of them.
IMO, thinking that nothing important came out of Racket reseachwise is a highly uninformed opinion. I mean, dependent type systems as macros (therefore bringing true static types as a library)! Come on, is that not impressive?! Rewriting Scheme-on-Scheme to obtain something simpler and pretty much as fast as Scheme-on-C is not impressive!? A Scheme program that compiles to a C parallel GC is not impressive!?
On the contrary, the core Racket team is very, very impressive. Just not for the things you yourself wish for.
Yes, I'm aware that Racket is mainly education and research platform; that's exactly what I said in my previous post.
Racket is not well-suited for practical web-programming. Proof: For Python or Ruby, there are dozens of books explaining how to write web applications in them. But there's not a single good book for Racket (not just for web programming, but for anything).
Racket's authors use racket for their academic jerk-offs, but don't fog our eyes and tell us it's a practical language for real programmers, when it isn't.
I'm sorry, but it's like complaining that Haskell is not a practical language. If you want to do production work, then why not focus on languages that are geared towards that? There are a lot of choices out there...
Huh? Weird, I have written a blog website in what Racket offers, following the documentation you criticize in another comment and got it working. Even the not so easy to understand continuation based side of it came to me after reading it thoroughly. It is quite simple to setup your REST routes and all that.
I did never bring it online, as I never rented a server for it, but it definitely functions and I had some local posts, which I did not include in the repository.
Did you never have a software without documentation? I think that would be way worse than having a sort of OK documentation of a bare bones web framework, that is actually understandable, with careful reading.
The Racket mailing list is also very helpful and people there are helpful in my experience. Show them you tried and your attempt at things and they'll probably help you out. My only pain with it is, that they are on Google groups.
Which topics are taboo? That documentation is good? Or that academic use and industry use are different? Those topics are well discussed in the community.
On the other hand, negative ranting about how everyone is wasting their time, how particular people are terrible, or how charging money for a book is inappropriate -- those are discouraged, and thankfully.
Come on, samth! Charging money for a book is not inappropriate. But charging (a lot of) money for a very lousy book are just pathetic. Did you ever read any of Jesse Alama's books? Thank God you didn't. That guy is tipical Racket community parasite: he parasitizes on your efforts and pains by charging his bad books, thus destroying the reputation of the entire community who turns out unable to write a fair book on how to use racket in a practical way.
Yeah, I think everyone understands that you have an axe to grind with Jesse. As for the docs: searchable? check; examples? check; narrative about what is happening? check. What's missing?
Are you going to tell us all books about your pet language are worth their price? How is that the community's problem?
rscho, I'll believe you when I see you or someone else wrote some more complex web application in Racket, which works properly and is scalable.
All of this will not happen, of course, because there is no such application written in the Racket in the world (no wonder when the documentation is so awful!)
Believe what? I've said nothing hinting at racket being good for web programming. What I do say is that you are missing the forest for the tree. You should probably go back to rails or django, as you'll be much happier there.
And if like your username and debate abilities suggest you are really 20 years old you can't present yourself as "an experienced developer", sorry for being blunt. Regarding Racket at least, you have a lot left to learn.
I'm running the webserver so the T.A. in my department in the university choose they preferred building/course/day/hour to work. They are ~400. The first year I was worried that the server would collapse or something. Now I assume it is working unless I get many angry emails. (I don't remember the last time I had problems, most of the emails are about changes in the available courses and other administrative stuff.)
Back to stuffer, you can use the default stuffer or just ignore that stuffers exist at all, unless your site is huge.
> Because how else do you explain this madness: they spent three years developing a new version of Racket that et the end turned slower than the original!
This is just a blatant misunderstanding of what Racket on Chez is trying to do, and a very limited understanding of what “optimization” means for something as complex as a compiler/interpreter. The point of the Chez backend is to improve maintainability and portability, not to increase speed [1]. Racket used to have a custom Scheme interpreter with a lot of custom C that was difficult to work with, so instead a lot of that code was ported to Chez - easier for everyone, especially Racket devs, even if it might take a while to smooth out some of the (very modest) performance hits.
And since you’re obviously totally ignorant as to why Racket decided to do all this work, it makes it hard to take your rant seriously.
I think the case is simple here: Racket community was not capable of producing good programming language, so instead they decided to take someone else's better implementation: they decided to abandon the years and years of their efforts, because they realized that Kent Dybvig (a real hero i this story!) was better than all of them. That's why they decided to take his Chez scheme and parasitate on his effort.
The very fact that they did this tells us a lot about Racket's community “achievements”!
I agree, but the paper you link has more than one year. Now the benchmarks are much better, and in most cases Racket CS is faster than Racket BC. I think the even point was a few month ago, but there were too many bugs (small bugs, in weird corner cases, but important enough to not switch until they were fixed).
If you don't mind crappy graphics with numbers pulled out of the air https://imgur.com/a/9r0aJzd The idea is trading a slower development speed for some time, to get more speed and features in the long run.
Perhaps the change in the slope in BC is too much, and the current speed of CS is greater than the imaginary speed of a version of BC in an universe where BC didn't happen. I hope the crappy graphic in Paintbrush is enough to make it clear that the numbers are pulled out of the air. Anyway, one of the hard fact of the blog post submitted here is that in most cases the current version of CS is faster than the current version of BC.
Jesse Alama here. If you bought a book from me but are unsatisfied, I'm happy to refund you. If you found my stuff unhelpful, let me know what's missing and I can try to include a discussion of that in the next edition. Just write me offline. Or write to the group, or visit us (or me) in the Racket Slack.
I wrote my stuff to help people get into web development with Racket. I love web devel, and Racket, too. You and I have a lot in common: I found the official docs puzzling, so I worked out my own approach to them and made _Server: Racket_. It should go without saying that that's the origin story of just about every paid book out there on applications of programming language X to domain Y. That's not even a criticism of the Racket docs. Plenty of tools/languages also have good docs, and there are lots of books, too. How many Django books (or even courses) are out there?
There are also some great web programming tutorials out there for Racket, too. I recommend this one, by Racket star Jens Axel Søgaard: https://github.com/soegaard/web-tutorial .
I hope you'd give Racket a chance. Since you're talking about it, it sounds like you're dipping your toes in the waters. I'm pretty sure you'll find them quite welcoming. That said, all this negativity is pretty off-putting.
I have a slow-moving side project in Racket. I picked it up for its reputation for being the Python of the Scheme world, but I think the analogy doesn't hold up and you're better off accepting Racket on its own terms. Racket doesn't have the standard library of Python, nor does it have the syntax, nor would you structure a program in the same way. Indeed, I think the idea of bringing a more Python-like syntax to Racket would only delay the realization that Racket is not Python with an inferior standard library, but a totally different animal.
I'm excited about Chez for the performance gains, and I think it's really nifty that it allows more of Racket to be written in Scheme.
Anyone writing scheme/racket like python is in for a bad time. I think languages either tend towards mutability or immutability. In clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates.
In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc. This means that even many cases of hidden otherwise "safe" mutability might lead to bad results.
Which is why scheme tends towards immutability. That is the safe thing, culturally and also by design. Whereas the happy path for python is generally one of mutability, the happy path for scheme is not.
Which is also something that I try to keep in mind when learning a new language. It is very tempting to try to write scheme in another language, but doing so in python will lead to sadness.
I have seen so many people trying to learn scheme by trying to write python in scheme, which usually ends up being awkward, slow and buggy in addition to not working with call/cc or delimited continuations.
I had an epiphany about this when trying to write scheme in rust. I took a step back and realized that I was the python programmer :)
> I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates.
Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs.
However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives:
1. Concurrency in servers
2. Graphical user interfaces
3. exploiting multiple cores for complex parallel computations, like number crunching
It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors).
However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector.
And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure.
This is a drawback which is rooted by the implementation.
But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.
Check 'Getting started' above, but I'd suggest that if you are already a developer, start with the Racket Guide, and 'How to Program Racket: a Style Guide' both available in the documentation site https://docs.racket-lang.org (and bundled with the installer). The Racket Guide is fully integrated with the Reference - click on something and it will take you to the reference for the full definition.
It's also worth working through HTDP https://htdp.org - with the caveat that you are using the teaching languages. A really nice thing is Racket can support students/learners, without compromising the full language. The Racket installer includes Racket, proper, the teaching languages, and a number of other languages.
The main goal of the project from the Racket on Chez status 2018
> It would be nice if porting to Chez Scheme made every aspect of Racket magically faster. It hasn’t done that, but we have plenty of room for improvement; the performance results to date are a lower bound on performance, not an upper bound.
> Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance. The Racket-on-Chez implementation is far more maintainable and flexible than the current Racket implementation, so maybe we’re half-way there after one year of work.
The fact that the performance looks this good is a huge win. And the focus on maintainability over speed is a refreshing sight. This is the sort of practical solution that will allow Racket to be relevant for many years to come. Racket is a good all around Scheme, there are other schemes that do certain aspects of what Racket can do better, but as a whole Racket is a very complete package.
I have two main criticisms with Racket, which are totally fixable, and in large part due to Racket's history as an incubator for language oriented programming, developed by PhDs in Comp Sci. Racket is very Academic. The documentation is great, but it is written by other Academics and can be hard to grok. Same with example code. Sure if you are looking at the student languages and tutorials based on that it is more accessible, but the minute you are trying to write a complex GUI app in typed Racket, the tutorials and example code is few and far between. Sometimes it makes me feel like I'm to dumb to be using the language, and I feel like I'm not the only one to get that feeling.
Also for a language that prides itself on Language Oriented Programming, I want to some more examples/tutorials that are not just using brain fuck language. These are fixable, and I admit some are just me problems, but I'm actively working to solve them in this space.
101 comments
[ 3.0 ms ] story [ 114 ms ] threadThe real Racket language is a general purpose language with all the bells and whistles you could ever imagine.
DSLs are just better integrated into the base language so your source code doesn't look like:
https://github.com/cisco/ChezScheme/issues/545
Racket-Chez is different from Cisco-Chez by > 600 commits. I wonder what the plan is to normalize them or will be Racket-Chez be our new house.
https://github.com/racket/ChezScheme
I don't think it's likely that we'll move back to pure upstream Chez in the near future, but it's not quite a fork either.
You can read more about some of these issues in our ICFP 2019 paper: https://www.cs.utah.edu/plt/rkt-on-chez/ which is co-authored with the Chez maintainers.
I'll read the Racket on Chez papers. Are there plans for more backends? RISC-V, Wasm or Scheme (not Chez specific)? Wasm would be interesting as that would also enable a path to integrate with Graal. I understand that Wasm doesn't yet support native tail calls, so that would have to have to be addressed.
> A Racket-implemented layer of Racket CS must be translated to Scheme to run on top of Chez Scheme.
That contract between Racket and Chez for how Racket runs on Chez, I think that is fairly interesting from a language engineering perspective. It seems like it could be a nice RRRS (Revised Report on Racket on Scheme).
What are your thoughts on Shen?
Wasm would be very nice to have; I think compile-to-web is a big missing piece although there are potentially other ways to do it.
For Graal I think a direct implementation would be nice.
Compiling to other Schemes would be great, and I think we're in a good position to make that happen now.
I think the contract isn't that interesting in a sense -- it's just most of Chez. But the paper does talk about that sort of thing.
GNU Guile? Common Lisp? Clojure (JVM)? Racket? Judging by my understanding of the difference between Common Lisp and Scheme, I think I am more of a Scheme type (I prefer C over C++, I like Go more than Java, etc).
Clojure if you're looking to use the language directly to solve your problems (and my preferred Lisp).
If you care about startup times or FFI then don't pick Clojure.
YMMV between Racket and Guile; I would say Racket is better insofar as the culture of documentation is really very good.
In practice, once you learn a Lisp, you can jump between them without too much trouble.
Isn't Clojure in some significant aspects similar to Schemes?
I use guile since I think it more fun, but racket is a lot easier if you want libraries around.
I managed to patch guile to fold equal? to eq? when the comparisons involved literal symbols, chars or fixnums. (Although maybe not in the best way, it still worked). I apparentlynnerd-sniped Andy so he implemented it properly as a part of the expander (I think). That took me less than an hour starting from a cursory understanding of the guile codebase.
In terms of schemes you have a wide variety to pick from. Gerbil, Racket, Gambit, Chez, Chicken and many more. Racket is a great all around choice. There are schemes that do various things better than it, but it can do most things well. It has two great edX courses to learn from (How to design simple data, and how to design complex data) and is how I initially learned.
Chicken is one of my favorite schemes and is probably the one I would use if I wasn't using Racket. It's so portable since it compiles to C. I love the egg system, and I like the logo. Gerbil is a performant systems level scheme. I remember there being an article about someone in the Common Lisp community considering jumping to Racket, but ending up on Gerbil Scheme for what it's worth. I haven't used it
Chez is another super performant scheme, and is actually the backend for the Racket programming language as seen in the article above. It was only open sourced a few years ago so it might be difficult to find solutions or get answers. I've used Guile, I appreciate the mission, but I found it wanting. I've heard people ship Gambit scheme apps onto IOS so if you are looking at mobile apps that might be the way to go, I'm sure Chicken could do that to. I have also heard that Gambits Cffi is one of the best in the business, so if you need to interface with a lot of C code that might be the way to go.
https://mitpress.mit.edu/sites/default/files/sicp/index.html
After getting comfortable with Lisp based languages, it is like Algol derived ones, it is relatively easy to jump between them.
I tend to stay with Clojure, because JVM/CLR is where I spend most of my time, so I can easily pig back into the libraries.
Maybe what you can do is similarly, pick a Lisp variant for the domain you spend most of your time on.
https://docs.racket-lang.org/sicp-manual/SICP_Language.html
Scheme is not more minimalist than C.L. in practice; it's standardization is simply more fragmented and has nested layers, often by different organizations, that implementations can support, and then most implementations go well above even that.
Different Scheme implementations tend to share a common base but then tend to provide functionality above that, often shared between different implementations as well.
So to explain just a bit, often I do a lot of paralysis by analysis of tooling, but as a side effect one of the things I've learned to help me get past it is to filter first based on licensing. I like Nixos, and I think the principles there are going to go far into the future, but I don't like MIT/BSD licenses. So if I want the same kind of tech, but in GNU-land, that leaves me with GUIX (the os and the package manager). Decision made.
Only in the most extreme circumstances do I violate these principles (steam for gaming!) and am always looking for alternatives as they pop up.
I really like the idea of compiled lisp eg common lisp, but most of the gpl friendly versions are not in active development, besides maybe Clozure CL. Clisp website shows last update was in 2010, and for some reason that really rubs me the wrong way.
It's funny because I still really don't know that much about lisp, it's just on my "to get into" list, besides elisp.
https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolch...
Apparently they dont like it that much
Here some axes of distinction:
1. supported programming styles
2. support for concurrency
3. performance of generated code and parallelism
4. floating-point performance
5. level of standardization
6. closeness to the system and capability to call into C functions, or functions with C ABI
7. suitability for scripting and stand-alone programs
8. GUI programming
9. Comprehensiveness and beginner-friendliness of documentation
10. REPL Programming
11. Libraries
12. Licenses
Here what I know about the languages you name:
(I also mention ABCL = Armed Bear Common Lisp a few times, just to illustrate that you also can run Common Lisp on the Java Platform).
1. supported paradigms - Clojure is very opiniated in supporting and demanding a purely functional style. It uses purely functional data structures. Racket and Scheme support a functional style well, but allow for seamless imperative code. Common Lisp is agnostic, one can program in a purely functional way and there are libraries with purely functional data structures, but it requires much more discipline.
2. Clojure has best support for concurrency and server-like tasks, it is made for that. Racket also supports green threads, apart from its places parallelism.
3. Racket, Chez, Common Lisp and so on support OS level threads and parallelism. Chez and Common Lisp stand out as they generate the most performant code - when it comes to raw computing power, single-threaded SBCL code will be faster than multi-threaded Clojure code. SBCL, for example, also allows to add compiler hints which generate unsafe code with better optimizations (for example, indicating that integer values will only be in a specific range).
4. SBCL has by far the best floating-point performance, I think Chez comes after that, and I'd expect Racket to improve further here. Racket has also been reviewed very favourably for scientific applications (https://khinsen.wordpress.com/2014/05/10/exploring-racket/ - Konrad Hinsen, the author, was an early contributor to Numerical Python).
5. Of all these, Common Lisp is standardized most. Especially Racket and Clojure are defined by their implementation.
6. Clojure and ABCL allow to call into Java. In turn, all of Common Lisp, Guile, Racket, Chez allow to call easily into C. There is a performance difference, I think, between most Schemes and SBCL: Calling into a C function has some extra cost because the stack is handled differently (I think it is because of continuations). I also tried to call into Rust functions from Racket and that works very nicely.
7. Clojure's startup time is simply too slow for scripting. It is also a bit hampered in that it runs on the JVM. There is babashka, which is interesting but has no mature status. Conversely, Common Lisp and Racket are well suited to scripting. It is also possible to compile SBCL and Racket programs into a single executable. I think SBCL supports this case best, for running Racket programs, an extra runtime library or a standard Racket installation is needed. Guile is also well-suited to scripting and is closer to the OS than some other Lisps.
8. Racket has a very nice support for GUI programming with a platform-independent functional API. Clojure and ABCL also allow to call into Swing and Fx code written in Java. I have not tried the rest but it looks relatively painful and brittle in comparison.
9. Racket has very comprehensive and high-quality documentation good for beginners. Clojure is also comprehensively documented, but might assume a bit more experience. Common Lisp is, as an open system, more eclectic, and ...
Guile and S7 are great for embedding in C programs. S7 is similar to Guile but permissively licensed.
Gambit and Chicken compile down to C if you want to work that way. Gambit is very fast, Chicken is extremely well documented and beginner friendly.
Clojure has by far the best books out for enterprise development and web dev if you want to build "normal" business apps and like books.
In the same way, Common Lisp uses Quicklisp, which runs on top of ASDF to automatically retrieve and compile libraries. It works very well.
One difference is that Quicklisp + ASDF often needs to be set up manually which can be a little bit more complicated (it is, however, contained in Debian as a package, for example).
Leiningen and Maven relay on version numbers for dependencies.
My understanding is that Quicklisp in practice uses a "rolling release" model similar to Arch Linux - you get a current distribution, where all packages are at their newest version, and if needed, one can also roll back to earlier versions of the whole distribution. That this works with elegance is related to one aspect of Common Lisp culture which is very, very different from, say, Python or Go: Common Lisp puts a lot of importance on backward compatibility and stable APIs, it is possibly the most backward-compatible of all dynamic languages.
Further, while Leiningen is a de facto standard which makes working with Clojure libraries essentially frictionles, Quicklist is just one modern way of multiple ways to include Common Lisp libraries.
This difference is owed to the trait that Common Lisp is much more an open system (which I consider a good thing), while Clojure is more uniform and "managed".
Another thing which may be nice to talk about is where the communities are for each language (Racket on Slack and the mailing lists, Common Lisp has an irc...).
As another example, I was talking to another one of the creators of the language and he called one of my collaborators a doofus and the educators at my university, which used to be John Hopkins University, a bunch of donkeys. I understand that he had some points to make about how educators work but this is not the way you make them, right?
It comes to a point that when I was talking to the students of these people, they're kind of afraid of talking to their advisors and I must admit that spending time with these people is one of the reasons why I decided to drop out of the PHD and leave academia all together, because if that's how it looks like to be successful in these communities I think I prefer to try to be successful somewhere else.
It is clearly geared to servers, for example sequences are always lazy. This is not always the best thing but for servers, it seems in general better.
However, there is a subtle point about parallelism: One typically wants concurrency and parallelism for one of three objectives:
1. Concurrency in servers
2. Graphical user interfaces
3. exploiting many cores for complex parallel computations, like number crunching
It turns out that Clojure is great for the first application. It also works for the second one.
However it is not that great for the third area of interest. The reason is performance. For example, floating point numbers passed in function arguments are often boxed. Also, due to the JVM it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector, even if the Clojure compiler partially tries to work around this.
And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure.
But I still think that immutability in-the-large is the right way to go.
It's kind of an oddball. While the development focus is mostly educational, specifically Programming Language theory, it's also very usable in the real world. There's a few tutorials on writing your own domain specific language in it. You can specify a language other than the default Racket, so one compiler/interpreter environment actually supports many Lisps and DSLs.
I'm a long time dev who recently picked up SICP to learn why everyone says learning Lisp/Scheme will make you a better programmer, and Racket is by far the most interesting environment I've worked in. I haven't even touched Python, which was my money-maker, in months.
You know what they say about emacs. "Emacs a great operating system, it's just lacking a decent text editor." Same with Racket. Racket is a great language development framework, the only thing missing is a decent language to write your program in.
It does take a lot more effort and expertise to design a language and a program. That's why it's fun for me, I get to dream more and need to learn more.
I'm inspired by the super interesting Racket papers [1] and PG's book "On Lisp". It helps that I got to use Racket to make a couple basic compilers in some uwaterloo classes too.. but I didn't even use macros for those projects, so I haven't really gotten started with Racket yet ;)
[1]: https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf
It also has a Big Idea; it aims to be the practical realization of the grand idea that Lisps are the perfect platform to build programming languages on, and to take this so radically far that you can have entirely different programming languages that nevertheless share, not just a runtime, but all their libraries. Unfortunately, so far, nobody except Racket enthusiasts appear to have much interest in building languages on top of Racket - but it's absolutely possible and practical, and someone really did accomplish the astonishing feat of implementing Python (Python 2, alas) in Racket, in such a way that you could combine libraries from both languages.
Congratulations to everyone involved into making this happen.
Can we appreciate the meta? A fast low-level program was re-written in a high-level language to reduce maintenance costs. These days on HN you usually only hear about the opposite, eg. Figma rewriting server Typescript code in Rust to improve performance [1]. Not fair to compare Rust to C, I know, but interesting nonetheless.
The loss of JIT was interesting. How does eval work? Apparently Chez Scheme AOT compiles code at runtime. Comparatively a JIT will change the compilation at runtime based on codepaths. There's a thread about that here [2].
Part of the motivation of CS was to make it easier for people to contribute to the compiler. I'm excited to see how that plays out.
Thanks again everybody. I'll go back to toying around with macros and tiny Racket programs now.
[1]: https://www.figma.com/blog/rust-in-production-at-figma/
[2]: https://news.ycombinator.com/item?id=16406391
Related, though not quit the same, is the manner in which the Cog VMs for Squeak/Pharo are developed:
"The VMs are developed in Smalltalk, using all the dynamic and reflective facilities of the Squeak/Pharo Smalltalk system. As such, developing in Cog is a delight. The Smalltalk framework comprising the various Cog VMs is translated into C by its Slang component to produce VM source that is combined with platform-specific support sources and compiled via a C compiler to obtain a fast production VM."
https://bintray.com/opensmalltalk/vm/cog/202101210320#read
And as a side effect make it faster on average. Very cool!
Meanwhile, for example, we can still count the number of web applications written in Racket on the fingers of one hand, and the number of Racket users in the racket group is rapidly decreasing from day to day.
Turns out the only users of Racket are people who live off Racket in a way that writes scientific articles that nobody cares about.
Very rare are those who use Racket for any practical purposes.
I wonder if it would have been better if this huge effort had been made to write clear documentation on how to use the Racket Web Library in a practical way? The current documentation for the web framework doesn't understand, I mean, even its creator, Jay McCarthy. I've never seen worse documentation on any software product than this for racket web library in my entire life.
On the other hand, we have this guy, Jesse Alama [2], who, like, wrote something about it. But there's literally not a single thing this guy published that he didn't charge her fattly. All his books and tutorials cost a lot and their quality is questionable.
But, unfortunately, these topics are a taboo in Racket community...
[1] https://blog.racket-lang.org/2021/01/racket-status.html [2] https://gumroad.com/jessealama
IMO, thinking that nothing important came out of Racket reseachwise is a highly uninformed opinion. I mean, dependent type systems as macros (therefore bringing true static types as a library)! Come on, is that not impressive?! Rewriting Scheme-on-Scheme to obtain something simpler and pretty much as fast as Scheme-on-C is not impressive!? A Scheme program that compiles to a C parallel GC is not impressive!?
On the contrary, the core Racket team is very, very impressive. Just not for the things you yourself wish for.
Racket is not well-suited for practical web-programming. Proof: For Python or Ruby, there are dozens of books explaining how to write web applications in them. But there's not a single good book for Racket (not just for web programming, but for anything).
Racket's authors use racket for their academic jerk-offs, but don't fog our eyes and tell us it's a practical language for real programmers, when it isn't.
If you are interested, you may refer to: https://github.com/ZelphirKaltstahl/racket-markdown-blog/tre...
I did never bring it online, as I never rented a server for it, but it definitely functions and I had some local posts, which I did not include in the repository.
Did you never have a software without documentation? I think that would be way worse than having a sort of OK documentation of a bare bones web framework, that is actually understandable, with careful reading.
The Racket mailing list is also very helpful and people there are helpful in my experience. Show them you tried and your attempt at things and they'll probably help you out. My only pain with it is, that they are on Google groups.
On the other hand, negative ranting about how everyone is wasting their time, how particular people are terrible, or how charging money for a book is inappropriate -- those are discouraged, and thankfully.
And yes, the documentation is poor. I'm experienced developer and could tell that. Check this mess: https://docs.racket-lang.org/web-server/stateless.html#%28pa... WTF?
Are you going to tell us all books about your pet language are worth their price? How is that the community's problem?
All of this will not happen, of course, because there is no such application written in the Racket in the world (no wonder when the documentation is so awful!)
When there's at least one, let me know.
Believe what? I've said nothing hinting at racket being good for web programming. What I do say is that you are missing the forest for the tree. You should probably go back to rails or django, as you'll be much happier there.
And if like your username and debate abilities suggest you are really 20 years old you can't present yourself as "an experienced developer", sorry for being blunt. Regarding Racket at least, you have a lot left to learn.
I'm running the webserver so the T.A. in my department in the university choose they preferred building/course/day/hour to work. They are ~400. The first year I was worried that the server would collapse or something. Now I assume it is working unless I get many angry emails. (I don't remember the last time I had problems, most of the emails are about changes in the available courses and other administrative stuff.)
Back to stuffer, you can use the default stuffer or just ignore that stuffers exist at all, unless your site is huge.
This is just a blatant misunderstanding of what Racket on Chez is trying to do, and a very limited understanding of what “optimization” means for something as complex as a compiler/interpreter. The point of the Chez backend is to improve maintainability and portability, not to increase speed [1]. Racket used to have a custom Scheme interpreter with a lot of custom C that was difficult to work with, so instead a lot of that code was ported to Chez - easier for everyone, especially Racket devs, even if it might take a while to smooth out some of the (very modest) performance hits.
And since you’re obviously totally ignorant as to why Racket decided to do all this work, it makes it hard to take your rant seriously.
[1] https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf
The very fact that they did this tells us a lot about Racket's community “achievements”!
Did you know Idris also runs on Chez? Does that also say a lot about Edwin Brady's achievements?
This is pure nonsense.
If you don't mind crappy graphics with numbers pulled out of the air https://imgur.com/a/9r0aJzd The idea is trading a slower development speed for some time, to get more speed and features in the long run.
Perhaps the change in the slope in BC is too much, and the current speed of CS is greater than the imaginary speed of a version of BC in an universe where BC didn't happen. I hope the crappy graphic in Paintbrush is enough to make it clear that the numbers are pulled out of the air. Anyway, one of the hard fact of the blog post submitted here is that in most cases the current version of CS is faster than the current version of BC.
I wrote my stuff to help people get into web development with Racket. I love web devel, and Racket, too. You and I have a lot in common: I found the official docs puzzling, so I worked out my own approach to them and made _Server: Racket_. It should go without saying that that's the origin story of just about every paid book out there on applications of programming language X to domain Y. That's not even a criticism of the Racket docs. Plenty of tools/languages also have good docs, and there are lots of books, too. How many Django books (or even courses) are out there?
There are also some great web programming tutorials out there for Racket, too. I recommend this one, by Racket star Jens Axel Søgaard: https://github.com/soegaard/web-tutorial .
I hope you'd give Racket a chance. Since you're talking about it, it sounds like you're dipping your toes in the waters. I'm pretty sure you'll find them quite welcoming. That said, all this negativity is pretty off-putting.
I'm excited about Chez for the performance gains, and I think it's really nifty that it allows more of Racket to be written in Scheme.
In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc. This means that even many cases of hidden otherwise "safe" mutability might lead to bad results.
Which is why scheme tends towards immutability. That is the safe thing, culturally and also by design. Whereas the happy path for python is generally one of mutability, the happy path for scheme is not.
Which is also something that I try to keep in mind when learning a new language. It is very tempting to try to write scheme in another language, but doing so in python will lead to sadness.
I have seen so many people trying to learn scheme by trying to write python in scheme, which usually ends up being awkward, slow and buggy in addition to not working with call/cc or delimited continuations.
I had an epiphany about this when trying to write scheme in rust. I took a step back and realized that I was the python programmer :)
Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs.
However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives:
1. Concurrency in servers
2. Graphical user interfaces
3. exploiting multiple cores for complex parallel computations, like number crunching
It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors).
However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector.
And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure.
This is a drawback which is rooted by the implementation.
But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.
[1] https://www.edx.org/course/how-to-code-simple-data
[2] https://www.edx.org/course/how-to-code-complex-data
Check 'Getting started' above, but I'd suggest that if you are already a developer, start with the Racket Guide, and 'How to Program Racket: a Style Guide' both available in the documentation site https://docs.racket-lang.org (and bundled with the installer). The Racket Guide is fully integrated with the Reference - click on something and it will take you to the reference for the full definition.
It's also worth working through HTDP https://htdp.org - with the caveat that you are using the teaching languages. A really nice thing is Racket can support students/learners, without compromising the full language. The Racket installer includes Racket, proper, the teaching languages, and a number of other languages.
https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
> It would be nice if porting to Chez Scheme made every aspect of Racket magically faster. It hasn’t done that, but we have plenty of room for improvement; the performance results to date are a lower bound on performance, not an upper bound.
> Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance. The Racket-on-Chez implementation is far more maintainable and flexible than the current Racket implementation, so maybe we’re half-way there after one year of work.
The fact that the performance looks this good is a huge win. And the focus on maintainability over speed is a refreshing sight. This is the sort of practical solution that will allow Racket to be relevant for many years to come. Racket is a good all around Scheme, there are other schemes that do certain aspects of what Racket can do better, but as a whole Racket is a very complete package.
I have two main criticisms with Racket, which are totally fixable, and in large part due to Racket's history as an incubator for language oriented programming, developed by PhDs in Comp Sci. Racket is very Academic. The documentation is great, but it is written by other Academics and can be hard to grok. Same with example code. Sure if you are looking at the student languages and tutorials based on that it is more accessible, but the minute you are trying to write a complex GUI app in typed Racket, the tutorials and example code is few and far between. Sometimes it makes me feel like I'm to dumb to be using the language, and I feel like I'm not the only one to get that feeling.
Also for a language that prides itself on Language Oriented Programming, I want to some more examples/tutorials that are not just using brain fuck language. These are fixable, and I admit some are just me problems, but I'm actively working to solve them in this space.