Future of Racket(greghendershott.com)
greghendershott.com
Future of Racket
https://www.greghendershott.com/2019/07/future-of-racket.html
39 comments
The mailing list traffic on this topic took the wind out of my sails for wanting to spend my tinker time in Racket. On the one hand, it’s probably overreacting for me to throw in the towel on Racket at just the suggestion of this change. On the other hand, part of what makes me interested in writing Racket for projects where I have broad latitude is the sense that I’m both using an exciting technology, and a technology with a history of relative stability.
By signaling a switch to some bland surface syntax I feel that it’s eroding the exciting part as well as the stability benefits of the language. For data science (the domain I’m most invested in) Julia has attracted a decent mindshare, is lispy (even if not as much as I want), and is fast. Racket with a bland syntax is likely to be about as lispy as Julia, much slower, and have fewer of the data science libraries I care about.
I only have so many hours in my life to dedicate to not-making-money programming endeavors. I was sort of hoping that Racket would be the vehicle for those hours. But right now, I’m worried that Racket is Perl 6-ing itself, and that’s a hard place to spend hours. Especially with people like Greg leaving the community.
A while back there was a thread about a prominent member of the Common Lisp community saying that he’d probably eventually leave CL for Racket. But then later he signaled that he’d settled on Gerbil Scheme. Maybe that’s the right life raft from Racket.
By signaling a switch to some bland surface syntax I feel that it’s eroding the exciting part as well as the stability benefits of the language. For data science (the domain I’m most invested in) Julia has attracted a decent mindshare, is lispy (even if not as much as I want), and is fast. Racket with a bland syntax is likely to be about as lispy as Julia, much slower, and have fewer of the data science libraries I care about.
I only have so many hours in my life to dedicate to not-making-money programming endeavors. I was sort of hoping that Racket would be the vehicle for those hours. But right now, I’m worried that Racket is Perl 6-ing itself, and that’s a hard place to spend hours. Especially with people like Greg leaving the community.
A while back there was a thread about a prominent member of the Common Lisp community saying that he’d probably eventually leave CL for Racket. But then later he signaled that he’d settled on Gerbil Scheme. Maybe that’s the right life raft from Racket.
Please don't be turned off by the recent commotion. (I'm sorry some of the commotion that might've discouraged you was by me.) Commotion happens because people care about Racket, and there are reasons they care.
Racket actually has a couple-decade history of very good stability, other than a couple oopses that might've helped prompt the current attempt at greater community involvement in decisions.
The history is too long to summarize here, but some quick evidence you can look at is, when the language evolution really wants to change an interface or how something works, the old way either still remains in the main language/library, or is preserved in a legacy language or module, which you can see at the bottom of the page: https://docs.racket-lang.org/
For further evidence that's fairly easy to find, you can also look at the very careful and conservative process for introducing the new Chez-based backend.
Racket actually has a couple-decade history of very good stability, other than a couple oopses that might've helped prompt the current attempt at greater community involvement in decisions.
The history is too long to summarize here, but some quick evidence you can look at is, when the language evolution really wants to change an interface or how something works, the old way either still remains in the main language/library, or is preserved in a legacy language or module, which you can see at the bottom of the page: https://docs.racket-lang.org/
For further evidence that's fairly easy to find, you can also look at the very careful and conservative process for introducing the new Chez-based backend.
No, to be clear, the commotion that has me concerned about Racket’s future is the substance of the proposal that was signaled on the list, not any sort of flamewar fatigue. One of the nice things about the Racket community is how thoughtful and earnest people are. I also tend to view your commentary as reasoned and agreeable, so no apologies needed!
To me, I’m just not that excited about the “maybe direction.” I guess I’m one of the parentheses clutchers who loves parediting in emacs. I’m sure the transition toward some other syntax will be cautious and careful, and that the resulting preferred #lang will be a fine one.
It just sounds like the center of mass for the Racket community won’t be quite what I was looking for when I came to Racket. I’ve got plenty of experience in at least one language, R, that started as a Scheme and then syntaxed itself to something less than Scheme (the language I mean, not the libraries—I'd kill for a #lang racket with R’s libraries).
Maybe Racket2 will be the bland syntax that succeeds in not obscuring the Music of the Spheres. If anyone can do it, this community will. On the other hand, I’ve got a healthy skepticism, uninformed by any deep understanding of the issues. I’m not sure what the benefits of sticking it out to see are.
The proposed change has anti-network effects in that Greg is already signaled his departure, and I’d already stopped reaching for Racket as the answer to “what lisp should I learn?” I simply don’t have a good answer to that question where I felt like I did a month or so ago.
But I’d be disappointed if Racket changed direction based on opinions of people like me. It’s not like I have any grand contributions to the community that are going away! I’m a dilettante who writes a little bit of Racket to scratch a personal itch once in a while. My primary takeaway from my one in-person RacketCon (Seattle) was, “woah, I don’t understand anything but these people are smaaaart.” I am not the right person to cater a language to.
To me, I’m just not that excited about the “maybe direction.” I guess I’m one of the parentheses clutchers who loves parediting in emacs. I’m sure the transition toward some other syntax will be cautious and careful, and that the resulting preferred #lang will be a fine one.
It just sounds like the center of mass for the Racket community won’t be quite what I was looking for when I came to Racket. I’ve got plenty of experience in at least one language, R, that started as a Scheme and then syntaxed itself to something less than Scheme (the language I mean, not the libraries—I'd kill for a #lang racket with R’s libraries).
Maybe Racket2 will be the bland syntax that succeeds in not obscuring the Music of the Spheres. If anyone can do it, this community will. On the other hand, I’ve got a healthy skepticism, uninformed by any deep understanding of the issues. I’m not sure what the benefits of sticking it out to see are.
The proposed change has anti-network effects in that Greg is already signaled his departure, and I’d already stopped reaching for Racket as the answer to “what lisp should I learn?” I simply don’t have a good answer to that question where I felt like I did a month or so ago.
But I’d be disappointed if Racket changed direction based on opinions of people like me. It’s not like I have any grand contributions to the community that are going away! I’m a dilettante who writes a little bit of Racket to scratch a personal itch once in a while. My primary takeaway from my one in-person RacketCon (Seattle) was, “woah, I don’t understand anything but these people are smaaaart.” I am not the right person to cater a language to.
Thank you for your thoughtful comments. The Racket commmunity has a lot of people using it on the side, like you do, and your interests and contributions matter. I've been in that category myself lately.
If you were drawn to Racket, but want to look around a bit, there are a few other Schemes I find especially interesting, including: Guile, Chicken, Gambit, and Scheme48. Guile is in pre-release of some nice new JIT work, including instant startup from native code caches, and has an active community. If the bulk of your code can be written in RnRS, and you avoid mutating lists, you should be able to move around between the various Schemes and Racket reasonably easily. Of course, there's also CL and Clojure, but those are pretty different.
I didn't know that R had some Scheme ancestry. (For one client, I made an interface to call R from Racket, for a data science system.) I think one of the things Racket was heading towards, around the time of the math modules work, was for Racket to become a newer R. And perhaps have a `#lang r`, as another way of bringing in some of the wealth of R libraries and programmers (and also a similar situation with Fortran). I'm pretty sure we couldn't get Fortran performance with anything other than a native Fortran compiler, and I don't know the state of R performance, but Racket could've had closer to one of the main selling points of Python today (i.e., a wealth of data science libraries are available easily through it).
If you were drawn to Racket, but want to look around a bit, there are a few other Schemes I find especially interesting, including: Guile, Chicken, Gambit, and Scheme48. Guile is in pre-release of some nice new JIT work, including instant startup from native code caches, and has an active community. If the bulk of your code can be written in RnRS, and you avoid mutating lists, you should be able to move around between the various Schemes and Racket reasonably easily. Of course, there's also CL and Clojure, but those are pretty different.
I didn't know that R had some Scheme ancestry. (For one client, I made an interface to call R from Racket, for a data science system.) I think one of the things Racket was heading towards, around the time of the math modules work, was for Racket to become a newer R. And perhaps have a `#lang r`, as another way of bringing in some of the wealth of R libraries and programmers (and also a similar situation with Fortran). I'm pretty sure we couldn't get Fortran performance with anything other than a native Fortran compiler, and I don't know the state of R performance, but Racket could've had closer to one of the main selling points of Python today (i.e., a wealth of data science libraries are available easily through it).
The legacy libraries and languages are maintained but not promoted. For example...
"Do not use #lang scheme to start new projects; #lang racket is the preferred language."
If #lang racket could go the way of #lang scheme, then it is harder for me to justify investing my time in #lang racket now.
"Do not use #lang scheme to start new projects; #lang racket is the preferred language."
If #lang racket could go the way of #lang scheme, then it is harder for me to justify investing my time in #lang racket now.
I no longer think that `#lang racket` will be allowed to become a second-class citizen.
The reason is: I think it's become glaringly obvious, to everyone, that a large percentage of Racketeers (including some of the educators) have no interest in any non-sexp language. If it were forced, the community would fork, in some way.
Matthew Flatt, for example, is a really first-rate developer, and of goodwill, and has some understanding of this.
I speculate it could take a month before any new discussion. People on academic calendars might be getting in a little vacation after the summer conference schedule, and then ramping up the new school year in a few weeks.
The reason is: I think it's become glaringly obvious, to everyone, that a large percentage of Racketeers (including some of the educators) have no interest in any non-sexp language. If it were forced, the community would fork, in some way.
Matthew Flatt, for example, is a really first-rate developer, and of goodwill, and has some understanding of this.
I speculate it could take a month before any new discussion. People on academic calendars might be getting in a little vacation after the summer conference schedule, and then ramping up the new school year in a few weeks.
Any sort of politics would ruin the fun for me. I don't know how you OSS people do it while maintaining sanity. Those types of arrangements always attract some bad actors (intentional or not).
There needs to be a strong limited vision for any project and a conservative approach to not try to fix what's not broken.
Getting rid of s expressions without it being part of a more cohesive improvement (like better supporting a new type system or something) just for mainstream appeal seems like an odd choice to me.
There needs to be a strong limited vision for any project and a conservative approach to not try to fix what's not broken.
Getting rid of s expressions without it being part of a more cohesive improvement (like better supporting a new type system or something) just for mainstream appeal seems like an odd choice to me.
I'm familiar with a lot of other open source projects and people, and I can guess what you mean about the occasional unintentional or intentional bad actor. FWIW, IMHO, there are no bad actors (as I see it) in Racket.
What I think just happened is a little growing pains, when a few new things happened all at once, and everyone (including in core) was caught off-guard by at least one surprise. I think it all arguably reduces to areas of communication to improve.
I absolutely agree about the strong vision, and I think that such a vision probably mostly exists, in core, but that it's not yet been made really-super-clear to everyone else, nor has there then been a chance for everyone else to comment on and influence an unambiguous draft vision. Until everyone comes to shared understanding and agreement on the top-level requirements, I think an RFC process on features and tactics seems not only premature, but also perpetuates misconceptions/misalignments.
What I think just happened is a little growing pains, when a few new things happened all at once, and everyone (including in core) was caught off-guard by at least one surprise. I think it all arguably reduces to areas of communication to improve.
I absolutely agree about the strong vision, and I think that such a vision probably mostly exists, in core, but that it's not yet been made really-super-clear to everyone else, nor has there then been a chance for everyone else to comment on and influence an unambiguous draft vision. Until everyone comes to shared understanding and agreement on the top-level requirements, I think an RFC process on features and tactics seems not only premature, but also perpetuates misconceptions/misalignments.
For pedagogical potential Python and Julia also competes against Racket due to connection to the data science ecosystem.
Well, this is in the end a very subjective thing but I'm with Greg on this one. A syntax without s-expressions is not an innovative feature. For me, it's not even desirable, not at all. When I'm using non-Lispy languages like Rust, Ada, Nim, and currently a lot of Go, that's despite their annoying syntactic idiosyncrasies. All of those quirky little curly braces and special symbols to save few keystrokes. I'd much prefer if all of these languages used s-expressions. That syntax is so simple that it makes you focus on the semantics.
It's a pity, because he has a few interesting projects like:
* Rackjure: "Provide a few Clojure-inspired ideas in Racket. Where Racket and Clojure conflict, prefer Racket." https://github.com/greghendershott/rackjure I don't use it, but I think it's a nice idea, and it show how Racket can be used for multiple programming "frontends".
* Travis-Racket "https://github.com/greghendershott/travis-racket*" https://github.com/greghendershott/travis-racket Travis don't support Racket directly, so his package is very useful for testing without having to study all the details about the naming and download addresses of each version/variant, I use it all the time.
* Rackjure: "Provide a few Clojure-inspired ideas in Racket. Where Racket and Clojure conflict, prefer Racket." https://github.com/greghendershott/rackjure I don't use it, but I think it's a nice idea, and it show how Racket can be used for multiple programming "frontends".
* Travis-Racket "https://github.com/greghendershott/travis-racket*" https://github.com/greghendershott/travis-racket Travis don't support Racket directly, so his package is very useful for testing without having to study all the details about the naming and download addresses of each version/variant, I use it all the time.
Greg Hendershott has contributed a lot of software development, and also a lot of community participation. The latter doesn't appear on one's CV, but makes a big difference, and has network effects.
The community of Racket has long been one of its selling points, which new adopters often mention, and people like Greg are why.
The community of Racket has long been one of its selling points, which new adopters often mention, and people like Greg are why.
He also wrote what I suspect is the de facto Markdown parser for Racket, which is used in Pollen. (I thought I recognized his name dimly, and it's because I reported a bug in Pollen a few years ago relating to Markdown smart quote handling that turned out to be a bug in his Markdown processor -- which he fixed virtually instantly. https://github.com/greghendershott/markdown/issues/45 for the curious.)
Another one that I really like:
* Frog: "Frog is a static blog generator implemented in Racket, targeting Bootstrap and able to use Pygments." https://github.com/greghendershott/frog
* Frog: "Frog is a static blog generator implemented in Racket, targeting Bootstrap and able to use Pygments." https://github.com/greghendershott/frog
I use his emacs racket-mode and it works great.
I agree in the sense that the non-s-expression syntax proposal also rubbed me the wrong way.
Rust is an interesting language but I have spent less than 20 hours playing with it. I am mostly retired now but if I were just starting my career then Rust is a language I would invest a lot of time in.
Anyway, I can’t even imagine myself using Racket with a non Lisp syntax.
Rust is an interesting language but I have spent less than 20 hours playing with it. I am mostly retired now but if I were just starting my career then Rust is a language I would invest a lot of time in.
Anyway, I can’t even imagine myself using Racket with a non Lisp syntax.
To me, Flatt's proposal for Racket2 smells more like adding tools to better facilitate infix languages than depricating S-expressions. Given Racket's pedagogical mission, it looks more like a move toward migrating the HtDP series of languages (Beginning Student, Intermediate Student, Intermediate Student with Lambda, and Advanced Student) to infix syntax than anything else. Not really the end of the world or a big change to the larger Racket community. Just another extension of an ecosystem that remains s-expression based despite Algol and Datalog shipping in the box. It's hard to see Flatt's work porting Racket to Chez Scheme as a prelude to abandoning Scheme as the basis for the Racket ecosystem.
On the other hand, the reality is that Racket's syntax makes for an uphill fight when it comes to adopting the HtDP curriculum. Anyway #lang racket syntax is just sugar on the more important concepts in the HtDP methodology. The HtDP engineering principles are matter much more than which language is used at the top level.
On the other hand, the reality is that Racket's syntax makes for an uphill fight when it comes to adopting the HtDP curriculum. Anyway #lang racket syntax is just sugar on the more important concepts in the HtDP methodology. The HtDP engineering principles are matter much more than which language is used at the top level.
I think this is probably a big testament to the draw that Rust has. Its a great language with big improvement and it feels like it will actually happen.
Whenever I dabled around with other languages, I quickly found reasons to not go deeper that where outside of the language itself. Like, small community, not many libraries, will never convince the boss to use it in production, doesn't run on embedded, ...
Rust is the language that really feels like investing in it will pay off.
(Still - do some Racket, or lisp or scheme, it's fun and exposes you to cool ideas and concepts.)
Whenever I dabled around with other languages, I quickly found reasons to not go deeper that where outside of the language itself. Like, small community, not many libraries, will never convince the boss to use it in production, doesn't run on embedded, ...
Rust is the language that really feels like investing in it will pay off.
(Still - do some Racket, or lisp or scheme, it's fun and exposes you to cool ideas and concepts.)
The Lisp community will feel the loss of Greg Hendershott.
[deleted]
Funnily enough, I read just recently (though I can't remember where) that John McCarthy originally intended to develop a syntax called M-expressions (derived from Algol or Fortran) for LISP that would be compiled to s-expressions, but users seemed content with the s-expressions and he didn't bother.
Ah, Wikipedia mentions something on the topic:
https://en.wikipedia.org/wiki/M-expression
Plus ça change, etc.
Ah, Wikipedia mentions something on the topic:
https://en.wikipedia.org/wiki/M-expression
Plus ça change, etc.
Since he mentions Rust, I have seen Rust being used for many different things and not only "systems programming", aking to a general purpose language.
Is this because the language lends itself easily to all this tasks? or is the Rust hype and devs using it for different things to learn the language?
Is this because the language lends itself easily to all this tasks? or is the Rust hype and devs using it for different things to learn the language?
Rust is currently the most overhyped language because it promises a lot of things, but cannot hold the most important ones. It's a nice language, but don't believe any security guarantee. memory safety, type safety, concurrency safety massively overhyped. Still much better than C++ though.
> Still much better than C++ though.
Well, no. There is zero reason to use Rust if you already know modern C++. Rust's only benefit is being newbie-friendly.
Well, no. There is zero reason to use Rust if you already know modern C++. Rust's only benefit is being newbie-friendly.
Rust
* is a lot simpler
* has a package manager
* has type classes (like interfaces with default implementations)
* doesn't have multiple inheritance or inheritance
* much nicer unified error/exception pattern
* amazing compiler error messages
* makes memory corruption and many forms of concurrency errors impossible(outside of ffi and unsafe)
* has tuples+sum types w/destructing
* is a lot simpler
* has a package manager
* has type classes (like interfaces with default implementations)
* doesn't have multiple inheritance or inheritance
* much nicer unified error/exception pattern
* amazing compiler error messages
* makes memory corruption and many forms of concurrency errors impossible(outside of ffi and unsafe)
* has tuples+sum types w/destructing
I like cargo and easier threading. The syntax is annoying though. C/C++ really would benefit immensely from a central library repo.
The learning part is pretty string, I guess. I sometimes do scripting tasks in Rust now instead of Python and the motivation is clearly learning. At the same time, the tooling is so good and fun to use that I don't feel like I'm putting myself through a painful exercise. Stuff like clasp for example (library to do CLI interfaces) is so good that I prefer it over doing that in Python.
Both, I think.
The language is fairly high level, and the borrow checker + RAII covers a lot of the ergonomic-gains of garbage collection. It's also appealing in that it moves towards functional, but not too much (beneficial for those who like the idea of functional programming, but can't be assed to pick it up properly -- eg me).
And the absurd hype cycle just keeps it permanently in mind.
The language is fairly high level, and the borrow checker + RAII covers a lot of the ergonomic-gains of garbage collection. It's also appealing in that it moves towards functional, but not too much (beneficial for those who like the idea of functional programming, but can't be assed to pick it up properly -- eg me).
And the absurd hype cycle just keeps it permanently in mind.
A lot of people get caught up in Rust's low level implementation stuff but you really don't need to touch that stuff at all if it's not your thing. Just understand enough about what you're doing with memory and the various performance trade offs which become more prominent at that level of the machine.
There's more than enough high level stuff like the type system and traits which you can go harder into in terms of learning new/better ways to program.
There's more than enough high level stuff like the type system and traits which you can go harder into in terms of learning new/better ways to program.
I feel like there's some paragraphs missing in this post between "I'm concerned the change won't help grow the community" and "I'll no longer learn or have fun in this community". He doesn't explicitly say how he expects his relationship with Racket to change, or why. He's implying, though not even outright stating, that he's distancing from Racket because of Matthew Flatt's proposal. That's begging for further explanation. Mere proposals don't warrant this sort of reaction. Racket is hardly a stranger to radical proposals. What's going on behind the scenes that's so serious as to warrant a post like this? Why, in short, the vagueposting drama?
He didn't rehash arguments that he had made on the Racket mailing list in his blog post. Here is one example: https://groups.google.com/forum/#!msg/racket-users/vN_1uUJZn...
I'm not talking about his specific objections to the proposal. I'm talking about why those objections, which seem to be taking place in the context of a reasonable discussion where everyone's opinion is heard, have led him to the conclusion that he will no longer enjoy participating in the Racket community.
This is a key line from his post:
"Also to be fair, if you have some mileage on your odometer, your pattern-recognition machinery will quickly assign high probabilities to various outcomes."
His combination of personality and experience is leading him to draw conclusions about where Racket2 is headed that is causing him to press pause on using (and contributing to) Racket. I had a similar reaction (described in this post: https://www.travishinkelman.com/post/exploring-scheme-implem...).
It seems that you are not assigning as high of probability to the outcomes that Greg is concerned about. Or you are not as concerned about those outcomes.
"Also to be fair, if you have some mileage on your odometer, your pattern-recognition machinery will quickly assign high probabilities to various outcomes."
His combination of personality and experience is leading him to draw conclusions about where Racket2 is headed that is causing him to press pause on using (and contributing to) Racket. I had a similar reaction (described in this post: https://www.travishinkelman.com/post/exploring-scheme-implem...).
It seems that you are not assigning as high of probability to the outcomes that Greg is concerned about. Or you are not as concerned about those outcomes.
S-expressions were the one thing that held me back from Racket. I like a lot that I've heard about the language, and I'm a believer in keeping syntax as simple and regular as possible, but in my book a language that doesn't allow infix expressions is not usable, while a "language" that requires users to implement text-based macros to work productively in it is incomplete.
The article doesn't link to the syntax proposal, so I don't yet know what it looks like. But for the first time I now hope that Racket might become a practical language that I could use. No S-expression language has ever gone beyond niche. I'm glad Racket is willing to step past them.
The article doesn't link to the syntax proposal, so I don't yet know what it looks like. But for the first time I now hope that Racket might become a practical language that I could use. No S-expression language has ever gone beyond niche. I'm glad Racket is willing to step past them.
Racket will never be a practical language, but not because it is a lisp. Clojure is a lisp and is plenty practical.
Racket was designed to teach programming to young students, which unfortunately isn't a killer app for a language even though I learned a great deal from HTDP and Racket/PLTScheme.
There have been other languages that were not lisps like Dart that utterly failed or like Coffeescript, which faded away because the space that they were trying to overtake (Javascript) was already deeply entrenched.
If you can't appreciate Racket beyond it's syntax, it's unlikely that you'd appreciate it with a new syntax. Racket is academic niche in the same ways Haskell is.
If parentheses and lack of infix symbols are sufficient to keep you away from Racket and you want much of the same level of metaprogramming and macros I suggest trying out Julia, which is considerably more practical where infix expressions and operators make sense within the numerical context: Every infix operator is a function call and has a dual syntax.
But don't please don't lie to yourself that you'd ever adopt Racket if it had infix expressions. I love Racket and I still don't use it for many practical projects because the demands of work are different than academia, which I believe are the true barriers to adoption.
Racket was designed to teach programming to young students, which unfortunately isn't a killer app for a language even though I learned a great deal from HTDP and Racket/PLTScheme.
There have been other languages that were not lisps like Dart that utterly failed or like Coffeescript, which faded away because the space that they were trying to overtake (Javascript) was already deeply entrenched.
If you can't appreciate Racket beyond it's syntax, it's unlikely that you'd appreciate it with a new syntax. Racket is academic niche in the same ways Haskell is.
If parentheses and lack of infix symbols are sufficient to keep you away from Racket and you want much of the same level of metaprogramming and macros I suggest trying out Julia, which is considerably more practical where infix expressions and operators make sense within the numerical context: Every infix operator is a function call and has a dual syntax.
But don't please don't lie to yourself that you'd ever adopt Racket if it had infix expressions. I love Racket and I still don't use it for many practical projects because the demands of work are different than academia, which I believe are the true barriers to adoption.
> Racket was designed to teach programming to young students,
I'd say that the "teaching languages" were designed for teaching students, and Racket was designed as the practical tool for implementing those languages and a cross-platform IDE to support them. As a result of this, and various subsequent community work, Racket is now practical for many purposes.
I said a little more about this recently: https://news.ycombinator.com/item?id=20507549
I'd say that the "teaching languages" were designed for teaching students, and Racket was designed as the practical tool for implementing those languages and a cross-platform IDE to support them. As a result of this, and various subsequent community work, Racket is now practical for many purposes.
I said a little more about this recently: https://news.ycombinator.com/item?id=20507549
There is still no official proposal, but there are some early draft / ideas:
* https://github.com/racket/racket2-rfcs/pull/88
* https://github.com/racket/racket2-rfcs/issues/3#issuecomment...
There is a lot of discussion in that repository that are not about syntax. For example "the big renaming" https://github.com/racket/racket2-rfcs/issues/49 and "more immutability" https://github.com/racket/racket2-rfcs/issues/22 .
* https://github.com/racket/racket2-rfcs/pull/88
* https://github.com/racket/racket2-rfcs/issues/3#issuecomment...
There is a lot of discussion in that repository that are not about syntax. For example "the big renaming" https://github.com/racket/racket2-rfcs/issues/49 and "more immutability" https://github.com/racket/racket2-rfcs/issues/22 .
With Racket, the community relationship has been fuzzier, with all the various enthusiasts and volunteers, with money not a factor.
From the professors' perspective, I'd say they're pursuing their research and education ideas, as well as getting funding, publications, tenure, awards -- and I think all that is mostly the goals of Racket. Nurturing a user base serves those goals.
From some other community people's perspectives, Racket is a community effort, to support, with the professors doing most of the work on the core, while everyone contributes in various other ways. I suspect many have assumed it's a partnership of aligned interests, towards some shared goals, or that the core is a benevolent dictatorship that will represent the interests of the current user community.
I recently saw someone mocking Racketeers for being alarmed about losing their precious parentheses, but I don't think that's the problem, for maybe half the people who are concerned. I think the problem for some is having their ideas of the goals of Racket and the community relationship shaken up, after they've invested.