5 ms·

It was heavily discussed previously. In particular, it triggered this response from Rust contributor withoutboats: https://news.ycombinator.com/item?id=26410487

• mirekrusin 5y ago
  Wow, thanks, that was burried from me, thanks for surfacing it.
• auggierose 5y ago
  Oh, thanks for that link. Withoutboats is being quite emotional, but it is understandable to be emotional about their brain child. I am tempted from time to time to try Rust, but in the end, I don't think it provides enough benefits for me to consider it. I like high-level, and when I am going low-level, I don't want to be hand-cuffed. It seems with Rust, I am paying all the time just for the ability to go into hand-cuffed low-level mode.
  • jdub 5y ago
    Nah, you're really not. Most of the time, particularly if you're not writing libraries, Rust feels like a dialect of Python that wants to help you get things right.
    • auggierose 5y ago
      Well, 90% of what I am doing is writing libraries. I know how to get things right. Does Rust?
      • ssokolow 5y ago
        Honestly, as a consumer of libraries, I much prefer when they're written in Rust (without gratuitous use of `unsafe`) compared to a language which doesn't make you think about these sorts of things as hard.
        • auggierose 5y ago
          For me, writing a program is mostly writing a bunch of libraries that I then put together. So I am consuming my libraries mostly myself. Therefore, for me it is important that both the library writing and the library using can be done efficiently. I assume that having a Rust library of something is a good thing. The question for me is: How easy and natural and quick is it to express a concept as a library in Rust?
          • eximius 5y ago
            There are roughly two levels to the discussion: 1. Do you like strong type systems? If so, Rust us great! If you really would e itching for some python or JS, it may bother you, even though the Rust type inference really makes it a non-issue. 2. Do you care about allocations? One could be cheeky and rephrase it as "do you care about performance", but caring about allocations is one of the more advanced optimization concerns and GCed languages can have great performance if you dont hit their pathological cases. But the thing about Rust is that you have as much control as possible to avoid allocating. Entire libraries can allocate nothing more than temporary stack variables, with their primary data being lifetime constrained references the user passes in. 2.5 if you dont care about allocations, then does `Rc<Foo>` bother you? There are very easy escape hatches when you _just don't care_ if that thing is shared and don't want to deal with lifetimes. But Rust _lets you choose_. To me, its a pleasure to use.
            • auggierose 5y ago
              I see type systems as a necessary evil. Obviously, I like to be able to distinguish a 32 bit integer from a 64 bit integer or a String. And being able to define interfaces is important. But I am not a fan of modelling all sorts of high-level issues as a type system, because that always comes at a prize: When it works, it is great, and otherwise it really really sucks. So yeah, Rc<Foo> and stuff like that would bother me, because most of the time, these things are rather peripheral to what I am implementing. I feel that, when performance is really really important, it is more important to be able to generate code on the fly, and I don't think Rust supports that. But I haven't tried out ownership in Rust. I will have to work with it for a while to see if it bothers me or not.
      • jdub 5y ago
        "I know how to get things right." Ah, you're one of those people. Sure. :-)
  • jokethrowaway 5y ago
    I'd say seat belts more than handcuffs. When going low level it's easy to slip in memory leaks and security vulnerability. If you care about developer speed and security but don't care about correctness or performance you can rely on someone's else implementation and write higher level code (eg. use node and offload low level security considerations to node). If you care about developer speed and performance but don't care about correctness or security use a low level unbounded language (eg. write C and triple check your code) If you care about security, correctness and performance but don't care about developer speed, use Rust. To be frank I find the point about developer speed in Rust to be a bit exaggerated, it's pretty high level and the tooling is pretty great. - Compiler speed is a bit hit or miss - Debugging life cycles definitely take some time, but with time you get the hang of it and you can quickly copy paste previous solutions to the current problem. - You save a significant amount of developer time by fixing things alerted by the compiler instead of finding errors at runtime All things considered Rust is definitely the language I feel more productive in (before it used to be Haskell). Oftentimes considerations about hiring / collaborating with other developers take the precedence over security, correctness and performance. Right now I'm maintaining a node.js project, 2 Python projects and a Rust project - mainly because node.js and Python worked best with those teams and the Rust one is a solo project.
    • auggierose 5y ago
      I am currently using Swift, and I like it a lot. But you are kind of siloed into the Apple ecosystem. So I am looking for an alternative. I am thinking TypeScript might give the biggest bang for the buck: * You have the widest possible reach via web apps & Electron * You have an eval/Function object for compiling code on the fly * You can embed low-level code via WebAssembly (and here Rust might be relevant for producing that WebAssembly) * If you need access to your TypeScript libraries on mobile, you can still do that via embedding a hidden WebView.
    • ModernMech 5y ago
      > To be frank I find the point about developer speed in Rust to be a bit exaggerated, it's pretty high level and the tooling is pretty great. Rust has a long learning curve that most people won’t make it through. For them, they might feel the language is slow to developenin because they haven’t gotten to the point where they are “thinking” in Rust. As a Haskeller, you are well suited to learn Rust; due to their similar ML lineage (the original Rust compiler was written in OCaml), Rust and Haskell make some similar design considerations. I’d say one thing Rust does right is take a lot of the things that make Haskell safe and make them fit in an imperative language.
  • FpUser 5y ago
    I am sort of in the same boat. I use C++ for server type applications. I consider modern C++ safe enough. While there are no explicit safety guarantees I am a practical man. My servers work for years without any complaints from clients. No memory leaks, no crashes. That's the end result and I think from that perspective for me using Rust would be ROI negative as I would have to port / replace a lot of code I reuse in my various products. Things of course would be different should the client insist on implementation done in Rust but so far not a single client of mine ever mentioned using this language.
  • mgaunard 5y ago
    The point of Rust is that your mediocre C++ developers won't be able to write some kinds of bad code patterns with it, since it won't compile. The problem is that most likely those mediocre C++ developers won't be able to write any Rust at all. If you do have good C++ developers, you're also probably better off sticking to well-established and battle-proven C++. So the use case for Rust remains niche. It's a way to attract the programming language nerd that knows more about Haskell than he does about systems programming. Maybe not exactly the best fit? But worth trying if you want to differentiate yourself from the competition.
