11 ms·

Racket Compiler and Runtime Status

180 points by gleb_the_human 6y ago

kogir 6y ago
If HN ends up moving to the CS runtime I'd love to hear a high level summary of what work it required and how the new runtime performs.
- the-smug-one 6y ago
  You can run (what I suspect is an old version of) HN yourself: http://arclanguage.org/install http://arclanguage.org/install
deleted 6y ago
[deleted]
arc-in-space 6y ago
I'm glad Racket CS happened(even though I don't use Racket), because I was worried about the future of chezscheme's maintenance. It's a runtime with good portability(Guile Scheme, for instance, seems to pretend Windows doesn't exist), and I think it'd be a shame to see it fade away in the future.
- deleted 6y ago
  [deleted]
- bjoli 6y ago
  There is a branch being pushed to while we speak on the guile git to update the mingw support. I don't know what it means in practice, but maybe windows support for guile 3 is getting closer.
DC1350 6y ago
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?
- patrec 6y ago
  Carmack would have used it for Oculus, had management not said no. https://twitter.com/id_aa_carmack/status/807797812700348416 https://twitter.com/id_aa_carmack/status/807797812700348416
  - Blikkentrekker 6y ago
    Javascript would have been a Scheme dialect, had it not been that NetScape's management said no.
- soegaard 6y ago
  The Racket distribution comes with several languages. You were probably using the socalled teaching languages, which are small subsets of real Racket. Using a subset of the real language allows better and more beginner friendly error messages. The real Racket language is a general purpose language with all the bells and whistles you could ever imagine.
  - ashton314 6y ago
    Plus some bells and whistles that you can’t! It’s really impressive, and I’ve found Racket’s documentation to be excellent.
- fantispug 6y ago
  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.
  - behnamoh 6y ago
    One could also argue that DSLs are not always good esp. in large projects maintained by many devs.
    - 6y ago
sitkack 6y ago
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 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 https://github.com/racket/ChezScheme
- samth 6y ago
  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 back to pure upstream Chez in the near future, but it's not quite a fork either. You can read more about some of these issues in our ICFP 2019 paper: https://www.cs.utah.edu/plt/rkt-on-chez/ https://www.cs.utah.edu/plt/rkt-on-chez/ which is co-authored with the Chez maintainers.
  - sitkack 6y ago
    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?
    - samth 6y ago
      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.
gypsyharlot 6y ago
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).
- fredrikholm 6y ago
  Racket if you're interested in a more "pure" lisp and/or metaprogramming/DSLs. Clojure if you're looking to use the language directly to solve your problems (and my preferred Lisp).
- yw3410 6y ago
  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.
  - mepian 6y ago
    SBCL is an implementation of Common Lisp, to be precise. There is also CCL, or Clozure Common Lisp, which has the best support for macOS.
  - jnxx 6y ago
    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.
  - kazinator 6y ago
    If you learn Clojure, you will not jump into Lisp without too much trouble.
    - jnxx 6y ago
sachanganesh 6y ago
What is Racket primarily used for? I'm not sure where it fits in the language landscape in terms of strengths/weaknesses.
- desine 6y ago
  It's a Lisp, in the Scheme subset. It's original design was primarily around Programming Language Theory education - formerly it was PLT Scheme. Much of it was designed for educational uses, but it's a really well-rounded system with plenty of packages, a decent package management system, better performance than most interpreted languages. It comes with an IDE easier to pick up for newbies than Emacs (the usual Lisp/Scheme environment), but also runs fine as a command line REPL and compiler. It's kind of an oddball. While the development focus is mostly educational, specifically Programming Language theory, it's also very usable in the real world. There's a few tutorials on writing your own domain specific language in it. You can specify a language other than the default Racket, so one compiler/interpreter environment actually supports many Lisps and DSLs. I'm a long time dev who recently picked up SICP to learn why everyone says learning Lisp/Scheme will make you a better programmer, and Racket is by far the most interesting environment I've worked in. I haven't even touched Python, which was my money-maker, in months.
