8 ms·

Rust is lower-level, it is a replacement for C and C++. I'd love to work with Rust but there are only so much low-level projects where it makes sense - kernels

by epx 7y ago

Rust is lower-level, it is a replacement for C and C++. I'd love to work with Rust but there are only so much low-level projects where it makes sense - kernels, Web engines, things like HTTP servers. Go covers those cases where you would like to use Python but it would be too slow.

k__ 7y ago
Would be cool if Rust could cover that gap.
- AstralStorm 7y ago
  It's close enough with its syntactic sugar and type system. There's no gap at all, really. One place where Java and C# win, and sometimes C++, is the availability of excellent libraries. Rust doesn't have as many and not as fleshed out either. Go has the same problem though.
  - asdkhadsj 7y ago
    Agreed, I write everything in Rust these days. I usually dogfood areas where normally I would recommend Go but I'm curious on what the end product will end like in Rust. So far, all the projects have been super easy and only as complex as I want them; with one exception: Diesel. If a developer came to me and wanted to write something in Rust over Go, but didn't know Rust well and wanted to use Diesel, I'd warn them not to. The errors you can get from Diesel are insanely unhelpful and quite advanced in the type system. With that said, I don't think Go really has a comparison to Diesel either.. so perhaps this is an unfair warning. If instead you use raw SQL with Diesel, suddenly it becomes just as friendly as Go's SQLX, and yet again Rust becomes largely as simple as Go. Rust is in my view surprisingly simple. If you choose advanced features you usually understand them. It seems to me that using libraries are the biggest threat to making Rust feel insanely complex; ie Diesel's type system. As an aside, I hope one day Diesel can achieve errors akin to TQL (which I found recently), as TQL really nails the error reporting from what I've seen, at least.
    - mamcx 7y ago
      I agree. I made my own pseudo-ORM layer instead. I make a small python script that spit out rust structs and stuff and cover the rest with traits. Is not bad. I think for RDBMS Rust lack the Python DBAPI interface. Too much reimplementation at the low level (ie: I adapt postgres and sqlite and frankly, both drivers are dissimilar is unnecessary ways).
    - hathawsh 7y ago
      I'm having a similar experience with Rust. Libraries that expose complex types can be hard to use because mistakes lead to confusing compiler error messages with over 100 lines of mostly irrelevant details. I can use libraries that expose complex types, but I have to be prepared for a steep learning curve for each such library. On the other hand, there are many libraries that expose only simple types and I can use them easily. BTW, I love how the Rust compiler uses all CPU threads. It's fast on my 8 year old Ubuntu desktop with 6 cores / 12 hyperthreads.
  - ori_b 7y ago
    Garbage collection makes Java, C#, and Go remarkably more productive for most programs.
    - AstralStorm 7y ago
      Until your memory blows up or the GC stalls become a performance issue you have to solve. And by then it's very hard to fix as it got interwoven in the design of your application. Rust forces you to think about memory use and ownership ahead of time, but after some short practice it really gets out of the way and does not become a problem, while avoiding bad code nasties like interlinked singletons, cyclical references or random shared_ptr held forever. Additionally the explicit memory model makes interacting with C (and often C++) code much more straightforward. Source: had to wrangle that performance issue on Android both in Java and C++. Had to help JVM not stall forever in IntelliJ.
      - ori_b 7y ago
        I've done a bunch of performance work. For many applications I've had to speed up, the performance issues were either localized with low hanging fruit, or were architectural, where layers of abstraction led to translations between impedance mismatches throughout the whole application -- transforming an image 4 times between different coordinate spaces before drawing it on the screen does not make for a fast application. A language change isn't going to solve that. GC pauses have almost never been an issue: It's irrelevant for servers. For UI, most code just doesn't end up allocating that much in the UI thread. Yeah, for things like games that do a lot of work and need to update at 120fps, GC can be a problem. I generally don't write that kind of code. I'd really rather have a GC for 90% of all code that I ship.
        smarterclayton 7y ago
        For Kubernetes in general this has been my experience over the last 5 years (and the year preceding on Docker and other "learning Go" projects). For web style apps with moderate to heavy client complexity (Kube APIs, client libraries) I have appreciated about being able to start with the GC, when we hit a scale cliff go and remove a 5-10 stupid allocation patterns (inlining, value types, removing pointers or replacing with internal index references so the collector ignores them), get another 10x scale from that, then go back and do architectural improvements, get another 10x, then trim some fat around the edges and get another 5x. You definitely hit a wall at some point (comparing the best that you can do in Go with protobuf / JSON relative to say Serde) where the remaining 2-10x efficiency is not achievable. That is where I'd be most interested in generic like constructs in Go where I can type and define down. It's hard to beat the clarity and brevity of Serde - no one in Go has done it at anywhere near the performance.
