Hacker News Reader

Comment by kryptiskt | Hacker News Reader

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.

View on HN

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.

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

A bit of Googling landed me here: 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

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.

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.

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.

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

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.

Would you say Rhombus is to Racket as ReasonML (https://reasonml.github.io/) is to OCaml?

I think it's a reasonable analogy, but I would say ReasonML is actually more than Rhombus in a sense. Rhombus doesn't require any external tooling, because Racket has support for implementing #lang's built in to it.

Woah this is really cool. I’ve had a similar idea but I’m not smart enough to implement it myself. Seems it is really challenging even with all the tools Racket gives you

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.

> chasing a never to have come to reality Perl 6

Recently, Perl 6 has indeed become a lot less real, as it has been renamed to Raku (https://raku.org using the #rakulang tag on social media). But it is still very much a real thing (with regular releases since December 2015). And it actually has its own IDE: https://commaide.com .

> I am a nobody in front of people like Matthew Flatt, but this feels like Seconds Systems Effect taken to its extreme definition:

I think you are mistaking working time for bloat; they can be inversely related; it's easier to add lots of ideas, it's harder to pare things down.

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

This isn't Perl 6.

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

Pretty much everyone does, but Racket remains the former. Neither the schedule nor the ambition of new Racket development has been scaled back for Rhombus. It's not even clear that they would once Rhombus was generally available and hosting Racket, though there would also be a place for improvements that didn't fit in Racket.

> This isn't Perl 6.

Indeed. And even Perl 6 is not Perl 6 anymore: it has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

> a top successor for Common Lisp

I know that some well-known Lisp hackers left for Racket, but I've never been clear on how it is really a successor. It does have a great community and ecosystem, but it inherits a ton of the mistakes of Scheme, is unspecified and as such is susceptible to derailments like Rhombus. I think that performance is not that great either, which isn't necessarily a huge deal for many problems but is for some.

What I am genuinely curious about is: from your point of view, what makes Racket a preferable successor to Lisp (which can't easily be grafted into a Lisp environment)? The two things which leap to my mind are the sane read case and the community mindset.

I also think that language oriented programming like in Racket is overrated. As a Lisp programmer I'm happy to have different paradigms integrated into one language, and not have them added as 'languages'. For some amount of languages it makes sense, but generally it's more like an academic exercise and makes the whole machinery more complicated - which for many use cases is not needed. Working on a hosted platform with deep integration into the host language environment was during the last years preferred by a lot more users - that's more compatible and reusable (since more reusable libraries work).

> An awesome lisp, a top successor for Common Lisp and a playground for experiments and initiating people into Lisp.

As good as its development environment might be for learning purposes and research, it is no match for neither LispWorks nor Allegro Common Lisp, so it is hard to be a top successor.

In fact there isn't a single commercial Scheme has successful in the market as those Lisp environments, with exception of ChezScheme, used commercially by Cisco.

Not to be rude, but apart from Clojure, other Lisps are non-existent in production compared to the software world at large.

One could even consider Scheme as more widely used than CL.

The biggest production use case for Lisp today is to learn Lisp.

The biggest use case for Scheme, CL, or Racket is to use to learn Lisp. Racket that way was quite successful.

With all this going on now. Scheme is the only serious Lisp for learning purposes. What new in sights will Rhombus provide here? The biggest use case for trying out scheme was while working through books like SICP.

> Clojure, other Lisps are non-existent in production compared to the software world at large

Clojure is also non-existent in production to the software world at large.

The latest Clojure survey had roughly 2500 people giving feedback. That's a drop in the ocean of many millions of Java, C, C++, C#, Python and Javascript programmers. Rough estimates say that there are >7 million Java programmers world-wide.

https://www.zdnet.com/article/programming-languages-python-d...

The number of Clojure programmers is probably less than 1/1000ths of that.

Except that they are, looking for a job in Porto/Lisbon? Syscog is always looking for good Common Lisp coders.

The fact that CL is used enough to keep two commercial vendors in business, shows how relevant it still is across some industries, even if doesn't do newspaper headlines.

More so than ever Scheme ever was.

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.

really, if they are concerned about the 'teaching' aspect and parens being less new user friendly, why not just do a LUA-on-racket, maybe with some small extensions for the 'teaching' language - LUA maps to scheme pretty well, and its already 'done'.

Because the teaching isn’t just about the syntax. It’s the concepts. How to Design Programs, does exactly what your says, and it also teaches test driven development. A guide to Racket with pictures allows you to leverage DrRacket’s ability to display graphics inline to become familiar with programming in a more visual way, Making a language in an hour shows you how languages are parsed, and how Racket makes it easier to design your own. All of these things introduce you to concepts and ideas that are useful even if you forget everything about Racket the Language later on.

Reply on news.ycombinator.com