33 ms·

Racket-on-Chez Status

137 points by ausimian 7y ago

kamaal 7y ago
Is there an update on what Racket decided to do with the proposal to deprecate the existing language syntax? Racket was a great tool to teach people lisp and initiate them into that paradigm. Is the main syntax still good for long term use?
- kryptiskt 7y ago
  They changed the name of the project from Racket 2 to Rhombus to make it clear that it was not about replacing Racket. And even in the original announcment it was stated " * `#lang racket` is not going away and will always have its current parenthesis-oriented syntax. In the same way that Racket still supports `#lang scheme` and `#lang mzscheme` and even `(module <name> mzscheme ....)` and even top-level programs, the Racket compiler and runtime system will always support `#lang racket` programs. We believe that Racket's `#lang`-based ecosystem makes it uniquely positioned for trying new language variants while preserving and building on our past investments." They have only made that statement stronger since then.
  - deleted 7y ago
    [deleted]
  - kamaal 7y ago
    So will the current Racket language continue to be developed, as in new features, bug fixes and regular releases after Rhombus is released? Renaming doesn't help the case much here, if Racket's future is abandonware.
    - kamaal 7y ago
      A bit of Googling landed me here: https://groups.google.com/forum/#!msg/racket-users/-x_M5wIhtWk/V47eL30HCgAJ https://groups.google.com/forum/#!msg/racket-users/-x_M5wIht... From there: Phase 1: Brainstorming (months) Phase 2: Iterative Design (years) Phase 3: Conversion (months or years) Phase 4: Transition (years) I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect Plus as a former Perl programmer having watched Perl 5 lost almost everything, chasing a never to have come to reality Perl 6. I can say, given all this, the future of Racket as a language, for its core uses and users is pretty much dead in the years to come. Like dead totally. Racket doesn't even have as much the share of dev mind share or a resource like CPAN at its disposal. Languages like Racket will fade away into oblivion a lot more quickly. It can be hard to see this in all the enthusiasm in the early stages of the project. But when you embark on multi year project journeys. People's priorities change, people get into health crises, lose jobs, move on to better projects, recessions happen. Core teams that started these projects change so much, newer one's pretty much give up and see no point in it after a while. Many people prefer a perfectly working tool improved over time, than a pie-in-the-sky idea that will never come to see the light of the day. While all this is happening, your existing language, libraries, dev mindshare, tooling suffers. Merely supporting small time fixes means nothing, because no one likes to use a tooling in hospice care. Your core dedicated set of users, who did most of the evangelism for your cause move on to newer tools and languages, for the obvious reasons that they don't see their future with existing tool they like, the newer one is taking for ever and isn't even the same goodness as the current one. Once you lose those users, the newer users you wish to attract from the crowd of Java and Python programmers won't even bother to try, why should they? They have something proven to work in production with tooling, libraries, books, and production success stories for decades. That is when you realize you lost both your old and new language. Racket was awesome for what it was. An awesome lisp, a top successor for Common Lisp and a playground for experiments and initiating people into Lisp. It's not late. Probably it's time to stop right now.
      - gonzus 7y ago
        I wish I could argue against your reasoning, but sadly I think you are totally correct. Here's to hoping we are both proven wrong.
      - kryptiskt 7y ago
        Racket (and PLT Scheme before it) has always been a bunch of languages, keeping a few different syntaxes and semantics around isn't anything new. I don't get why having another take on the surface syntax should cause all that much anxiety.
        kamaal 7y ago
        Because you are not exactly running Rhombus as a side toy language, but as a successor to Racket. This requires Rhombus to eventually replace Racket. Anything less than this and it makes Rhombus a non-successor to Racket. While at the same time much needed resources to make Racket win, will go to making Rhombus happen. Even if Rhombus comes along, it won't have any of the current Racket goodness to begin with. Rhombus will take years to just exist. Meanwhile precious resources for improving Racket to a better Racket over the years will be taken by Rhombus. Net result is a stagnated Racket, and a non-attractive Rhombus. Plus C based languages have their winners already. Racket is a kind of a winner in the Lisp family. With Clojure it makes the only other choice. Now if you change the syntax, you are going after users who don't really care what you have to offer, at the same time, you are taking away what your existing users like.
        manthideaal 7y ago
        It seems you learned from the decline of Perl, so you have the experience of a warrior. But Rhombus represents the hope of a better future for Racket, so another step in this fight should be to embrace the future and learn from the past, I don't know how.
        dTal 7y ago
        Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug fixed in Rhombus is a bug fixed in Racket, anywhere except the syntax parser. They will share all core libraries. The whole point of Racket is that #langs are mutually compatible. And the stress test of using Racket in earnest for what it is actually designed for will make Racket better, not worse. Consider PyonR [0]. This is a similar and yet much more ambitious goal than Rhombus - Python as a Racket #lang, with 100% compatibility with Racket and Python including external modules. And yet, it's a one-man project, written as a thesis and now pretty much abandoned. Writing Rhombus, a mere surface syntax for Racket, should be much easier. The hard part isn't writing it, it's deciding what it should be. The Racket team are the only ones that I can see who are taking all the "write your own DSL" Lisp hype and actually trying to apply it in a structured way. [0] https://github.com/pedropramos/PyonR https://github.com/pedropramos/PyonR
    - Decabytes 7y ago
      Racket’s whole schtick is that it allows for language oriented programming. Sure it’s a scheme and it has parenthesis, but a lot of languages in it’s toolkit do not. Not only that when you design a new language the reader converts your new language code into s-expressions and the expander gets it all the way to Racket code. Which is how Rhombus will more than likely work as well. So knowing #lang racket is still a requirement when creating a new language on top of the Racket VM
