5 ms·

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

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

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