• IshKebab 5y ago
  To be fair withoutboats didn't really address any of the points that people make about the flaws of async Rust (e.g. the cancellation problem). It may be the case that there's no good way to solve them, but that doesn't mean that they aren't problems and it doesn't really help to say that people who highlight them are totally wrong and don't know what they're talking about. That said I think your second link does a much better job of explaining the issues than this post does.
  • pornel 5y ago
    withoutboats has explored these trade-offs on their blog, e.g. https://without.boats/blog/poll-drop/ https://without.boats/blog/poll-drop/ and as part of io-uring investigation. io-uring is the main use-case for async drop, but even that has been mostly solved without language changes: there is tokio-uring now. Apart from requiring a safe zero-copy io-uring abstraction to use a buffer pool instead of "bare" references, Rust's polling+cancellation model is fantastic. It's incredibly convenient to be able to externally time out and abort any Future, without needing to pass contexts/tokens and/or needing every I/O operation to have an explicit timeout option. It's annoying when conscious small trade-offs are framed as fatal flaws (like the title of TFA). In the case of the cancellation model the "doesn't work" is that a safe abstraction is not entirely zero-cost. But when you use async in JS, C#, or Golang, you already have unavoidable heap allocations and memcpys (and another set of difficulties with cancellation). Rust's worst-case flaw is comparable to a normal mode of operation in a few other async languages. The scale of the issue is overblown, and its benefits are overlooked.
• tptacek 5y ago
  Is that provoked by the author of this post, or just a random commenter on the thread that post spawned? It looks like the latter.
  • hitekker 5y ago
    I’d say both. The author of the post called Rust async/await a disaster, and the top commenter, who withoutboats replied to, agreed with the author’s criticism.
    • tptacek 5y ago
      I don't think the author of a blog post is accountable in any way for the most inflammatory thing somebody that agrees with them says.
      • hitekker 5y ago
        The original article is just as inflammatory as its top comment if you’ve read it: > In 2017, I said that “asynchronous Rust programming is a disaster and a mess”. In 2021 a lot more of the Rust ecosystem has become asynchronous – such that it might be appropriate to just say that Rust programming is now a disaster and a mess. As someone who used to really love Rust, this makes me quite sad. I imagine withoutboats read both and was pretty upset.
        • tptacek 5y ago
          I'm less comfortable projecting my own opinions into the head of 'withoutboats than you are. The author of the comment they responded to and the author of this post are not the same person.
          • deleted 5y ago
            [deleted]
          • deleted 5y ago
            [deleted]