3 ms·

> This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness wi

> This is how it rings to my ear. Racket as is, is in some way frozen when it comes to features and big changes. Rhombus is where the next set of awesomeness will happen. You still seem to be misunderstanding how Racket and #lang's work. Rhombus and Racket will be the same language, but with different parsers. Big features of Rhombus will be added by adding those features to Racket. Languages in Racket are not developed independently of each other, they all share the underlying language machinery.

kamaal 7y ago
>>Rhombus and Racket will be the same language Exactly the point, one will have to bring Rhombus to Racket's feature parity, which by the link I posted, and the Racket people themselves acknowledge will take several years to happen. That much dev resources have to be dedicated to build a new language which will have the same feature parity as Racket. This effort could be expended to taking Racket forward. This is non trivial effort. At the same time, you are hoping to attract users from Java/Python land(Who very likely won't come, given where your language will be(absence of killer libs, frameworks, books, q&a support etc)). While turning away existing lisp users. This ultimately becomes a disaster. One of the biggest selling points of Racket was that it was continuously being worked on, unlike CL whose spec is frozen(putting it mildly, the real word would be abandoned). Looks like Lisp has a lot of self destructive tendencies than anything else. Competition seems to be non existent. But Lisp communities just can't agree to work on things. A super massive pivot that just won't fix any real problems to existing users, adding very few incentives to new users, plus act as a resource drain, and cause your perfectly fine existing language to stagnate. https://news.ycombinator.com/item?id=20503742 https://news.ycombinator.com/item?id=20503742 A similar argument is made in the above thread. Regardless, of all this serious software also commits itself to things like stability and takes backwards compatibility seriously.
- gus_massa 7y ago
  It will take years (if it is even completed) but it doesn't mean that Racket will not be advancing meanwhile. Most of the discussion is in angry[1] comments in GitHub written while drinking coffee in the morning. In these 6 months, I guess the lost development time was only 1 or 2 weeks distributed in small chunks. If I can extrapolate linearly, the delay will be only 6 months (but some parts may take more time, for example rewriting the documentations). The idea is that the libraries written in Racket will be usable in Rhombus and that the libraries in Rhombus will be usable in Racket. Racket already ships with multiple internal languages, so one more is not a big difference. [2] Note that some constructions that are special cases that must be implemented by the language are just libraries in Racket. For example most of the implementation of `for` and `match` are in their own library, and even more weird things like at-expressions is just a library https://docs.racket-lang.org/scribble/reader-internals.html https://docs.racket-lang.org/scribble/reader-internals.html Some of them may need some tweaking to make them more idiomatic with the new syntax, but most of the implementation will be useful as is. [1] Most comments are nice, but let's add some drama to make the story more interesting. [2] Some languages have more impedance mismatch and need some macro magic to make sharing easy. In some languages sharing libraries is straightforward.
- lispm 7y ago
  > One of the biggest selling points of Racket was that it was continuously being worked on I was under the impression that SBCL has monthly releases and runs on a bunch of current platforms. It also has a AOT native code compiler for 20 years, which Racket is just switching to. http://www.sbcl.org/sbcl20/ http://www.sbcl.org/sbcl20/ My Linux/ARM64 board runs a current commercial Common Lisp, which is also available natively on a bunch of current platforms incl. iOS, Windows, macOS, Linux, FreeBSD, AIX, Solaris. x86, x64, ARM32, ARM64, SPARC, POWER, ... It has a portable native code AOT compiler since 30+ years.

kamaal 7y ago

>>Rhombus and Racket will be the same language Exactly the point, one will have to bring Rhombus to Racket's feature parity, which by the link I posted, and the Racket people themselves acknowledge will take several years to happen. That much dev resources have to be dedicated to build a new language which will have the same feature parity as Racket. This effort could be expended to taking Racket forward. This is non trivial effort. At the same time, you are hoping to attract users from Java/Python land(Who very likely won't come, given where your language will be(absence of killer libs, frameworks, books, q&a support etc)). While turning away existing lisp users. This ultimately becomes a disaster. One of the biggest selling points of Racket was that it was continuously being worked on, unlike CL whose spec is frozen(putting it mildly, the real word would be abandoned). Looks like Lisp has a lot of self destructive tendencies than anything else. Competition seems to be non existent. But Lisp communities just can't agree to work on things. A super massive pivot that just won't fix any real problems to existing users, adding very few incentives to new users, plus act as a resource drain, and cause your perfectly fine existing language to stagnate. https://news.ycombinator.com/item?id=20503742 https://news.ycombinator.com/item?id=20503742 A similar argument is made in the above thread. Regardless, of all this serious software also commits itself to things like stability and takes backwards compatibility seriously.

gus_massa 7y ago
It will take years (if it is even completed) but it doesn't mean that Racket will not be advancing meanwhile. Most of the discussion is in angry[1] comments in GitHub written while drinking coffee in the morning. In these 6 months, I guess the lost development time was only 1 or 2 weeks distributed in small chunks. If I can extrapolate linearly, the delay will be only 6 months (but some parts may take more time, for example rewriting the documentations). The idea is that the libraries written in Racket will be usable in Rhombus and that the libraries in Rhombus will be usable in Racket. Racket already ships with multiple internal languages, so one more is not a big difference. [2] Note that some constructions that are special cases that must be implemented by the language are just libraries in Racket. For example most of the implementation of `for` and `match` are in their own library, and even more weird things like at-expressions is just a library https://docs.racket-lang.org/scribble/reader-internals.html https://docs.racket-lang.org/scribble/reader-internals.html Some of them may need some tweaking to make them more idiomatic with the new syntax, but most of the implementation will be useful as is. [1] Most comments are nice, but let's add some drama to make the story more interesting. [2] Some languages have more impedance mismatch and need some macro magic to make sharing easy. In some languages sharing libraries is straightforward.
lispm 7y ago
> One of the biggest selling points of Racket was that it was continuously being worked on I was under the impression that SBCL has monthly releases and runs on a bunch of current platforms. It also has a AOT native code compiler for 20 years, which Racket is just switching to. http://www.sbcl.org/sbcl20/ http://www.sbcl.org/sbcl20/ My Linux/ARM64 board runs a current commercial Common Lisp, which is also available natively on a bunch of current platforms incl. iOS, Windows, macOS, Linux, FreeBSD, AIX, Solaris. x86, x64, ARM32, ARM64, SPARC, POWER, ... It has a portable native code AOT compiler since 30+ years.