15 ms·

Nonsense to you is wonderful to me. I don't think "I am unfamiliar with this syntax" is really a useful observation - Erlang has an extremely unfamiliar syntax

Nonsense to you is wonderful to me. I don't think "I am unfamiliar with this syntax" is really a useful observation - Erlang has an extremely unfamiliar syntax, but I don't think that makes it less suitable for building a service. To answer your question more directly (though I feel the article covers these points), as someone building services in rust, there are a few reason I'd choose Rust over the languages you listed: a) Largely deterministic performance Having written services professionally in Java I have seen performance scale linearly with connections, until one day it suddenly spikes massively - why? It was that we crossed some threshold where the GC was suddenly having to do a ton more work, which caused a serious feedback loop - server has to pause, clients don't handle it well, clients hammer server more, server has to pause, etc. You can have similar issues in Rust but they should be easier to spot (they should be less blow-up-y). b) Correctness/ Expressiveness (is this a word?) I find it far, far easier to write correct, expressive code in Rust. For example, I think anyone who has moved from Java 6 to 7 or 8 will admit that Optional is awesome - because it is. In Rust the pattern exposed by Optional is first class, and extends far beyond nullability. This is just one example though. I find it extremely easy, by comparison to other languages, to write Rust code in a 'type driven' way, and in my experience this is a huge part of (me) writing code with fewer defects. As the linked article puts it: > Constraints like a compiler and a discerning type system are tools that help us to find and think about those edges.

danieldk 9y ago
Nonsense to you is wonderful to me. I don't think "I am unfamiliar with this syntax" is really a useful observation - Erlang has an extremely unfamiliar syntax, but I don't think that makes it less suitable for building a service. I do not think this is just about unfamiliarity. Doing static dispatch with generics + traits does add complexity to type signatures. E.g. consider using dynamic dispatch using trait objects trait Frobber { fn frob(&self, something: &OtherTrait); } versus static dispatch: trait Frobber { fn frob<S>(&self, something: &S) where S: OtherTrait; } Of course, static dispatch has large benefits (opportunities for inlining, possibly leading to other optimalizations). Rust adds correctness and deterministic performance (besides Rc/Arc misuse). But Rust also has the potential for 'macro/generics soup' and over-abstraction. I think it is a fair criticism of a language. Use sharp tools wisely. (Disclaimer: writing Rust daily for work.)
- vertex-four 9y ago
  Note that `impl Trait` in argument position has been stabilised and should be in a beta soon, and stable after that - so your latter example can be simplified to: trait Frobber { fn frob(&self, something: &impl OtherTrait); }
  - danieldk 9y ago
    I am not tracking development besides release notes, but that's great news!
    - steveklabnik 9y ago
      1.25 is released Thursday, and has some good stuff. This is coming in 1.26, and it and 1.27 are going to be monster releases with so so so much good stuff. Get ready :)
      - danieldk 9y ago
        Just read that SIMD intrinsics may also be stabilized for 1.27. Keep up the good work!
weberc2 9y ago
> Having written services professionally in Java I have seen performance scale linearly with connections, until one day it suddenly spikes massively - why? It was that we crossed some threshold where the GC was suddenly having to do a ton more work, which caused a serious feedback loop - server has to pause, clients don't handle it well, clients hammer server more, server has to pause, etc. Fair, but you almost never see things like this with Go, and when you do, it's pretty straightforward to triage since the GC and escape analysis are far simpler. Meanwhile, the performance is comparable. > I find it far, far easier to write correct, expressive code in Rust. I know this paragraph was comparing Rust to Java and not to Go, but while Rust is more expressive than Go, man does it take a long time to figure out how Rust wants you to express what you want to express. On the other hand, most things in Go do what you would expect, but sometimes you need to subvert the type system (which is a bummer, but it's worth it to me to sacrifice 1% of type safety for an order of magnitude or more productivity improvement).
- jashmatthews 9y ago
  > Fair, but you almost never see things like this with Go, and when you do, it's pretty straightforward to triage since the GC and escape analysis are far simpler. The Go GC is not a panacea. It trades lower STW pause times for a huge drop in throughput under GC pressure and simplicity for terrible performance with large, mostly static heaps when compared to a generational collector. This entire discussion and the original article is worth reading: https://www.reddit.com/r/programming/comments/5fyhjb/golangs_realtime_gc_in_theory_and_practice_pusher/dapa17l/ https://www.reddit.com/r/programming/comments/5fyhjb/golangs...
  - weberc2 9y ago
    Agreed. My point is that those tradeoffs are really, really good for a huge swath of applications.
    - jashmatthews 9y ago
      I'm not sure that's true. It works well for web proxies and simple CRUD apps. Anything which needs a decently sized heap is multiple times slower than Java, OCaml etc. CockroachDB only works at all because the actual DB is in RocksDB written in C++.
danjoc 9y ago
>Having written services professionally in Java I have seen performance scale linearly with connections, until one day it suddenly spikes massively - why? I'm going to guess: lack of load testing. Something I imagine you still need to do in Rust too.
dmitriid 9y ago
> Erlang has an extremely unfamiliar syntax, but I don't think that makes it less suitable for building a service. However, you can learn and understand all of Erlang's syntax in half a day. Rust's syntax is... less than optimal.
- littlestymaar 9y ago
  I really don't understand people complaining about rust syntax. Coming from a Java and JavaScript background, the Rust syntax was never a problem for me, it instantly felt like home (the only thing that bugged me was the lack or parenthesis around `if` expressions, and the lack of the `return` keyword at the end of a function but that's really no big deal and I internalized it pretty quickly). Some people complain about the angle bracket `<>` but that's from Java ! The type system can be a bit tricky to understand, for people not used to algebraic types, and the borrow checker and memory management story is hard to grasp, but the syntax, I just don't understand the complaints …
  - dmitriid 9y ago
    Syntax is literally the first thing people coming to a language see. Hence the complaints :) If something clicks immediately for you ,might not click immediately (or at all) for others ;) However, Rust's potential syntax issues arise from the fact that they try to express complex concepts within a limited set of characters (and it's a problem any sufficiently complex language will face), so of course people will complain :)
  - catnaroek 9y ago
    Weird, for me it is exactly the other way around. The syntax might be familiar, but it is idiotic. On the other hand, the semantics is exactly what I have always wanted C++ to be.

