4 ms·

Rust is much too low level for most glue/web services. Unless you have a specific high performance requirement (and Go doesn't meet this), there's no real stron

• zozbot234 6y ago
  Rust itself is not inherently "low level" per se. But others are probably right that the whole web services ecosystem for Rust is rather half-baked at this time, the OP notwithstanding.
  • rob74 6y ago
    Actually the OP only wrote that the current state of the ecosystem is surprisingly mature, but he doesn't recommend writing anything serious in it yet. Personally I don't see the point to implement a typical web application in Rust - the performance improvements you get will be lost on IO-bound applications, but you'll still be saddled with the complexity of the memory management. I'd rather suggest to rewrite VS Code or the Slack client in Rust (i.e. apps which currently use Web technologies on the desktop) - those would definitely benefit more from increased performance and reduced memory footprint...
    • zozbot234 6y ago
      > the performance improvements you get will be lost on IO-bound applications Performance starts mattering even in IO-bound applications as soon as you're trying to seriously scale out. Especially when running on a cloud-based platform. As for "the complexity of memory management", people like to bring this up about Rust but OP suggests that it's not a huge concern with the language. I do agree that rewriting stuff like Electron-based apps should be a priority, and that Rust can help this via easy bindings to native OS and GUI platforms.
    • deleuze 6y ago
      Stability is often more important than performance.
  • jfkebwjsbx 6y ago
    Having to care for memory management is by definition very low level.
    • FridgeSeal 6y ago
      But I don’t? The borrow checker takes care of that? String vs &str is trivial to get ones head around, usually it’s really easy to decide whether you’d like to pass a reference or ownership, and worst comes to worst, sprinkling some copy/clone etc to get things sorted quickly still yields a binary that’s faster and more robust than something I can whip up in Python...
      • jfkebwjsbx 6y ago
        The borrow checker only checks, it does not solve the problem. In other languages the problem does not even exist to begin with. It is not a trivial problem to solve (as you claim), otherwise we would have never needed the borrow checker to avoid memory bugs, nor higher level languages to speed up development by avoiding the problem altogether. If you are going to end up sprinkling clones, heap allocating and reference counting, then you could have used C#, Java or JS to begin with which are plenty fast with their JIT/VMs and not think about memory at all. Finally, comparing against Python is a very, very low bar for performance.
        • wtetzner 6y ago
          Just because you have a garbage collector doesn't mean you don't have to worry about memory management. I've see too many problems pop up because people don't understand how memory is managed in their GC'd language.
          • jfkebwjsbx 6y ago
            We were talking about the borrow checker and memory safety, not about memory limits, access patterns, etc.
          • tekknik 6y ago