I really don't think any one starting a project for production environment will be happy with being told that existing programs would run, but expect no fixes or enhancements from now on.
See how Perl lost programmer mindshare in the 2000s because of Perl 5 development had stalled in the favor of Perl 6.
Racket is(was) a language to do home work assignments. I guess even their very dedicated users would either switch to scheme or will just move to Clojure, with the current situation now.
> but expect no fixes or enhancements from now on.
This is a common misunderstanding around the Racket 2 proposal. Racket is completely different from Python and Perl when it comes to syntax. Racket already supports multiple syntaxes over the same semantics, and is designed for people to be able to build new syntaxes themselves.
IOW, Racket 1 (more precisely: `#lang racket`) and Racket 2 will not be different runtimes, only different ways of writing what is to run. You cannot run Python 2 and Python 3 in the same process, or import a Python 2 module in Python 3 file; similarly with Perl 5 and 6. But a `#lang racket` (less precisely: Racket 1) module can be imported and run in the same runtime and context as a `#lang racket2` (less precisely: Racket 2) module.
I get what you are saying, but in that case they should just call it Honu, instead of calling it Racket 2. Call things by what they mean, rather than using a well marketed name to promote a new language. When you say Racket 2, people will almost always take it as a the next Racket version.
If I implement Python in Racket, I will call it Python, not Racket 3. Python is Python, Racket is Racket.
By the way, Perl 6 is supposed to have a compatibility mode with Perl 5 too.
All these things look fine in theory, but in practice, no one bets their production code on things like these.
The name "Racket 2" is just a code name.
A name used to signal that we are talking a possible new direction (and not an immediate change to the existing racket).
Wrt to supporting new versions of a language Racket has an excellent track record. The language mzscheme (used before racket) is still supported - and is implemented using the language machinery present in Racket.
I don't think I put it very well the first time, so let me try again.
Racket, the platform, is very unlike common programming languages like Python, Ruby, Perl, JS, etc. And I don't mean the fact that it's a Scheme/Lisp. I mean the Language Oriented Programming [1] features it's built for.
It is a platform for designing and building languages. It's only sensible that it should be able to run all the different languages in the same program. In fact, one can create an arbitrary new language and use that new language all within the same running process. In fact, as you can see from the link I cite in [1], the languages can all look and behave completely differently, and yet all be valid "Racket": put them in a .rkt file and load it up and see.
I can now sort of understand your view. I am not a Racket contributor, though I do use it every now and then, and to me "building a new language in Racket" now means something completely different than what it'd have meant before I became familiar with Racket (the platform).
I think the difference stems from the fact that what Racket calls a "language" (`#lang`, in Racket terms), is actually just a syntax. In languages like Python/Perl/JS, the syntax and the semantics are so closely intertwined they might as well be the same thing, and we call this "single" thing "the language". But neither of those syntaxes are as extensible/user-modifiable as in a lisp, and none of those semantics are available for use with different syntaxes as in Racket.
A "language" in Racket does not change the core semantics of Racket-the-platform, only the syntax available to the programmer in that one file/module, and how that syntax gets translated into core Racket semantics. In this way, `#lang pollen` and `#lang bf` are not any special "compatibility modes" of Racket. In fact, right now, there exist multiple "Racket"s within Racket: there's `#lang racket/base` and `#lang racket` and then there's the type-checking variant `#lang typed/racket`. Neither is a special mode of another, or of the runtime; all are just different syntaxes of the same runtime.
I reckon Racket 2 will similarly be just a different syntax. Or, as we like to call those in Racket terms: a `#lang`-uage.
See how Perl lost programmer mindshare in the 2000s because of Perl 5 development had stalled in the favor of Perl 6.
Racket is(was) a language to do home work assignments. I guess even their very dedicated users would either switch to scheme or will just move to Clojure, with the current situation now.