danieldk 9y ago

Nonsense to you is wonderful to me. I don't think "I am unfamiliar with this syntax" is really a useful observation - Erlang has an extremely unfamiliar syntax, but I don't think that makes it less suitable for building a service. I do not think this is just about unfamiliarity. Doing static dispatch with generics + traits does add complexity to type signatures. E.g. consider using dynamic dispatch using trait objects trait Frobber { fn frob(&self, something: &OtherTrait); } versus static dispatch: trait Frobber { fn frob<S>(&self, something: &S) where S: OtherTrait; } Of course, static dispatch has large benefits (opportunities for inlining, possibly leading to other optimalizations). Rust adds correctness and deterministic performance (besides Rc/Arc misuse). But Rust also has the potential for 'macro/generics soup' and over-abstraction. I think it is a fair criticism of a language. Use sharp tools wisely. (Disclaimer: writing Rust daily for work.)

vertex-four 9y ago
Note that `impl Trait` in argument position has been stabilised and should be in a beta soon, and stable after that - so your latter example can be simplified to: trait Frobber { fn frob(&self, something: &impl OtherTrait); }
- danieldk 9y ago
  I am not tracking development besides release notes, but that's great news!
  - steveklabnik 9y ago
    1.25 is released Thursday, and has some good stuff. This is coming in 1.26, and it and 1.27 are going to be monster releases with so so so much good stuff. Get ready :)
    - danieldk 9y ago
      Just read that SIMD intrinsics may also be stabilized for 1.27. Keep up the good work!

weberc2 9y ago

> Having written services professionally in Java I have seen performance scale linearly with connections, until one day it suddenly spikes massively - why? It was that we crossed some threshold where the GC was suddenly having to do a ton more work, which caused a serious feedback loop - server has to pause, clients don't handle it well, clients hammer server more, server has to pause, etc. Fair, but you almost never see things like this with Go, and when you do, it's pretty straightforward to triage since the GC and escape analysis are far simpler. Meanwhile, the performance is comparable. > I find it far, far easier to write correct, expressive code in Rust. I know this paragraph was comparing Rust to Java and not to Go, but while Rust is more expressive than Go, man does it take a long time to figure out how Rust wants you to express what you want to express. On the other hand, most things in Go do what you would expect, but sometimes you need to subvert the type system (which is a bummer, but it's worth it to me to sacrifice 1% of type safety for an order of magnitude or more productivity improvement).

jashmatthews 9y ago
> Fair, but you almost never see things like this with Go, and when you do, it's pretty straightforward to triage since the GC and escape analysis are far simpler. The Go GC is not a panacea. It trades lower STW pause times for a huge drop in throughput under GC pressure and simplicity for terrible performance with large, mostly static heaps when compared to a generational collector. This entire discussion and the original article is worth reading: https://www.reddit.com/r/programming/comments/5fyhjb/golangs_realtime_gc_in_theory_and_practice_pusher/dapa17l/ https://www.reddit.com/r/programming/comments/5fyhjb/golangs...
- weberc2 9y ago
  Agreed. My point is that those tradeoffs are really, really good for a huge swath of applications.
  - jashmatthews 9y ago
    I'm not sure that's true. It works well for web proxies and simple CRUD apps. Anything which needs a decently sized heap is multiple times slower than Java, OCaml etc. CockroachDB only works at all because the actual DB is in RocksDB written in C++.

danjoc 9y ago

>Having written services professionally in Java I have seen performance scale linearly with connections, until one day it suddenly spikes massively - why? I'm going to guess: lack of load testing. Something I imagine you still need to do in Rust too.

dmitriid 9y ago

> Erlang has an extremely unfamiliar syntax, but I don't think that makes it less suitable for building a service. However, you can learn and understand all of Erlang's syntax in half a day. Rust's syntax is... less than optimal.

littlestymaar 9y ago
I really don't understand people complaining about rust syntax. Coming from a Java and JavaScript background, the Rust syntax was never a problem for me, it instantly felt like home (the only thing that bugged me was the lack or parenthesis around `if` expressions, and the lack of the `return` keyword at the end of a function but that's really no big deal and I internalized it pretty quickly). Some people complain about the angle bracket `<>` but that's from Java ! The type system can be a bit tricky to understand, for people not used to algebraic types, and the borrow checker and memory management story is hard to grasp, but the syntax, I just don't understand the complaints …
- dmitriid 9y ago
  Syntax is literally the first thing people coming to a language see. Hence the complaints :) If something clicks immediately for you ,might not click immediately (or at all) for others ;) However, Rust's potential syntax issues arise from the fact that they try to express complex concepts within a limited set of characters (and it's a problem any sufficiently complex language will face), so of course people will complain :)
- catnaroek 9y ago
  Weird, for me it is exactly the other way around. The syntax might be familiar, but it is idiotic. On the other hand, the semantics is exactly what I have always wanted C++ to be.