Make clear that `#lang racket` doesn't change about rhombus-prototype HOT 6 OPEN

I think there are still bug fixes for #lang scheme and #lang mzscheme, but I can't remember one just now.

A lot of new development is in libraries that can be used in racket and in the old languages.

from rhombus-prototype.

Is this just stating that we'll move from #lang racket to (#lang racket #lang racket2) or (#lang racket #lang rhombus), but not to (#lang old-racket #lang racket), or something more?

When I asked about being able to continue to program in #lang racket, the response was something along the lines of, "sure, just like you can program in #lang scheme or #lang mzscheme now, but my impression is those latter two languages aren't moving forward i.e. a dead end.

So, it might be nice to elaborate on the details of what it means to continue to support #lang racket - e.g. "possible" vs. "desirable"

from rhombus-prototype.

@mflatt has made this pretty clear in his email to Racket-users:

Subject: Racket2 and syntax
Date: Jul 15, 2019
From: Matthew Flatt

tl;dr DON'T PANIC

[...]

• #lang racket is not going away and will always have its current parenthesis-oriented syntax.

HTH
Stephen

from rhombus-prototype.

@spdegabrielle isn't that statement, "is not going away and will always have its current parenthesis-oriented syntax" also true of #lang scheme, #lang mzscheme, etc. ? In other words, that statement alone is insufficient to inspire confidence that I made the right choice (8 months ago) to base my future codebase on Racket.

It's possible I'm ignorant of #lang scheme and #lang mzscheme - are they being actively developed with additional features, bug fixes, etc. ?

As a specific example, I believe it was mentioned that all of the documentation would be switched over to the new infix syntax. If so, it might make day-to-day development in #lang racket more difficult.

Does that help to understand what might be on the minds of full time Racket programmers? If not, let me know, and I'll try to clarify further.

from rhombus-prototype.

I think that @gus-massa is correct. Those #langs are not being developed, in the sense that they are fixed things, but so is #lang racket. I can't recall the last time we added a library to the default set of things included in #lang racket, we try to never do that, because it would be backwards-incompatible.

At a runtime-level, all of these #langs are compatible. You can call a new web-server/dispatch function from #lang algol60 or #lang r5rs. In the future, we anticipate that all #lang racket2 code will be able to call and will be callable from #lang racket. This INCLUDES macros.

from rhombus-prototype.

Thanks Jay. I think it's becoming clearer to me now :) I've phrased my question in a few different ways and received answers with various nuances from different people. Sometimes academic/research folks have a different perspective than simple, application developers such as myself.

In a sense, I've made a big bet by basing all my future development on Racket, and although I'm only 8 months into this decision, it came after years of research, and it would be quite painful to switch languages. I feel more encouraged by recent communications i.e. I don't think I made a big mistake :) In fact, I prefer the type of language interoperability Racket provides over a mainstream VM such as the JVM or Erlang BEAM.

In a worst case scenario (only worst case from my pro-paren aesthetic), I'd be fine if support for #lang racket just included bug fixes and runtime improvements, and I expect the latter is a given from what you've described of the architecture. I agree with Matthew that #lang racket may have reached some sort of local maximum, so if the core team wants to explore all sorts of new possibilities, that's fine with me, as long as I can continue to be productive in #lang racket !

Who knows, maybe a whiz bang web framework will draw enough people over who then get into language oriented programming. Rails certainly did wonders for Ruby!

from rhombus-prototype.