- stretchcat 6y ago
  To me, it's the language I use when I want to have fun.
  - srcreigh 6y ago
    Same. I learn so much when I try to do something with it. You know what they say about emacs. "Emacs a great operating system, it's just lacking a decent text editor." Same with Racket. Racket is a great language development framework, the only thing missing is a decent language to write your program in. It does take a lot more effort and expertise to design a language and a program. That's why it's fun for me, I get to dream more and need to learn more. I'm inspired by the super interesting Racket papers [1] and PG's book "On Lisp". It helps that I got to use Racket to make a couple basic compilers in some uwaterloo classes too.. but I didn't even use macros for those projects, so I haven't really gotten started with Racket yet ;) [1]: https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf
rcarmo 6y ago
This is nice to see. I’ve played around with Chez and Racket separately, and even though I’m now focusing on bare metal/JIT again, I look forward to using the new Racket.
ampdepolymerase 6y ago
Congrats on the release. What Racket really needs right now is a proper dependency manager with support for constraint solving and allowing multiple conflicting transitive dependencies. Cargo and yarn are the gold standard for this. A lot of Lisps tend to overly focus on language and compiler features and neglect the more boring tooling and infrastructure that makes a programming language successful.
- samth 6y ago
  You might be interested in https://docs.racket-lang.org/xiden-guide/index.html https://docs.racket-lang.org/xiden-guide/index.html (Sage also gave a talk at RacketCon 2020 about it).
pjmlp 6y ago
Love it, it is finally here! Congratulations to everyone involved into making this happen.
srcreigh 6y ago
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. How does eval work? Apparently Chez Scheme AOT compiles code at runtime. Comparatively a JIT will change the compilation at runtime based on codepaths. There's a thread about that here [2]. Part of the motivation of CS was to make it easier for people to contribute to the compiler. I'm excited to see how that plays out. Thanks again everybody. I'll go back to toying around with macros and tiny Racket programs now. [1]: https://www.figma.com/blog/rust-in-production-at-figma/ https://www.figma.com/blog/rust-in-production-at-figma/ [2]: https://news.ycombinator.com/item?id=16406391 https://news.ycombinator.com/item?id=16406391
- samth 6y ago
  eval works very similarly to how it worked before -- when you eval some code it compiled it and then runs it. Every* Scheme or Lisp system supports this kind of compilation-at-runtime, and Chez is no exception.
- Zuider 6y ago
  >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 https://bintray.com/opensmalltalk/vm/cog/202101210320#read
- omaranto 6y ago
  > 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!
Bost 6y ago
See also https://youtu.be/s3Q3M2wZ7rI https://youtu.be/s3Q3M2wZ7rI
sevensor 6y ago
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.
- bjoli 6y ago
  Anyone writing scheme/racket like python is in for a bad time. I think languages either tend towards mutability or immutability. In clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc. This means that even many cases of hidden otherwise "safe" mutability might lead to bad results. Which is why scheme tends towards immutability. That is the safe thing, culturally and also by design. Whereas the happy path for python is generally one of mutability, the happy path for scheme is not. Which is also something that I try to keep in mind when learning a new language. It is very tempting to try to write scheme in another language, but doing so in python will lead to sadness. I have seen so many people trying to learn scheme by trying to write python in scheme, which usually ends up being awkward, slow and buggy in addition to not working with call/cc or delimited continuations. I had an epiphany about this when trying to write scheme in rust. I took a step back and realized that I was the python programmer :)
  - jnxx 6y ago
    > I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs. However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives: 1. Concurrency in servers 2. Graphical user interfaces 3. exploiting multiple cores for complex parallel computations, like number crunching It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors). However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector. And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure. This is a drawback which is rooted by the implementation. But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.
fhe 6y ago
what's a good textbook/tutorial for someone self-teaching Racket to follow along?
- shawnps 6y ago
  When I was learning in university, How to Design Programs was the textbook: https://htdp.org/2020-8-1/Book/index.html https://htdp.org/2020-8-1/Book/index.html
  - bhrgunatha 6y ago
    There are 2 edx courses based on the book too for those who prefer video instruction. [1] https://www.edx.org/course/how-to-code-simple-data https://www.edx.org/course/how-to-code-simple-data [2] https://www.edx.org/course/how-to-code-complex-data https://www.edx.org/course/how-to-code-complex-data
- spdegabrielle 6y ago
  Go here for guidance: https://docs.racket-lang.org/getting-started/index.html 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 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 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.
