5 ms·

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 ti

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.
      - rackjack 5y ago
        Nobody can answer this question unless you tell us what kind of concepts and libraries you are writing. Sometimes Rust is handcuffs, sometimes it is guardrails, sometimes it is a rollercoaster track. It is impossible to tell without more information. You and the other guys are asserting things with basically no knowledge of the other's context.
  - 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.

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.
    - rackjack 5y ago
      Nobody can answer this question unless you tell us what kind of concepts and libraries you are writing. Sometimes Rust is handcuffs, sometimes it is guardrails, sometimes it is a rollercoaster track. It is impossible to tell without more information. You and the other guys are asserting things with basically no knowledge of the other's context.
- 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.