>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."

https://bintray.com/opensmalltalk/vm/cog/202101210320#read

> A fast low-level program was re-written in a high-level language to reduce maintenance costs.

And as a side effect make it faster on average. Very cool!

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.

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.

> 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.

[1] https://www.cs.utah.edu/plt/publications/icfp19-fddkmstz.pdf

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.

"Future versions of Racket CS" appears twice on the graph. It still understandable though.

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”!

This is a strange, strange view of things. I guess all languages running on LLVM are parasites too, then.

Did you know Idris also runs on Chez? Does that also say a lot about Edwin Brady's achievements?

This is pure nonsense.

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.

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.

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.

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...

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.

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?

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!)

When there's at least one, let me know.

> rscho, I'll believe you when...

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.

Stuffers are a very low level part of the webserver. I had no idea they exist until now. It's better to link to https://docs.racket-lang.org/web-server/run.html

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.