dogfishbar 6y ago
Life goal: outlive dynamic type checking.
- rscho 6y ago
  Welcome to Racket, then: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf&ved=2ahUKEwiwy8212LbuAhUP_KQKHc9PCLsQFjAAegQIARAB&usg=AOvVaw2dG6VNUS-pOHGw0ojEVXpJ https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
- gus_massa 6y ago
  The Racket distribution has many languages, so you can use Typed Racket instead https://docs.racket-lang.org/ts-guide/quick.html https://docs.racket-lang.org/ts-guide/quick.html
Decabytes 6y ago
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 acceptable performance. The Racket-on-Chez implementation is far more maintainable and flexible than the current Racket implementation, so maybe we’re half-way there after one year of work. The fact that the performance looks this good is a huge win. And the focus on maintainability over speed is a refreshing sight. This is the sort of practical solution that will allow Racket to be relevant for many years to come. Racket is a good all around Scheme, there are other schemes that do certain aspects of what Racket can do better, but as a whole Racket is a very complete package. I have two main criticisms with Racket, which are totally fixable, and in large part due to Racket's history as an incubator for language oriented programming, developed by PhDs in Comp Sci. Racket is very Academic. The documentation is great, but it is written by other Academics and can be hard to grok. Same with example code. Sure if you are looking at the student languages and tutorials based on that it is more accessible, but the minute you are trying to write a complex GUI app in typed Racket, the tutorials and example code is few and far between. Sometimes it makes me feel like I'm to dumb to be using the language, and I feel like I'm not the only one to get that feeling. Also for a language that prides itself on Language Oriented Programming, I want to some more examples/tutorials that are not just using brain fuck language. These are fixable, and I admit some are just me problems, but I'm actively working to solve them in this space.
- deleted 6y ago
  [deleted]

If HN ends up moving to the CS runtime I'd love to hear a high level summary of what work it required and how the new runtime performs.

the-smug-one 6y ago
You can run (what I suspect is an old version of) HN yourself: http://arclanguage.org/install http://arclanguage.org/install

deleted 6y ago

[deleted]

arc-in-space 6y ago

I'm glad Racket CS happened(even though I don't use Racket), because I was worried about the future of chezscheme's maintenance. It's a runtime with good portability(Guile Scheme, for instance, seems to pretend Windows doesn't exist), and I think it'd be a shame to see it fade away in the future.

deleted 6y ago
[deleted]
bjoli 6y ago
There is a branch being pushed to while we speak on the guile git to update the mingw support. I don't know what it means in practice, but maybe windows support for guile 3 is getting closer.

DC1350 6y ago

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?

patrec 6y ago
Carmack would have used it for Oculus, had management not said no. https://twitter.com/id_aa_carmack/status/807797812700348416 https://twitter.com/id_aa_carmack/status/807797812700348416
- Blikkentrekker 6y ago
  Javascript would have been a Scheme dialect, had it not been that NetScape's management said no.
soegaard 6y ago
The Racket distribution comes with several languages. You were probably using the socalled teaching languages, which are small subsets of real Racket. Using a subset of the real language allows better and more beginner friendly error messages. The real Racket language is a general purpose language with all the bells and whistles you could ever imagine.
- ashton314 6y ago
  Plus some bells and whistles that you can’t! It’s really impressive, and I’ve found Racket’s documentation to be excellent.
fantispug 6y ago
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.
- behnamoh 6y ago
  One could also argue that DSLs are not always good esp. in large projects maintained by many devs.
  - 6y ago

sitkack 6y ago

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 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 https://github.com/racket/ChezScheme

samth 6y ago
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 back to pure upstream Chez in the near future, but it's not quite a fork either. You can read more about some of these issues in our ICFP 2019 paper: https://www.cs.utah.edu/plt/rkt-on-chez/ https://www.cs.utah.edu/plt/rkt-on-chez/ which is co-authored with the Chez maintainers.
- sitkack 6y ago
  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?
  - samth 6y ago
    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.

gypsyharlot 6y ago

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

fredrikholm 6y ago
Racket if you're interested in a more "pure" lisp and/or metaprogramming/DSLs. Clojure if you're looking to use the language directly to solve your problems (and my preferred Lisp).
yw3410 6y ago
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.
- mepian 6y ago
  SBCL is an implementation of Common Lisp, to be precise. There is also CCL, or Clozure Common Lisp, which has the best support for macOS.
- jnxx 6y ago
  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.
- kazinator 6y ago
  If you learn Clojure, you will not jump into Lisp without too much trouble.
  - jnxx 6y ago

sachanganesh 6y ago

What is Racket primarily used for? I'm not sure where it fits in the language landscape in terms of strengths/weaknesses.

desine 6y ago
It's a Lisp, in the Scheme subset. It's original design was primarily around Programming Language Theory education - formerly it was PLT Scheme. Much of it was designed for educational uses, but it's a really well-rounded system with plenty of packages, a decent package management system, better performance than most interpreted languages. It comes with an IDE easier to pick up for newbies than Emacs (the usual Lisp/Scheme environment), but also runs fine as a command line REPL and compiler. It's kind of an oddball. While the development focus is mostly educational, specifically Programming Language theory, it's also very usable in the real world. There's a few tutorials on writing your own domain specific language in it. You can specify a language other than the default Racket, so one compiler/interpreter environment actually supports many Lisps and DSLs. I'm a long time dev who recently picked up SICP to learn why everyone says learning Lisp/Scheme will make you a better programmer, and Racket is by far the most interesting environment I've worked in. I haven't even touched Python, which was my money-maker, in months.
stretchcat 6y ago
To me, it's the language I use when I want to have fun.
- srcreigh 6y ago
  Same. I learn so much when I try to do something with it. You know what they say about emacs. "Emacs a great operating system, it's just lacking a decent text editor." Same with Racket. Racket is a great language development framework, the only thing missing is a decent language to write your program in. It does take a lot more effort and expertise to design a language and a program. That's why it's fun for me, I get to dream more and need to learn more. I'm inspired by the super interesting Racket papers [1] and PG's book "On Lisp". It helps that I got to use Racket to make a couple basic compilers in some uwaterloo classes too.. but I didn't even use macros for those projects, so I haven't really gotten started with Racket yet ;) [1]: https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf https://www2.ccs.neu.edu/racket/pubs/scheme2007-ctf.pdf

