Racket-On-Chez Status: January 2019 | Hacker News Reader

Racket-On-Chez Status: January 2019

blog.racket-lang.org

175 pointsbwidlar32 comments

So the benchmarks show that everything is faster with Chez Scheme, except VM startup is slower? That seems to be the prevailing trend in VMs.

Python 3 is the same way now -- everything is faster than Python 2, except startup. There was a good PyCon talk showing this, but this message also gives some numbers [1].

I have a prototype of a shell solution to this here:

Shell Protocol Designs http://www.oilshell.org/blog/2018/12/05.html#toc_2

https://github.com/oilshell/shell-protocols/tree/master/copr...

It requires around 100 lines of code in the VM or application, assuming the application can make the dup2() libc call and such. If anyone wants to help prove the protocol, let me know :)

[1] https://mail.python.org/pipermail/python-dev/2017-July/14865...

edit: I misread the graphs -- some non-startup stuff is slower with Chez, but it doesn't change my overall point :)

Racket has a special place in my heart. Racket, together with https://htdp.org/, helped me reach a point where I felt my code truly reflected the structure I was modeling. It helped me focus on data flowing through my code, rather than blindly following "cookbooks". Racket is one of the very few languages that get out of your way, so that the model is almost tangible.

Code design is what keeps complex projects from collapsing under their own weight. There are always trade-offs when constructing software, but I feel that design is often neglected needlessly.

Would you recommend that book to experienced programmers?

Yes. Especially programmers who have less or little formal computer science or even software engineering background. HTDP is a fantastic book.

Talk by Matthew Flatt on why they are doing this:

https://www.youtube.com/watch?v=t09AJUK6IiM

Great news on the status! I use both Chez and Racket and I look forward to having the merged Chez backend being the default. I am going to try Racket CS soon, and hopefully I can immediately switch.

How would you compare / contrast Chez and Racket? I'd be interested in hearing your thoughts.

From what I can tell (and I may be wrong), some differences are:

  - Chez has parallel threads (that can run on multiple cores)
  - Racket seems to have some higher level concepts and more learning material
  - Racket has multiple "languages" and facilitates making your own; see: Beautiful Racket[0]
  - Chez is faster than Racket

[0] https://beautifulracket.com/

I like the fast 'bare bones' Chez implementation, but, I also appreciate the huge ecosystem around Racket.

Huge as in huge, or huge as in huge for a niche language?

Decide for yourself: https://pkgs.racket-lang.org/

Did I read ~1000 packages? That's great for a small community and bigger than last time I checked a few years ago. It has a long way to go to get to CPAN or Nuget size though (captain obvious to the rescue :)). I think it demonstrates that the community is healthy though and I like the packages I saw by some brief browsing.

The Racket standard library also has a lot of good stuff in it. There are many batteries included.

Chez is a scheme, whereas Racket is basically a scheme but was renamed from PLT-Scheme because the authors/community felt it had strayed far enough from scheme that a renaming was a good idea.

It's still basically scheme though. I mean, if you're coming from a scheme background the only thing that might trip you up in racket is cons cells are immutable. If you only have racket experience and try out [another] scheme, you might experience some culture shock when you start encountering stuff like let-values being in srfi-11 instead of racket/base. In my opinion, racket is generally a more pleasant experience. Virtually all of my personal/recreational projects are in racket these days.

Will this work also help other alternative implementations like pycket [1]? As a layman it seems like making things more maintainable and less tied to C would help, but I'm curious if someone has more insights.

[1] https://github.com/pycket/pycket

Yes, pycket now uses significant parts of the code developed as part of Racket-on-Chez, and it's helped us implement lots more of the full system.

As language geek I love the ongoing work on Racket CS.

This is a good way to improve language implementations with safer technology stacks.

Maybe I missed some context; is there a reason that Racket is moving away from their own VM?

They are trying to move from their C-based implementation to Chez Scheme for maintainability. Since Racket programmers are familiar with Scheme, using a Scheme for the implementation has obvious advantages. They're also using it as an opportunity to "do things the right way this time".

Along these lines:

> Putting a number on maintainability is less easy than measuring benchmark performance. Anecdotally, as the person who has worked on both systems, I can report that it’s no contest. The current Racket implementation is fundamentally put together in the wrong way (except for the macro expander), while Racket CS is fundamentally put together in the right way. Time and again, correcting a Racket CS bug or adding a feature has turned out to be easier than expected.

Last year's post has some details on the organization of the Racket codebase and why some of the layers are being moved to Chez.

https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...

Does this mean that Racket is now R7RS compatible?

You assuming Chez is R7RS compliant?

I thought I read somewhere that it was. Am I mistaken?

> As a superset of the language described in the Revised6 Report on the Algorithmic Language Scheme (R6RS), Chez Scheme supports all standard features of Scheme [...]

https://github.com/cisco/ChezScheme

No. Racket CS depends on many features of Chez Scheme not in R7RS.

This doesn't preclude R7RS compatibility, does it?

Well, Racket CS is "just" standard Racket running on Chez Scheme instead of the old Racket VM. Therefore no changes has been made to Racket (the language) - and thus there is no R7RS compatibility (which wasn't and still isn't a goal for Racket).

No idea, but related question: does anyone know the status of r7rs-large? (r7rs-small has been done for a few years AFAIK...)

There's been ongoing votes for what's to be included. It is coming along.

No, it doesn't; Racket-on-Scheme is just a change of implementation, not (in any large way) user-exposed language.

OTOH, at least one R7RS implementation for Racket exists.

More details: Link to the (unofficial) r7rs package https://pkgs.racket-lang.org/package/r7rs

The GitHub page has the details about the installation (it's quite straightforward), how to use it and compatibility with the standard. https://github.com/lexi-lambda/racket-r7rs

Reply on news.ycombinator.com