- azakai 7y ago
  >> cases where you would like to use Python but it would be too slow. > Would be cool if Rust could cover that gap. To really cover most of that gap, writing Rust would need to be as easy as writing Python, since that's one of the main selling points of Python. But Rust's massive benefit, compile-time memory management, is definitely not as easy to write as code that uses GC. GC has overhead that you sometimes can't tolerate, but it's just simpler to write. If you have a graph of objects, it's easy to do in Python or C# or JavaScript. In Rust it's more complicated, because it's hard to do that at compile time! The huge benefits of Rust are directly relevant for systems code, but for most Python code it's probably not the best tool.
shpongled 7y ago
Eh, I use Rust as a python replacement for most tasks (exception is for something super simple that's just a couple lines with pandas). Rust isn't bound to low level tasks - it certainly excels at them, but there's nothing stopping you from writing web services in it
- shrimp_emoji 7y ago
  >I use Rust as a python replacement for most tasks Wie bitte??? My wig has been snatched.
  - shpongled 7y ago
    To be honest, I find it extremely frustrating to write anything non-trivial in Python (or any dynamically typed language, for that matter).
  - pierreyoda 7y ago
    Rust complexity is a bit overblown. I also revert automatically to it now if I feel like Typescript (Node.js) won't cut it, even for < 1K LOCs. I may be biased since I've been using it for almost 6 years, but you mostly don't need to worry about lifetime annotations which IMO is the really foreign part if you are already comfortable with functional languages, especially since the compiler is unbelievably useful. Many well-known Rust crates also account for the majority of the best all-around libraries I've ever personally used in any language, and you can actually use them without a PHD in build systems thanks to Cargo. Re-usability is superb thanks to traits (composition over inheritance) and generics, even if still immature domains tend to be overly generic for the end-user (HTTP networking for instance, though it's getting better fast).
  - bsder 7y ago
    I'm beginning to lean toward the camp of Rust replacing Python, too--and I've been using Python since 1996-ish. My primary limitation in Rust is the state of the libraries--Python libraries and frameworks are simply a LOT more stable in general. The first question is "What does Python do better than Rust?" Libraries/frameworks is the big one--there is no excellent Django-equivalent or Jupyter notebook-equivalent, for example (maybe there never will be by virtue of the language differences, but it is what it is). Python helper scripts generally ship in .py form so you can fix bugs in crappy Python scripts (if people start shipping Rust auxiliary scripts that's going to be a step backwards). Verbosity--okay, I'll concede that if I want things to be mostly GC, I'm writing a lot of extra wording in Rust. And when I reverse the question: "What does Rust do better than Python?" The answer is a whole lot. Strong typing is a big one--because of Rust doing okay type inference I don't wind up with types repeated very often--it feels more like Python. Performance, sure, but I rarely care. Tooling seems to be a bit better--and Rust seems to be targeting to be a first class citizen on Windows. And, of course, concurrency--Python should have just sucked it up, taken the performance hit in 3.0 to remove the GIL and then optimized performance back over 7 versions (Good concurrency is becoming a standard in languages--I suspect Python is eventually going to concede this or start losing mindshare--and the pain would have been best suffered back at 3.0). Yes, there are issues. If you have a doubly-linked anything in Rust, you're about to have a bad time (or not, if you REALLY need double-linkage--it's time to quit being pedantic, to break out "unsafe" and to encapsulate things). If you're writing a library, your lifetime annotations look like 300 baud line noise. I really learn a new language about every 10 years or so--I have to feel a significant upside without a lot of downside in order to move (my last big change was Perl->Python in about 1996--my history of languages that I knew cold is assembly->C(with a C++ excursion for a bit--I got better)->Perl->Python). At this point, for one-off things that I'm writing a quick 100 lines, I'm starting to reach for Rust more and more and Python less and less.

by epx 7y ago

k__ 7y ago

Would be cool if Rust could cover that gap.

AstralStorm 7y ago
It's close enough with its syntactic sugar and type system. There's no gap at all, really. One place where Java and C# win, and sometimes C++, is the availability of excellent libraries. Rust doesn't have as many and not as fleshed out either. Go has the same problem though.
- asdkhadsj 7y ago
  Agreed, I write everything in Rust these days. I usually dogfood areas where normally I would recommend Go but I'm curious on what the end product will end like in Rust. So far, all the projects have been super easy and only as complex as I want them; with one exception: Diesel. If a developer came to me and wanted to write something in Rust over Go, but didn't know Rust well and wanted to use Diesel, I'd warn them not to. The errors you can get from Diesel are insanely unhelpful and quite advanced in the type system. With that said, I don't think Go really has a comparison to Diesel either.. so perhaps this is an unfair warning. If instead you use raw SQL with Diesel, suddenly it becomes just as friendly as Go's SQLX, and yet again Rust becomes largely as simple as Go. Rust is in my view surprisingly simple. If you choose advanced features you usually understand them. It seems to me that using libraries are the biggest threat to making Rust feel insanely complex; ie Diesel's type system. As an aside, I hope one day Diesel can achieve errors akin to TQL (which I found recently), as TQL really nails the error reporting from what I've seen, at least.
  - mamcx 7y ago
    I agree. I made my own pseudo-ORM layer instead. I make a small python script that spit out rust structs and stuff and cover the rest with traits. Is not bad. I think for RDBMS Rust lack the Python DBAPI interface. Too much reimplementation at the low level (ie: I adapt postgres and sqlite and frankly, both drivers are dissimilar is unnecessary ways).
  - hathawsh 7y ago
    I'm having a similar experience with Rust. Libraries that expose complex types can be hard to use because mistakes lead to confusing compiler error messages with over 100 lines of mostly irrelevant details. I can use libraries that expose complex types, but I have to be prepared for a steep learning curve for each such library. On the other hand, there are many libraries that expose only simple types and I can use them easily. BTW, I love how the Rust compiler uses all CPU threads. It's fast on my 8 year old Ubuntu desktop with 6 cores / 12 hyperthreads.
- ori_b 7y ago
  Garbage collection makes Java, C#, and Go remarkably more productive for most programs.
  - AstralStorm 7y ago
    Until your memory blows up or the GC stalls become a performance issue you have to solve. And by then it's very hard to fix as it got interwoven in the design of your application. Rust forces you to think about memory use and ownership ahead of time, but after some short practice it really gets out of the way and does not become a problem, while avoiding bad code nasties like interlinked singletons, cyclical references or random shared_ptr held forever. Additionally the explicit memory model makes interacting with C (and often C++) code much more straightforward. Source: had to wrangle that performance issue on Android both in Java and C++. Had to help JVM not stall forever in IntelliJ.
    - ori_b 7y ago
      I've done a bunch of performance work. For many applications I've had to speed up, the performance issues were either localized with low hanging fruit, or were architectural, where layers of abstraction led to translations between impedance mismatches throughout the whole application -- transforming an image 4 times between different coordinate spaces before drawing it on the screen does not make for a fast application. A language change isn't going to solve that. GC pauses have almost never been an issue: It's irrelevant for servers. For UI, most code just doesn't end up allocating that much in the UI thread. Yeah, for things like games that do a lot of work and need to update at 120fps, GC can be a problem. I generally don't write that kind of code. I'd really rather have a GC for 90% of all code that I ship.
      - smarterclayton 7y ago
        For Kubernetes in general this has been my experience over the last 5 years (and the year preceding on Docker and other "learning Go" projects). For web style apps with moderate to heavy client complexity (Kube APIs, client libraries) I have appreciated about being able to start with the GC, when we hit a scale cliff go and remove a 5-10 stupid allocation patterns (inlining, value types, removing pointers or replacing with internal index references so the collector ignores them), get another 10x scale from that, then go back and do architectural improvements, get another 10x, then trim some fat around the edges and get another 5x. You definitely hit a wall at some point (comparing the best that you can do in Go with protobuf / JSON relative to say Serde) where the remaining 2-10x efficiency is not achievable. That is where I'd be most interested in generic like constructs in Go where I can type and define down. It's hard to beat the clarity and brevity of Serde - no one in Go has done it at anywhere near the performance.
azakai 7y ago
>> cases where you would like to use Python but it would be too slow. > Would be cool if Rust could cover that gap. To really cover most of that gap, writing Rust would need to be as easy as writing Python, since that's one of the main selling points of Python. But Rust's massive benefit, compile-time memory management, is definitely not as easy to write as code that uses GC. GC has overhead that you sometimes can't tolerate, but it's just simpler to write. If you have a graph of objects, it's easy to do in Python or C# or JavaScript. In Rust it's more complicated, because it's hard to do that at compile time! The huge benefits of Rust are directly relevant for systems code, but for most Python code it's probably not the best tool.

shpongled 7y ago

Eh, I use Rust as a python replacement for most tasks (exception is for something super simple that's just a couple lines with pandas). Rust isn't bound to low level tasks - it certainly excels at them, but there's nothing stopping you from writing web services in it

shrimp_emoji 7y ago
>I use Rust as a python replacement for most tasks Wie bitte??? My wig has been snatched.
- shpongled 7y ago
  To be honest, I find it extremely frustrating to write anything non-trivial in Python (or any dynamically typed language, for that matter).
- pierreyoda 7y ago
  Rust complexity is a bit overblown. I also revert automatically to it now if I feel like Typescript (Node.js) won't cut it, even for < 1K LOCs. I may be biased since I've been using it for almost 6 years, but you mostly don't need to worry about lifetime annotations which IMO is the really foreign part if you are already comfortable with functional languages, especially since the compiler is unbelievably useful. Many well-known Rust crates also account for the majority of the best all-around libraries I've ever personally used in any language, and you can actually use them without a PHD in build systems thanks to Cargo. Re-usability is superb thanks to traits (composition over inheritance) and generics, even if still immature domains tend to be overly generic for the end-user (HTTP networking for instance, though it's getting better fast).
- bsder 7y ago
  I'm beginning to lean toward the camp of Rust replacing Python, too--and I've been using Python since 1996-ish. My primary limitation in Rust is the state of the libraries--Python libraries and frameworks are simply a LOT more stable in general. The first question is "What does Python do better than Rust?" Libraries/frameworks is the big one--there is no excellent Django-equivalent or Jupyter notebook-equivalent, for example (maybe there never will be by virtue of the language differences, but it is what it is). Python helper scripts generally ship in .py form so you can fix bugs in crappy Python scripts (if people start shipping Rust auxiliary scripts that's going to be a step backwards). Verbosity--okay, I'll concede that if I want things to be mostly GC, I'm writing a lot of extra wording in Rust. And when I reverse the question: "What does Rust do better than Python?" The answer is a whole lot. Strong typing is a big one--because of Rust doing okay type inference I don't wind up with types repeated very often--it feels more like Python. Performance, sure, but I rarely care. Tooling seems to be a bit better--and Rust seems to be targeting to be a first class citizen on Windows. And, of course, concurrency--Python should have just sucked it up, taken the performance hit in 3.0 to remove the GIL and then optimized performance back over 7 versions (Good concurrency is becoming a standard in languages--I suspect Python is eventually going to concede this or start losing mindshare--and the pain would have been best suffered back at 3.0). Yes, there are issues. If you have a doubly-linked anything in Rust, you're about to have a bad time (or not, if you REALLY need double-linkage--it's time to quit being pedantic, to break out "unsafe" and to encapsulate things). If you're writing a library, your lifetime annotations look like 300 baud line noise. I really learn a new language about every 10 years or so--I have to feel a significant upside without a lot of downside in order to move (my last big change was Perl->Python in about 1996--my history of languages that I knew cold is assembly->C(with a C++ excursion for a bit--I got better)->Perl->Python). At this point, for one-off things that I'm writing a quick 100 lines, I'm starting to reach for Rust more and more and Python less and less.