What exactly are you scared of? What is the bad outcome that will come from more software being written in Rust? Are you scared that important projects will be derailed by a successful campaign to rewrite large amounts of code in Rust? Or something else? The fact that promotion of Rust pattern-matches against a scary political movement isn't, IMO, reason enough to be scared.
To be clear, I'm not part of any coordinated Rust marketing effort. I just like what I've seen of Rust so far, I want to write more of it (edit: particularly in contexts where I currently use Electron or server-side web frameworks based on less efficient language runtimes), and I think enthusiasm about Rust is justified.
If Rust had the momentum of a typical over-hyped programming language I'd be merely interested. The insane "better than a politician" marketing creates risks I can't even foresee, and the ones I can are all very, very bad.
To be clear, are they actually denying the influence of Haskell and other languages, or are they just saying that `?` notation is something new in their experience, and better than what's available in current popular languages? IMO, there's nothing wrong with the latter.
> not a syntax for a somewhat broken, highly limited notion of effects distinct from computation. There are effect contexts not only richer, but critically more important than `Either`, e.g. `StateT`.
So are you concerned that the hype around Rust will prevent people from discovering Haskell and using it in situations where it would be an even better choice? I guess that could happen, but IMO promoting something less dangerous than C and C++ on the one hand, and more efficient than JavaScript on the other, that people will actually be willing to use for real projects today, is important enough to justify that risk.
> risks I can't even foresee, and the ones I can are all very, very bad.
What are some of those risks you can foresee?
They are completely aware of the necessity of separating effects from computations if one truly wanted to create a "safe" programming language that was in the critical path of the mainstream. Actually doing this is a fairly high bar modulu all the memory-safety nonsense in the talking points deck. It would create roughly no people who had a low-friction migration path from TypeScript to Rust, which is diametrically opposed to having a menacing mob at ones disposal.
Rust is halfway between the polar points articulated by Paul Graham: it's neither designed for it's serious users (though they pretend to like it) nor it's audience who it openly condescends to.
As for the scary effects of having a programming language committee control more votes than 4chan on internet forums in general: yeah I don't know how that's going to play, but I'm pretty sure I'm not going to like it.
Having a low-friction migration path from TypeScript also enables more programmers to write reliable, efficient software. I hope that the number of programmers quietly doing this will grow to eclipse the number posting to forums. We must not get so caught up in forum drama that we forget that increasing the quantity of good software in the world is what's most important.
No, it can’t be that even despite of that, in that thread he is still correct, and we are both professionals, and therefore don’t bring petty shit into hacker news threads. He’s still right in that thread regardless of interpersonal bullshit.
No one is saying that everyone will be served well by the default, but virtual memory is a great deal cheaper than physical DRAM on every conceivable platform for Jai or Rust, and him blowing it off in big chunks to avoid compiler/borrow-checker errors for the same cost in core without a bitchy compiler is a win in the leathered hacker's book.
Why do you people always need to be right?
Catch a Rust person saying this is fucked full stop and it's too late to fix it.
And, moreover, that it's an opinion shared by the python and c++ communities? I'd love to see evidence of that. I'd also love to read arguments about why Vec/vector is stupid, it's certainly the first time I read that.
The fact that `?` is baked in for Option/Result is a pragmatic choice that allowed rust to ship in 2015, not 2035, when the research on mixing effect systems and borrow checker is done. There were already enough innovations tokens in rust 1.0, and moving the needle forward on memory safety and decent type systems is having a positive effect on all the other languages in that space (Zig, Carbon, now C++/C++2…).
No one in the Haskell community is like great: linked lists as the fundamental data type is just awesome on modern x86.
The people in the Python community are like great: we just broke everything and took a decade doing it, because we were emphatically wrong about ASCII being a given.
The people in the Rust community say nothing like this: Rust isn’t wrong: you’re wrong. Which is going to get progressively weirder as we move back to ASICS more weird than GPUs.
I’m enheartened to hear that someone (e.g. you parent) has some grasp on reality on this, but I’ve been in this game long enough to see a decade of progress dunked over CORBA and XML, which had nothing like the mindshare or organic buy-in this Rust stuff does.
This is true fanaticism, and I don’t know about you, but I’m going to miss being retired for it’s consequences for the least fun decade of a career that included Visual Basic.
What percentage of new software will actually be affected by this? My guess is that it will still be most practical to write lots of software in an imperative style, and Rust will let us do that more safely and efficiently than other popular languages. For the problems that really need to be solved through custom ASICs, we have things like the Haskell-inspired Clash [1]. I doubt that the hype around Rust, and even the most misguided Rust boosters, will impede progress on that front.
Find me that one.
I think the more meaningful question is whether local arenas are idiomatic enough in Rust. Of course, custom allocators are not the easiest thing to use in C++, either.
And there are other semi-related things, such as allocating and initializing pinned objects in-place, for which Rust is still lacking a good story as the Rust-for-Linux folks have pointed out recently.
The fucking arrogance. It is not the world’s job to accommodate Rust. It’s C’s job to work out whether Rust works out or not.
I’m proposing Jai (and John) as plausibly more in touch with a rapidly-changing hardware landscape than Rust by definition practically ever could be without another round of pre-1.0 “everything is broken always”.
Were you earnestly asking that question in good faith because you didn’t read the multiple siblings about Jai and arenas vs affine? Or are you just part of the gang tackle?
Yes, because although I read the whole thread, I didn't get the connection between arenas and the rapidly changing hardware landscape. Now I want to learn more. And, as someone who merely uses Rust in some projects and thinks it's likely to be the least bad alternative for some others, I have no problem contemplating that Rust might have chosen a suboptimal default allocation style. I think the borrow checker is still a good thing though, and don't understand how it could be fully replaced by arena allocation.
> @burntsushi
I get notified when you do this. It would be fantastic if you never did it again. Please.
I'll say @burntsushi when I please, thank you.
Klabnick got flagged below showdead when he mouthed off on this same thread. That's the Rust Community when their temper gets high. My temper also gets high. I apologize when I'm explicitly cited for going out of bounds, which I do. So cite an example (or ten) of me going out of bounds and I'll acknowledge it.
Citing the fact that Carl and Yehuda cited to me in person that they planned to monetize the Rust phenomenon is not hate speech, it's hear say, but everyone believes me, including you.
So let's hear a legitimate complaint?
You seem to be mobilized by Rust quite a lot.
- I move comfortably through the compiler and standard library of Rust, so I’m not mobilized by a lack of understanding
- I’m terrified of this level of fanaticism from people who have only a superficial understanding of Rust, or it’s pedigree, or the historical precedent of particular technology fetishism.
“Blow is right on arena-by-default” is the real point of controversy there. I think it’s obvious, but am open to contrary opinion.
Carl/Yehuda/Tom profiteered off an exceptional ability to forecast language cults: maybe differ with that.
But I’ve really teed up things that one can concretely disagree with: I’ve done this intentionally to deprive the arrows of any tangible meaning, as well-travelled commenters do.
Dumbass under pseudonym.
Many languages, probably most notably among them C++, have implemented varying degrees of what we might call "custom allocator policy".
This is a rather extreme case of a generally over-applied maxim: "defaults matter".
While it is completely possible to do a custom bump-allocator (which is the only kind of allocation on the table if you need to be fast without the help of `tcmalloc` or `jemalloc`), it's sufficiently high-friction that most write their own vector rather than doing the language lawyer thing of doing a "custom allocator".
What John Blow proposes, quite reasonably if not obviously to me, is making a call-frame level arena in which all "heap" allocations are just past the last one, basically burning "reclaim opportunity" in light of the abundance of evidence that no one ever cares about memory that `jemalloc` has already done fragmentation around.