Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Racket Compiler and Runtime Status

blog.racket-lang.org

Post reply on HN
Print view View original

41–50 of 102 posts

Re: Racket Compiler and Runtime Status

#41

Post by sitkack »

samth wrote: post #11
sitkack wrote: post #6

Interesting I was just looking at the Chez Scheme backends and didn't remember seeing aarch64, just 32 bit arm. And then I found this 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

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

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

What are your thoughts on Shen?

Re: Racket Compiler and Runtime Status

#42

Post by Zuider »

chromatin wrote: post #36
DC1350 wrote: post #5

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?

If my memory serves me correctly, you are currently reading and posting on a website written in Racket.

HN is written in Paul Graham's Arc language, specifically, a language built in Racket.

Re: Racket Compiler and Runtime Status

#43

Post by sevensor »

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.

Re: Racket Compiler and Runtime Status

#44

Post by Zuider »

srcreigh wrote: post #31

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

>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

Re: Racket Compiler and Runtime Status

#45

Post by samth »

sitkack wrote: post #41
samth wrote: post #11

Earlier quoted context omitted.

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

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…

Paulo Matos is working on a RISC-V backend.

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.

Re: Racket Compiler and Runtime Status

#46

Post by bmitc »

behnamoh wrote: post #23
fantispug wrote: post #12

Earlier quoted context omitted.

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.

One could also argue that DSLs are not always good esp. in large projects maintained by many devs.

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.

Re: Racket Compiler and Runtime Status

#47

Post by bmitc »

pjmlp wrote: post #30
gypsyharlot wrote: post #8

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

In that case just pick the scheme dialect used by SCIP. 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 var…

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.

https://docs.racket-lang.org/sicp-manual/SICP_Language.html

Re: Racket Compiler and Runtime Status

#48

Post by bmitc »

gypsyharlot wrote: post #8

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

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.

Re: Racket Compiler and Runtime Status

#49

Post by arminiusreturns »

gypsyharlot wrote: post #8

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

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.

Re: Racket Compiler and Runtime Status

#50

Post by omaranto »

srcreigh wrote: post #31

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

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

Post reply on HN