Life goal: outlive dynamic type checking.
Welcome to Racket, then:
https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
Racket Compiler and Runtime Status
61–70 of 102 posts
Re: Racket Compiler and Runtime Status
#62I 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 Rack…
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 :)
Re: Racket Compiler and Runtime Status
#63Earlier quoted context omitted.
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…
Fedora just announced to kill the Guile bindings for GNU make and GDB. https://fedoraproject.org/wiki/Changes/RemoveGuileFromToolch... Apparently they dont like it that much
Nobody uses them. Guile users tend to go "oooh, neat!" until they realize that the supported version is ancient.
Re: Racket Compiler and Runtime Status
#64I'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.
Re: Racket Compiler and Runtime Status
#65Thanks 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.…
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...
[1] https://blog.racket-lang.org/2021/01/racket-status.html [2] https://gumroad.com/jessealama
Re: Racket Compiler and Runtime Status
#66Thanks 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.…
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,…
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.
Re: Racket Compiler and Runtime Status
#67Life goal: outlive dynamic type checking.
The Racket distribution has many languages, so you can use Typed Racket instead https://docs.racket-lang.org/ts-guide/quick.html
Re: Racket Compiler and Runtime Status
#68Thanks 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.…
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,…
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.
Re: Racket Compiler and Runtime Status
#69Earlier quoted context omitted.
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,…
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?
Re: Racket Compiler and Runtime Status
#70Thanks 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.…
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,…
> 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