danieldk 7y ago
Question from someone who knows barely anything about the Scheme ecosystem: It seems that the one of the motivations for starting this effort, besides performance, was to move away from a C code base. Is Chez Scheme primarily written in Scheme?
- kryptiskt 7y ago
  Yes, Chez Scheme is mostly implemented in Scheme. The garbage collector and some support routines are in C, but the compiler and libraries and most other system stuff is written in Scheme.
- zelphirkalt 7y ago
  I think the reason is more maintainability, when basing on a solid and faster other Scheme. It's much easier to write in terms of that other Scheme's primitives, than writing a C core, avoiding all kinds of C typical bugs. Furthermore, many improvements in Chez Scheme will carry over to Racket and the 2 communities might join forces in improving Chez and thus Racket in effect. What that other Scheme is based on is a secondary consideration. Chez Scheme is also said to be implemented very well, however.
  - bjoli 7y ago
    Iirc Idris2 went straight to running on chez since Edwin was so impressed by chez scheme and it's runtime.
    - kryptiskt 7y ago
      I made a chez scheme backend for Idris a couple of years ago: https://github.com/melted/idris-chez https://github.com/melted/idris-chez About the only notable thing with it (apart from inspiring the target for Idris 2) is that it implements the C FFI, so it will handle Idris programs made to target C.
    - logicchains 7y ago
      The result is super fast: if you use if after using Idris1 you'll be blown away by how much quicker it type-checks. I'd never have thought a Scheme could perform noticeably faster than Haskell, but maybe most of the improvements are just due to algorithmic improvements made during the rewrite.