rcarmo 6y ago

This is nice to see. I’ve played around with Chez and Racket separately, and even though I’m now focusing on bare metal/JIT again, I look forward to using the new Racket.

ampdepolymerase 6y ago

Congrats on the release. What Racket really needs right now is a proper dependency manager with support for constraint solving and allowing multiple conflicting transitive dependencies. Cargo and yarn are the gold standard for this. A lot of Lisps tend to overly focus on language and compiler features and neglect the more boring tooling and infrastructure that makes a programming language successful.

samth 6y ago
You might be interested in https://docs.racket-lang.org/xiden-guide/index.html https://docs.racket-lang.org/xiden-guide/index.html (Sage also gave a talk at RacketCon 2020 about it).

pjmlp 6y ago

Love it, it is finally here! Congratulations to everyone involved into making this happen.

srcreigh 6y ago

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. How does eval work? Apparently Chez Scheme AOT compiles code at runtime. Comparatively a JIT will change the compilation at runtime based on codepaths. There's a thread about that here [2]. Part of the motivation of CS was to make it easier for people to contribute to the compiler. I'm excited to see how that plays out. Thanks again everybody. I'll go back to toying around with macros and tiny Racket programs now. [1]: https://www.figma.com/blog/rust-in-production-at-figma/ https://www.figma.com/blog/rust-in-production-at-figma/ [2]: https://news.ycombinator.com/item?id=16406391 https://news.ycombinator.com/item?id=16406391

samth 6y ago
eval works very similarly to how it worked before -- when you eval some code it compiled it and then runs it. Every* Scheme or Lisp system supports this kind of compilation-at-runtime, and Chez is no exception.
Zuider 6y ago
>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 https://bintray.com/opensmalltalk/vm/cog/202101210320#read
omaranto 6y ago
> 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!

Bost 6y ago

See also https://youtu.be/s3Q3M2wZ7rI https://youtu.be/s3Q3M2wZ7rI

sevensor 6y ago

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.

