Live data from Hacker News

Future of Racket

greghendershott.com

21–30 of 40 posts

Re: Future of Racket

#21
post #11
post #6

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?

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.

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.

Re: Future of Racket

#22
post #12

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 propos…

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.

Re: Future of Racket

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

Re: Future of Racket

#24

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 technolo…

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.

Re: Future of Racket

#25
post #19

My feel from the Rust that I've done so far: you know you're in something like an industry consortium, they're trying to please all the stakeholders, and gain adoption, and one can even see community input partly as market research. I like that I know where I stand. With Racket, the community relationship has been fuzzier, with all the various enthusiasts and volunteers, with money not a factor. From the professors'…

Unfortunately, the person stepping down in this blog post (Greg) was one of the people who I looked up to when I was really enthusiastic about racket because he was obviously "getting things done" in the language -- solving problems, making things.

Re: Future of Racket

#26
post #10
post #6

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?

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.

Re: Future of Racket

#27
post #24

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 technolo…

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 supportin…

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.

Re: Future of Racket

#28
post #12

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 propos…

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 be…

> 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

Re: Future of Racket

#29

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 technolo…

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.

Re: Future of Racket

#30
post #10

Earlier quoted context omitted.

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.

I like cargo and easier threading. The syntax is annoying though. C/C++ really would benefit immensely from a central library repo.
Post reply on HN