This title broke the HN guideline: "<i>Please use the original title, unless it is misleading or linkbait; don't editorialize.</i>" (<a href="https://news.ycombinator.com/newsguidelines.html" rel="nofollow">https://news.ycombinator.com/newsguidelines.html</a>). On HN, it's not ok to use the title field to point out what you think is important about an article. That's one of the things we mean by editorializing.<p>Titles are by far the biggest influence on discussion. Most comments below are not about the article as a whole—just the cherry-picked bit of the article that the title singled out. Normally we'd change the title to e.g. "The Future of Programming - Interview with Richard Eisenberg" and remove the flags, but in this case the thread is already so skewed I don't think we can.<p>If you want to say what you think is important about an article, that's great, but do so by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: <a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=false&sort=byDate&type=comment&query=%22level%20playing%20field%22%20by:dang" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...</a><p>Edit: there's an earlier submission <a href="https://news.ycombinator.com/item?id=35993993" rel="nofollow">https://news.ycombinator.com/item?id=35993993</a> which I've just added to the second-chance pool (<a href="https://news.ycombinator.com/pool" rel="nofollow">https://news.ycombinator.com/pool</a>, explained at <a href="https://news.ycombinator.com/item?id=26998308" rel="nofollow">https://news.ycombinator.com/item?id=26998308</a>).
This seems a bit unfair to me. The author is not entirely wrong, but it feels like they don't give the full picture. The truth is in Rust you often don't have to heap allocate at all and it is very good at avoiding this much of the time. Obviously, if building something like an AST in a parser, a naïve implementation is going to be calling the boxed allocator quite a bit which will have a lot of overhead, but for things like this I would just use an arena allocator (like bumpalo). So yes, sometimes you have to do a little more allocation, but I think it is greatly over stated. I do really like OCaml, however, and agree a compacting GC with bump allocator can be quite nice at times as well (and a compiler would probably be a good use case for one).
I’m not sure it’s fair to editorialize a title like that when sharing an hour-long podcast.<p>I’m curious about the claim being made but I’m being linked to a haystack.<p>Edit: it begins at 25:34.
I have been used both GCed language and Rust a lot and I can't agree with the quoted put into the HN Headline here.<p>Sure rust borrow checker+move semantics are always there and you always have to cater to it.<p>But they _are not_ a memory management handling tool.<p>It's more like a ownership control tool.<p>Which is used to get some decent semi-manual memory management, but also is used to provide some very neat concurrency guarantees, and many other forms of resource management.<p>E.g. you don't need something like python `with` or java `try-with` it's already there as part of the borrow checker/move semantics for free.<p>So I would rephrase the quote to:<p>"For reliable state handling, you don't pay as you go, everyone has to pay all the time."<p>I did remove the "in rust" part because IMHO this is pretty much always the case (at least for real world non pet projects). Either your language helps with handling state to some degree, in which case you always pay some form of price for it. Or it doesn't in which case you also pay a price for it due to it now being harder and much much more prone to get messy (in my experience guaranteed to get messy in most real world projects).<p>Through I'm never surprised if people focused on functional programming dislike rust: Because rust is _not_ a functional language, it only has many functional elements. But the moment you try write very "functional" style code in it, you can easily end up in a world of pain.<p>Certain common functional abstractions do not scale well if combined with the rusts ownership model (they still tend to work well in simple use-cases). Partially due to limitations of the current implementation/language design. But also some aspects seem to be very hard to solve even on a conceptual level.
Indeed, Rust is ideal for writing kernels, drivers, or getting more secure software in domains where people are religiously against any kind of automatic memory management system.<p>Other than that, there are better options in regards to productivity.
This sounds to me like a new way of saying that languages with GC allow developers to move faster in very many cases than languages without GC which I think I largely agree with.
> I think, first of all, that for a programming language to be effective, everything needs to be opt-in, right?<p>I disagree. You gain a lot by making things not-opt in. For example, strong typing. Strong typing really becomes powerful when everybody uses it. Another example, is purity and side effects. Purity isn’t really optional in Haskell.<p>Which brings another point: you could say that for side effects in Haskell, you don’t pay as you go, everyone has to pay all the time. You are basically forced to deal with the concepts of monads fairly if you want to write anything interesting.<p>Just like Haskell gets a lot of value in using the type system to encode side effects, Rust gets a lot of value in using the type system to encode ownership. Further, I would argue that the borrow checker provides value beyond memory usage, since a clear ownership model can have follow on effects for correctness and program organization.
I actually don't really think about memory all that much for most of the kinds of work that I do. RAII kinda just does it. His idea for optional GC for some data and manual memory management for other data is kinda interesting though.
Can we please get the title put back, the weird anti-Rust clickbait does a disservice to an excellent podcast.<p>The original title was The Future of Programming With Richard Eisenberg.<p>@dang
Adopting a higher-level language where the programmer doesn't have to worry about as much stuff generally comes with some trade-offs. Garbage collection has downsides but for a lot of use-cases they aren't significant. Saying that OCaml has a place in a world where Rust exists doesn't strike me as a very hot take.
That's an interesting point of view. I really don't buy that garbage collection has advantages for the user. Sure it has advantages for the developer of the language, like a GIL, but for the user, it's more a constraint they have to live with.