orsenthil 7y ago
Why is it called "Chez" scheme?
- uselpa 7y ago
  Because it’s now based on « Chez Scheme » (https://scheme.com https://scheme.com).
  - orsenthil 7y ago
    I meant, why was "that" scheme called "Chez" scheme?
    - pjmlp 7y ago
      All about it on "The development of Chez Scheme" paper, written on its twentieth anniversary. https://legacy.cs.indiana.edu/~dyb/pubs/hocs.pdf https://legacy.cs.indiana.edu/~dyb/pubs/hocs.pdf
      - catalogia 7y ago
        I don't see the name explained in that document. It does mention 'C-Scheme' and 'Z80 Scheme' so maybe Chez is a sort of interpolation of those?
        onemoresoop 7y ago
        In French chez means "at the home of (used in imitation of French, often humorously)." This always rings this bell in my mind when I hear this word. An example: Je suis allé chez Steele et Sussman roughly translates to: I went to the Steele's and the Sussman's homes
      - cat199 7y ago
        ^ this paper is mind-expanding to see the huge evolution and depth of effort around performance optimization over years for this system
  - 7y ago
xvilka 7y ago
Will it work on top of GNU Guile[1] as well? It became very fast since 3.0 version with the introduction of JIT[2]. [1] https://www.gnu.org/software/guile/ https://www.gnu.org/software/guile/ [2] https://www.gnu.org/software/guile/news/gnu-guile-300-released.html https://www.gnu.org/software/guile/news/gnu-guile-300-releas...
- gus_massa 7y ago
  It is difficult because there are a lot of minor details that has been added to Chez Scheme or to the patched version of Chez Scheme that is used by Racket. For example ephemerons, that need some magic to cooperate with the garbage collector. https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgmt:s26 https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgm...
jnxx 7y ago
What I wonder is whether the Chez base might massively improve Racket's concurrency capabilities. In Common Lisp, one has pthreads-like concurrency capabilities which seem very well suited for fine-grained parallelism as well as for server tasks. I am thinking in such things like parallel backtracking and optimization algorithms for robotic control or board games, for example. However, threads are notoriously difficult to handle cleanly and safely in larger programs. Here, Clojure (which in my eyes is a very Scheme-like Lisp) offers a very elegant solution with its concurrency primitives of Futures, Atoms, Agents, and STM. After some experimenting, I believe they are very, very attractive for many concurrent server tasks (like a web server), but not that well suited for computing-intensive parallel algorithms like the ones I mentioned above, which I am highly interested in. Part of the reasons are that such algorithms can become quite GC-heavy. Also, the Clojure compiler has limits on how much primitive types can be passed as parameters in one functions. This means that a complex backtracking algorithm in Clojure can still be two orders of magnitude slower than in C (which is somewhat disappointing, but one has to remember that Clojure was not designed for this). Racket has had, so far, only limited concurrency capabilities. It had Futures, however they could easily become blocked by GC. It also has Places, which are a very safe and clean solution of splitting parallel computations into separate processes. However, I think that places are not the first choice for heavily parallel algorithms with strong interdependencies. Now, Racket can run on top of Chez, and Chez has fine-grained concurrency capabilities on top of pthreads, which seem to be on par with Common Lisp. Also, Racket has strong support for functional and side-effect free programming, including some data structures. In my impression, this seems to open a wide range of new possibilities, including providing look-alike primitives for Clojure's Futures, Agents, and Atoms. I would be very interested to know more whether this impression is correct.

137 points by ausimian 7y ago

Is there an update on what Racket decided to do with the proposal to deprecate the existing language syntax? Racket was a great tool to teach people lisp and initiate them into that paradigm. Is the main syntax still good for long term use?

kryptiskt 7y ago
They changed the name of the project from Racket 2 to Rhombus to make it clear that it was not about replacing Racket. And even in the original announcment it was stated " * `#lang racket` is not going away and will always have its current parenthesis-oriented syntax. In the same way that Racket still supports `#lang scheme` and `#lang mzscheme` and even `(module <name> mzscheme ....)` and even top-level programs, the Racket compiler and runtime system will always support `#lang racket` programs. We believe that Racket's `#lang`-based ecosystem makes it uniquely positioned for trying new language variants while preserving and building on our past investments." They have only made that statement stronger since then.
- deleted 7y ago
  [deleted]
- kamaal 7y ago
  So will the current Racket language continue to be developed, as in new features, bug fixes and regular releases after Rhombus is released? Renaming doesn't help the case much here, if Racket's future is abandonware.
  - kamaal 7y ago
    A bit of Googling landed me here: https://groups.google.com/forum/#!msg/racket-users/-x_M5wIhtWk/V47eL30HCgAJ https://groups.google.com/forum/#!msg/racket-users/-x_M5wIht... From there: Phase 1: Brainstorming (months) Phase 2: Iterative Design (years) Phase 3: Conversion (months or years) Phase 4: Transition (years) I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition: https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect Plus as a former Perl programmer having watched Perl 5 lost almost everything, chasing a never to have come to reality Perl 6. I can say, given all this, the future of Racket as a language, for its core uses and users is pretty much dead in the years to come. Like dead totally. Racket doesn't even have as much the share of dev mind share or a resource like CPAN at its disposal. Languages like Racket will fade away into oblivion a lot more quickly. It can be hard to see this in all the enthusiasm in the early stages of the project. But when you embark on multi year project journeys. People's priorities change, people get into health crises, lose jobs, move on to better projects, recessions happen. Core teams that started these projects change so much, newer one's pretty much give up and see no point in it after a while. Many people prefer a perfectly working tool improved over time, than a pie-in-the-sky idea that will never come to see the light of the day. While all this is happening, your existing language, libraries, dev mindshare, tooling suffers. Merely supporting small time fixes means nothing, because no one likes to use a tooling in hospice care. Your core dedicated set of users, who did most of the evangelism for your cause move on to newer tools and languages, for the obvious reasons that they don't see their future with existing tool they like, the newer one is taking for ever and isn't even the same goodness as the current one. Once you lose those users, the newer users you wish to attract from the crowd of Java and Python programmers won't even bother to try, why should they? They have something proven to work in production with tooling, libraries, books, and production success stories for decades. That is when you realize you lost both your old and new language. Racket was awesome for what it was. An awesome lisp, a top successor for Common Lisp and a playground for experiments and initiating people into Lisp. It's not late. Probably it's time to stop right now.
    - gonzus 7y ago
      I wish I could argue against your reasoning, but sadly I think you are totally correct. Here's to hoping we are both proven wrong.
    - kryptiskt 7y ago
      Racket (and PLT Scheme before it) has always been a bunch of languages, keeping a few different syntaxes and semantics around isn't anything new. I don't get why having another take on the surface syntax should cause all that much anxiety.
      - kamaal 7y ago
        Because you are not exactly running Rhombus as a side toy language, but as a successor to Racket. This requires Rhombus to eventually replace Racket. Anything less than this and it makes Rhombus a non-successor to Racket. While at the same time much needed resources to make Racket win, will go to making Rhombus happen. Even if Rhombus comes along, it won't have any of the current Racket goodness to begin with. Rhombus will take years to just exist. Meanwhile precious resources for improving Racket to a better Racket over the years will be taken by Rhombus. Net result is a stagnated Racket, and a non-attractive Rhombus. Plus C based languages have their winners already. Racket is a kind of a winner in the Lisp family. With Clojure it makes the only other choice. Now if you change the syntax, you are going after users who don't really care what you have to offer, at the same time, you are taking away what your existing users like.
        manthideaal 7y ago
        It seems you learned from the decline of Perl, so you have the experience of a warrior. But Rhombus represents the hope of a better future for Racket, so another step in this fight should be to embrace the future and learn from the past, I don't know how.
        dTal 7y ago
        Racket is not like other languages. Racket is a language with first class support for building languages on top of it. And so no, Rhombus does not need to be a "successor" to Racket. It does not need to "replace" Racket. It will have all the current Racket goodness to begin with, because all of its semantics will come from Racket - they will be the same language. Nor will it steal valuable developer attention - a bug fixed in Rhombus is a bug fixed in Racket, anywhere except the syntax parser. They will share all core libraries. The whole point of Racket is that #langs are mutually compatible. And the stress test of using Racket in earnest for what it is actually designed for will make Racket better, not worse. Consider PyonR [0]. This is a similar and yet much more ambitious goal than Rhombus - Python as a Racket #lang, with 100% compatibility with Racket and Python including external modules. And yet, it's a one-man project, written as a thesis and now pretty much abandoned. Writing Rhombus, a mere surface syntax for Racket, should be much easier. The hard part isn't writing it, it's deciding what it should be. The Racket team are the only ones that I can see who are taking all the "write your own DSL" Lisp hype and actually trying to apply it in a structured way. [0] https://github.com/pedropramos/PyonR https://github.com/pedropramos/PyonR
  - Decabytes 7y ago
    Racket’s whole schtick is that it allows for language oriented programming. Sure it’s a scheme and it has parenthesis, but a lot of languages in it’s toolkit do not. Not only that when you design a new language the reader converts your new language code into s-expressions and the expander gets it all the way to Racket code. Which is how Rhombus will more than likely work as well. So knowing #lang racket is still a requirement when creating a new language on top of the Racket VM

danieldk 7y ago

Question from someone who knows barely anything about the Scheme ecosystem: It seems that the one of the motivations for starting this effort, besides performance, was to move away from a C code base. Is Chez Scheme primarily written in Scheme?

kryptiskt 7y ago
Yes, Chez Scheme is mostly implemented in Scheme. The garbage collector and some support routines are in C, but the compiler and libraries and most other system stuff is written in Scheme.
zelphirkalt 7y ago
I think the reason is more maintainability, when basing on a solid and faster other Scheme. It's much easier to write in terms of that other Scheme's primitives, than writing a C core, avoiding all kinds of C typical bugs. Furthermore, many improvements in Chez Scheme will carry over to Racket and the 2 communities might join forces in improving Chez and thus Racket in effect. What that other Scheme is based on is a secondary consideration. Chez Scheme is also said to be implemented very well, however.
- bjoli 7y ago
  Iirc Idris2 went straight to running on chez since Edwin was so impressed by chez scheme and it's runtime.
  - kryptiskt 7y ago
    I made a chez scheme backend for Idris a couple of years ago: https://github.com/melted/idris-chez https://github.com/melted/idris-chez About the only notable thing with it (apart from inspiring the target for Idris 2) is that it implements the C FFI, so it will handle Idris programs made to target C.
  - logicchains 7y ago
    The result is super fast: if you use if after using Idris1 you'll be blown away by how much quicker it type-checks. I'd never have thought a Scheme could perform noticeably faster than Haskell, but maybe most of the improvements are just due to algorithmic improvements made during the rewrite.

orsenthil 7y ago

Why is it called "Chez" scheme?

uselpa 7y ago
Because it’s now based on « Chez Scheme » (https://scheme.com https://scheme.com).
- orsenthil 7y ago
  I meant, why was "that" scheme called "Chez" scheme?
  - pjmlp 7y ago
    All about it on "The development of Chez Scheme" paper, written on its twentieth anniversary. https://legacy.cs.indiana.edu/~dyb/pubs/hocs.pdf https://legacy.cs.indiana.edu/~dyb/pubs/hocs.pdf
    - catalogia 7y ago
      I don't see the name explained in that document. It does mention 'C-Scheme' and 'Z80 Scheme' so maybe Chez is a sort of interpolation of those?
      - onemoresoop 7y ago
        In French chez means "at the home of (used in imitation of French, often humorously)." This always rings this bell in my mind when I hear this word. An example: Je suis allé chez Steele et Sussman roughly translates to: I went to the Steele's and the Sussman's homes
    - cat199 7y ago
      ^ this paper is mind-expanding to see the huge evolution and depth of effort around performance optimization over years for this system
- 7y ago

xvilka 7y ago

Will it work on top of GNU Guile[1] as well? It became very fast since 3.0 version with the introduction of JIT[2]. [1] https://www.gnu.org/software/guile/ https://www.gnu.org/software/guile/ [2] https://www.gnu.org/software/guile/news/gnu-guile-300-released.html https://www.gnu.org/software/guile/news/gnu-guile-300-releas...

gus_massa 7y ago
It is difficult because there are a lot of minor details that has been added to Chez Scheme or to the patched version of Chez Scheme that is used by Racket. For example ephemerons, that need some magic to cooperate with the garbage collector. https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgmt:s26 https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgm...

jnxx 7y ago

What I wonder is whether the Chez base might massively improve Racket's concurrency capabilities. In Common Lisp, one has pthreads-like concurrency capabilities which seem very well suited for fine-grained parallelism as well as for server tasks. I am thinking in such things like parallel backtracking and optimization algorithms for robotic control or board games, for example. However, threads are notoriously difficult to handle cleanly and safely in larger programs. Here, Clojure (which in my eyes is a very Scheme-like Lisp) offers a very elegant solution with its concurrency primitives of Futures, Atoms, Agents, and STM. After some experimenting, I believe they are very, very attractive for many concurrent server tasks (like a web server), but not that well suited for computing-intensive parallel algorithms like the ones I mentioned above, which I am highly interested in. Part of the reasons are that such algorithms can become quite GC-heavy. Also, the Clojure compiler has limits on how much primitive types can be passed as parameters in one functions. This means that a complex backtracking algorithm in Clojure can still be two orders of magnitude slower than in C (which is somewhat disappointing, but one has to remember that Clojure was not designed for this). Racket has had, so far, only limited concurrency capabilities. It had Futures, however they could easily become blocked by GC. It also has Places, which are a very safe and clean solution of splitting parallel computations into separate processes. However, I think that places are not the first choice for heavily parallel algorithms with strong interdependencies. Now, Racket can run on top of Chez, and Chez has fine-grained concurrency capabilities on top of pthreads, which seem to be on par with Common Lisp. Also, Racket has strong support for functional and side-effect free programming, including some data structures. In my impression, this seems to open a wide range of new possibilities, including providing look-alike primitives for Clojure's Futures, Agents, and Atoms. I would be very interested to know more whether this impression is correct.