
Rebuilding Racket on Chez Scheme Experience Report [pdf] - hencq
https://www.cs.utah.edu/plt/publications/icfp19-rddkmstz.pdf
======
darkpuma
> _" The main Racket distribution now consists of roughly 1.2M lines of Racket
> (including 270k lines of documentation source), but that code is still
> supported by roughly 200k lines of C. Large parts of Racket’s implementation
> remain in C only because the original interpreter was in C, and all of that
> C code is relatively difficult to maintain."_

For context, cloc says that Chez Scheme has ~100k lines of scheme code and 16k
of C (plus 15k of C headers.) I didn't know Chez was that much smaller than
racket/base; that's pretty cool. 16k instead of 200k is a huge difference.

~~~
dleslie
I think that is fair to say that Chez is something of a marvel; though
gambitc/gerbil is nipping at its heels.

------
threepio
I've been hearing nothing but good things about Racket for the last few years.
I finally downloaded it last month. It really just puts a silly smile on your
face. The language-oriented programming is terrific too. I really want to find
ways to integrate Racket into my work.

~~~
gnulinux
> I really want to find ways to integrate Racket into my work.

Normally engineers search for tools to solve their problems. Somehow, when it
comes to programming languages, software engineers start a search for problems
for their cute tools. Please don't get me wrong, I'm not making a snarky
comment against lisp. I'm very much in love with lisp, but I do understand how
people see us lisp people like bunch of gray wizards in some remote castle.
What needs to be shown is a set of problems that can adequately be solved by
racket that cannot be solved as well with competing languages. We should
really stop treating programming languages anything other than tools. I use
GNU grep for 20 years, one day I realize ripgrep is better, I switch.

Again, I want to underscore that I'm not saying that particularly disagrees
with you. I just don't think this rhetoric is helpful. We should be thinking
about what makes racket that puts a smile on our face, and discuss whether we
can use these tools in other languages. Not that this is not being discussed,
of course.

~~~
scottlocklin
One of the things that boggles me about Lisp is there seem to be more lisps
and schemes out there than significant applications built in them. I say this
as a former lisp weenie (and present day J bum). It's certainly more fun to
develop in Lisp than Javascript, but ... for all these tales of power its
achievements since Macsyma seem lacking.

I mean, someone must be building stuff with all these lisps that gets used,
but compared to, say, Javascript or Java, it seems most lisp developers
develop new dialects of lisp. I guess this isn't unexpected as it was
originally a language for developing interpreters (aka "AI v1" expert system
shells).

~~~
sansnomme
(I am referring to Lisp here as mostly the Common Lisp and the Scheme variety)

There is also the issue where are a lot of areas like UX and tooling requires
boring engineering work that no wants to put in. Dependency management,
language servers, static analysis etc.

Scheme is stuck in academia; its creators are more interested in forcing
language constructs like Continuation Passing Style onto end users rather than
fixing ecosystem problems. Despite having a multitude of standards, every
Scheme has to roll its own dependency manager. Chicken libraries aren't
directly compatible with Gambit and good luck with Racket's licensing.

Quicklisp is relatively recent and a lot of books that are considered
"standard reading" are so old that they don't mention it. Simple things like
exporting a binary using save-image-and-die etc. don't work properly, easy
Rust/Go style cross platform compilation support is almost non-existent and
the whole process is extremely flaky in general. Stuff like Roswell improves
the UI a bit but the underlying foundation is extremely barebones. Now most of
these problems would go away with proper funding. But the major users of Lisp
tend to be small niche companies in areas like natural language processing and
quantum computing. They are not Sun, they are not Google. They never had to
onboard a tremendous amount of new people in a short time. They have their
pick of a community with too much supply and not enough demand. The people in
charge of using them are happy to stay within the safe walls of Emacs and
tradition, expecting all newcomers to do the same. They are not gonna drop a
couple million of investment to fund tooling and infrastructure. Even with
Clojure where you have new editors and tooling the language authors are
infamous for being reluctant to address user needs and concerns at a core
level. Forget about a language whose ANSI standard has never seen an update
for 2 decades and whose improvements are fueled by a hodgepodge of mildly
incompatible language extensions and macros. Sure there are two new compiler
projects in CL that are coming along nicely, but they are not dedicating the
attention to UX that languages like Elixir do. The CL21 project looks nice on
paper but never caught on, and everyone is happy to push for more compiler
implementations instead. A lot of the compilation and ecosystem stuff that are
really important such as mobile, Web, GUIs etc. are tied to proprietary
software. Sure the situation is improving with electron and I heard that the
Qt binding is slightly better these days but the language situation resembles
more to closed sourced relics like Embarcadero Delphi than the highly vaulted
insane-productivity-startup-secret-weapon that HN seem to give the impression
of.

~~~
neilv
What's the barrier with Racket's licensing? It's currently LGPL (looks like
v3).

[https://docs.racket-lang.org/license/index.html](https://docs.racket-
lang.org/license/index.html)

[https://github.com/racket/racket/blob/master/racket/src/COPY...](https://github.com/racket/racket/blob/master/racket/src/COPYING_LESSER.txt)

~~~
soegaard
Adding to Neil's answer:

Racket is currently being relicensed as MIT / Apache 2.

[https://github.com/racket/racket/issues/1570](https://github.com/racket/racket/issues/1570)

It's a slow process though. Not because people object to relicensing, but some
people are no longer in contact with the Racket community and they can be
difficult to find.

------
hencq
Very cool to see that this is getting ready for prime time. It seems they
succeeded in achieving the primary goal of making the implementation more
maintainable and easier to work with. But the lesser goal (or perhaps non
goal, but something some people might have secretly hoped for) of inheriting
some of Chez's speed hasn't really panned out (yet).

------
rurban
I would recommend either a change to lazy jit compilation, or dumping the
jitted image, for the startup-time problem.

