
Racket-On-Chez Status: January 2019 - bwidlar
https://blog.racket-lang.org/2019/01/racket-on-chez-status.html
======
chubot
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](http://www.oilshell.org/blog/2018/12/05.html#toc_2)

[https://github.com/oilshell/shell-
protocols/tree/master/copr...](https://github.com/oilshell/shell-
protocols/tree/master/coprocess)

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...](https://mail.python.org/pipermail/python-
dev/2017-July/148656.html)

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

------
nur0n
Racket has a special place in my heart. Racket, together with
[https://htdp.org/](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.

~~~
Buttons840
Would you recommend that book to experienced programmers?

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

------
AlexanderDhoore
Talk by Matthew Flatt on why they are doing this:

[https://www.youtube.com/watch?v=t09AJUK6IiM](https://www.youtube.com/watch?v=t09AJUK6IiM)

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

~~~
Buttons840
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/](https://beautifulracket.com/)

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

~~~
4thaccount
Huge as in huge, or huge as in huge for a niche language?

~~~
darkpuma
Decide for yourself: [https://pkgs.racket-lang.org/](https://pkgs.racket-
lang.org/)

~~~
4thaccount
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.

------
hencq
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](https://github.com/pycket/pycket)

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

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

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

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

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

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

------
pmoriarty
Does this mean that Racket is now R7RS compatible?

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

~~~
gus_massa
More details: Link to the (unofficial) r7rs package [https://pkgs.racket-
lang.org/package/r7rs](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](https://github.com/lexi-
lambda/racket-r7rs)