bjoli 6y ago
Anyone writing scheme/racket like python is in for a bad time. I think languages either tend towards mutability or immutability. In clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. In scheme, despite not being traditionally multithreaded as a standard, any computation can always be returned to several times due to call/cc. This means that even many cases of hidden otherwise "safe" mutability might lead to bad results. Which is why scheme tends towards immutability. That is the safe thing, culturally and also by design. Whereas the happy path for python is generally one of mutability, the happy path for scheme is not. Which is also something that I try to keep in mind when learning a new language. It is very tempting to try to write scheme in another language, but doing so in python will lead to sadness. I have seen so many people trying to learn scheme by trying to write python in scheme, which usually ends up being awkward, slow and buggy in addition to not working with call/cc or delimited continuations. I had an epiphany about this when trying to write scheme in rust. I took a step back and realized that I was the python programmer :)
- jnxx 6y ago
  > I think languages either tend towards mutability or immutability. In Clojure for example there is much emphasis on parallelism, which reflects itself in its choices of immutable data structures and atomic updates. Clojure with its focus on immutability and its purely functional data structures makes it much easier to write correct parallel and concurrent programs. However, there is a subtle point: One typically wants concurrency and parallelism for one of three objectives: 1. Concurrency in servers 2. Graphical user interfaces 3. exploiting multiple cores for complex parallel computations, like number crunching It turns out that Clojure is great for the first application, and that it works very nicely for the second one (once you bind a GUI written in, say, Swing, to Clojures promises and actors). However it is not that great for the third area of interest. The reason is performance. For example, sequences in Clojure are always lazy, and floating point numbers passed in function arguments are often boxed. Also, it is not possible to pass even small objects by value. These things put a lot of pressure on the garbage collector. And the result of that is that a single-threaded program which does things like massive number crunching written in Common Lisp will be faster than a parallel program written in Clojure. This is a drawback which is rooted by the implementation. But I still think that immutability in-the-large is the right way to go. Common Lisp libraries and Schemes are already adopting purely functional data structures, and I think this principle will become more important in the future and their possible offspring.

fhe 6y ago

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

shawnps 6y ago
When I was learning in university, How to Design Programs was the textbook: https://htdp.org/2020-8-1/Book/index.html https://htdp.org/2020-8-1/Book/index.html
- bhrgunatha 6y ago
  There are 2 edx courses based on the book too for those who prefer video instruction. [1] https://www.edx.org/course/how-to-code-simple-data https://www.edx.org/course/how-to-code-simple-data [2] https://www.edx.org/course/how-to-code-complex-data https://www.edx.org/course/how-to-code-complex-data
spdegabrielle 6y ago
Go here for guidance: https://docs.racket-lang.org/getting-started/index.html 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 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 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.

dogfishbar 6y ago

Life goal: outlive dynamic type checking.

rscho 6y ago
Welcome to Racket, then: https://www.google.com/url?sa=t&source=web&rct=j&url=https://www.ccs.neu.edu/home/stchang/pubs/ckg-popl2017.pdf&ved=2ahUKEwiwy8212LbuAhUP_KQKHc9PCLsQFjAAegQIARAB&usg=AOvVaw2dG6VNUS-pOHGw0ojEVXpJ https://www.google.com/url?sa=t&source=web&rct=j&url=https:/...
gus_massa 6y ago
The Racket distribution has many languages, so you can use Typed Racket instead https://docs.racket-lang.org/ts-guide/quick.html https://docs.racket-lang.org/ts-guide/quick.html

Decabytes 6y ago

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 acceptable performance. The Racket-on-Chez implementation is far more maintainable and flexible than the current Racket implementation, so maybe we’re half-way there after one year of work. The fact that the performance looks this good is a huge win. And the focus on maintainability over speed is a refreshing sight. This is the sort of practical solution that will allow Racket to be relevant for many years to come. Racket is a good all around Scheme, there are other schemes that do certain aspects of what Racket can do better, but as a whole Racket is a very complete package. I have two main criticisms with Racket, which are totally fixable, and in large part due to Racket's history as an incubator for language oriented programming, developed by PhDs in Comp Sci. Racket is very Academic. The documentation is great, but it is written by other Academics and can be hard to grok. Same with example code. Sure if you are looking at the student languages and tutorials based on that it is more accessible, but the minute you are trying to write a complex GUI app in typed Racket, the tutorials and example code is few and far between. Sometimes it makes me feel like I'm to dumb to be using the language, and I feel like I'm not the only one to get that feeling. Also for a language that prides itself on Language Oriented Programming, I want to some more examples/tutorials that are not just using brain fuck language. These are fixable, and I admit some are just me problems, but I'm actively working to solve them in this space.

deleted 6y ago
[deleted]