4 ms·

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 availabil

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.

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.