Hacker News new | past | comments | ask | show | jobs | submit login

Well PyonR is not a replacement for Racket. It's something totally a different project altogether. Rhombus is supposed to replace Racket. We could have PerlRacket or AwkRacket or RubyRacket and none of it should effect Racket, because you are using Racket as a language to build things, not exactly using RubyRacket as a replacement for Racket.

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. Lispers who happen to be core users of Racket have no use at the time for non-existent Rhombus, and its not Lispy so their whole use case ends here. Racket won't be continued to developed in the same breath as Rhombus, so Racket is also dead here. C based language devs have a lot of good stuff already, so they don't need Rhombus either.

Eventually this could lead to the exact situation Perl was in the 2000s. The core development was frozen for 5+ years. The language usability just fell year over year. Perl 6 took forever to even start with the implementations. Pugs, then Neitza, then Rakudo. Eventually they came to a point, where they announced Perl 5 development would just run parallel as a separate project compared to Perl 6. By then a lot of dev mind share was lost to Python/Java. Now neither Perl 5 nor Perl 6 have significant mind share. Perl 5 certainly has lost a lot of its users.

Also in general trying to be everything to everybody is a bad idea in general. Ask Parrot VM people. It doesn't work the way you expect. You won't solve anyone's specific problem, and it takes forever to get done.




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


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

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.


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


> 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/

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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: