Live data from Hacker News

Racket Compiler and Runtime Status

blog.racket-lang.org

81–90 of 102 posts

Re: Racket Compiler and Runtime Status

#81
post #73

Earlier quoted context omitted.

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.

Re: Racket Compiler and Runtime Status

#82

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 accept…

[deleted]

Re: Racket Compiler and Runtime Status

#83
post #13

Earlier quoted context omitted.

If you want batteries included and probably the nicest runtime of all the lisps I would suggest racket. I use guile since I think it more fun, but racket is a lot easier if you want libraries around.

Thank you for the feedback! In what way is Guile more fun?

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.

Re: Racket Compiler and Runtime Status

#84

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

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,…

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.

Re: Racket Compiler and Runtime Status

#85

Earlier quoted context omitted.

> 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 portabi…

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…

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

Re: Racket Compiler and Runtime Status

#86

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

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 this might lead especially beginners to underestimate how mature and good it is. It is very under-hyped compared to Clojure. But there is the Common Lisp Cookbook on the web, which is really good. I can also warmly recommend the books "Practical Common Lisp" by Peter Seibel, and "Common Lisp Recipes" by (corrected!) Edmund Weitz. If you want to have true understanding, and are about to write industry-grade robust software, they are really worth every cent.

10. REPL Programming: Lisps and Schemes such as Racket have a subtle difference which affects the style of programming. In Lisp, everything is dynamic and you can re-load and evaluate parts of the program when it is running. This makes for a great development environment. In contrast to that, Racket for example has a clear distinction between compilation time and run time, which gives certain safety and correctness guarantees, but requires that the program is re-loaded more often during development.

11. Libraries: Racket has a distinct "Batteries included" feeling which makes it nice for beginners. Clojure uses Leiningen which runs on top of Maven to automatically retrieve libraries, it works very well. Racket has a similar system. Common Lisp is more eclectic again, what is used today is quicklisp and asdf (see the Common Lisp Cookbook). There is also a reasonable support in OS Packages e.g. in Debian, and in addition GNU Guix is a very interesting solution for packaging of Lisp libraries and in polyglot projects.

12. Licenses: Clojure has a non-copyleft license (Eclipse License) which might be an obstacle if you want to publish copyleft libraries and code (not sure about the exact limits here but the problem is that in a Lisp system, there is less clear of a boundary of system or language code and your own code, so it is probably advisable to use a language with compatible license if you want to publish copyleft code). Racket is Apache 2 which is GPL compatible. Guile is, as part of the GNU system, GNU LGPL.

In summary, I think Racket is great for beginners, although you could start with all of them. Clojure is fantastic for servers and to learn about functional programming. Guile and Racket are great for scripting. Common Lisp, and especially SBCL requires a bit more learning effort at the beginning, but it is a really mature and highly performant system which gives you a lot of freedom.

Re: Racket Compiler and Runtime Status

#87
post #10

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

If you want live image reloading stick to a Lisp like SBCL rather than Scheme. 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.

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.

Re: Racket Compiler and Runtime Status

#88
post #52

what's a good textbook/tutorial for someone self-teaching Racket to follow along?

Go here for guidance: https://docs.racket-lang.org/getting-started/index.html

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.

Re: Racket Compiler and Runtime Status

#89
post #86

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

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…

This is very good, I agree with almost everything. I would add the following:

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.

Re: Racket Compiler and Runtime Status

#90
post #86

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

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…

> Clojure uses Leiningen which runs on top of Maven to automatically retrieve libraries, it works very well.

In the same way, Common Lisp uses Quicklisp, which runs on top of ASDF to automatically retrieve and compile libraries. It works very well.

Post reply on HN