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