5 ms·

I'm a network engineer, and I've done C++ for over a decade now. One of the nice things about Rust is that they decided to go with async over fibers, which is i

I'm a network engineer, and I've done C++ for over a decade now. One of the nice things about Rust is that they decided to go with async over fibers, which is in line with how most high performance C++ is written. The Rust team also isn't rushing Future out the door, so it's coming along much nicer than the C++ Future, which is usually replaced because it's not monadic. Rust is great, and I highly recommend learning Rust if you want to become a better C++ developer. C++ introduces a lot of unnecessary headaches Rust completely solves. Rust is worth the switch if only because reading error messages from expanded templates is horrible compared to type system that actually understands type parameters. I'm really bullish on Rust becoming even more mainstream, to the point anyone can pick it up and use it in their business without a second thought by 2020.

f2f 8y ago
i admire you: you change your occupation every couple of days, as well as the languages you've replaced rust for :)
- daboross 8y ago
  Could you site this? I've looked at ilovecaching's comment history (at least up to ~60 days ago) and they seem consistent on being a networking programmer who uses C++. Was there a particular comment you found which would indicate this isn't the truth?
  - f2f 8y ago
    nb: you mean "cite". why would you make me do this? you can doxx people on your own dime... still, for posterity: https://news.ycombinator.com/item?id=18328964 https://news.ycombinator.com/item?id=18328964 "...now I am working full time as a Rust developer" https://news.ycombinator.com/item?id=18310666 https://news.ycombinator.com/item?id=18310666 "As a long time Erlang developer..." https://news.ycombinator.com/item?id=18265199 https://news.ycombinator.com/item?id=18265199 "As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust." https://news.ycombinator.com/item?id=18251478 https://news.ycombinator.com/item?id=18251478 "Becoming a professional Haskell and Erlang developer really shifted my view on OOP" https://news.ycombinator.com/item?id=18185795 https://news.ycombinator.com/item?id=18185795 "I've been using Rust in production for a little over half a year, and my team and I have run into very few issues. [...] We're all extremely glad we chucked C++ and Go and switched to Rust. " https://news.ycombinator.com/item?id=18171917 https://news.ycombinator.com/item?id=18171917 "I am exclusively using Go and Rust at home and at work, and I find myself equally productive in both." you get the point.
    - siegfried-en 8y ago
      You have a point, but he never said he programmed exclusively in C++, so I don’t really see the issue here...
    - faitswulff 8y ago
      A couple languages doesn't seem beyond the realm of possibility for one engineer to be familiar with, though?
    - moosingin3space 8y ago
      It really isn't that ridiculous that someone who has worked as a network engineer for a decade would use Erlang, C++, and Go. Even Haskell isn't too much of a stretch, considering the user's company has functional programming expertise in Erlang. Rust is a neat language that, depending on their workload, could replace all of those languages. Why the presumption of bad faith?
    - TheCoelacanth 8y ago
      Not seeing any major inconsistencies. Three months ago they exclusively used Go and Rust, at some point before that they used Erlang and Haskell and they used C++ for a total of over 10 years.
    - mquander 8y ago
      I guess I'm glad that someone sits around looking through comment histories skeptically, but I don't see what about these comments seem suspicious to you.
    - fxfan 8y ago
      I think what you're posting definitely sounds suspicious and a lot of rust users are doing it for the hype but. 1) rust genuinely is a great language and his opinion in the comment is something I have as a professional c++ programmer or the past 2) his comment history is only suspicious and only mildly, there's nothing outright contradictory. I would give him the benefit of doubt.
    - atombender 8y ago
      Talk about cherry-picking. It's pretty clear from those comments that they've worked with Erlang before, as well as Haskell and C++, and that they've transitioned to use Rust. For example, in the same comment that begins with "As a long time Erlang developer", they later continue: "I’m more optimistic about Rust ... We’ve been able to scale Rust to handle the same load as our Erlang cluster". So there's no contradiction here.
skyde 8y ago
I am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go. I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature. Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it still polute your method signature and make the debugger and stacktrace useless. Also you still have to think about trying to no make anything that could block spinlock or calling api that are not Async ex: Createfile Compare this to Golang where project like Groupcache (1) have super clean code that replaced a thousand line of code C++ system at google. Why do you think Golang fiber/gorotine are worse ? (1) https://github.com/golang/groupcache https://github.com/golang/groupcache
- pcwalton 8y ago
  Goroutines are just threads, with a particularly idiosyncratic implementation. You can use threads and blocking I/O in Rust too. You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason.
  - comex 8y ago
    > You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason. Depends on how many threads you have and what OS you’re running on.
  - skyde 8y ago
    Goroutine are very different from thread in practice. you don’t have to pay the memory usage and context switch cost you would have if using large amounts of threads. It’s also faster to do IO processing from a single thread in batch instead of having one OS thread per request.
    - pcwalton 8y ago
      Context switches on I/O are the same for 1:1 and M:N because you're eating the cost of a kernel to user context switch either way. Memory usage per thread is a property of the GC, not M:N threading. You can have very small stacks in a 1:1 implementation too.

f2f 8y ago

i admire you: you change your occupation every couple of days, as well as the languages you've replaced rust for :)

daboross 8y ago
Could you site this? I've looked at ilovecaching's comment history (at least up to ~60 days ago) and they seem consistent on being a networking programmer who uses C++. Was there a particular comment you found which would indicate this isn't the truth?
- f2f 8y ago
  nb: you mean "cite". why would you make me do this? you can doxx people on your own dime... still, for posterity: https://news.ycombinator.com/item?id=18328964 https://news.ycombinator.com/item?id=18328964 "...now I am working full time as a Rust developer" https://news.ycombinator.com/item?id=18310666 https://news.ycombinator.com/item?id=18310666 "As a long time Erlang developer..." https://news.ycombinator.com/item?id=18265199 https://news.ycombinator.com/item?id=18265199 "As someone who has worked two jobs now writing, deploying, and operating Erlang clusters, I recommend switching to Rust." https://news.ycombinator.com/item?id=18251478 https://news.ycombinator.com/item?id=18251478 "Becoming a professional Haskell and Erlang developer really shifted my view on OOP" https://news.ycombinator.com/item?id=18185795 https://news.ycombinator.com/item?id=18185795 "I've been using Rust in production for a little over half a year, and my team and I have run into very few issues. [...] We're all extremely glad we chucked C++ and Go and switched to Rust. " https://news.ycombinator.com/item?id=18171917 https://news.ycombinator.com/item?id=18171917 "I am exclusively using Go and Rust at home and at work, and I find myself equally productive in both." you get the point.
  - siegfried-en 8y ago
    You have a point, but he never said he programmed exclusively in C++, so I don’t really see the issue here...
  - faitswulff 8y ago
    A couple languages doesn't seem beyond the realm of possibility for one engineer to be familiar with, though?
  - moosingin3space 8y ago
    It really isn't that ridiculous that someone who has worked as a network engineer for a decade would use Erlang, C++, and Go. Even Haskell isn't too much of a stretch, considering the user's company has functional programming expertise in Erlang. Rust is a neat language that, depending on their workload, could replace all of those languages. Why the presumption of bad faith?
  - TheCoelacanth 8y ago
    Not seeing any major inconsistencies. Three months ago they exclusively used Go and Rust, at some point before that they used Erlang and Haskell and they used C++ for a total of over 10 years.
  - mquander 8y ago
    I guess I'm glad that someone sits around looking through comment histories skeptically, but I don't see what about these comments seem suspicious to you.
  - fxfan 8y ago
    I think what you're posting definitely sounds suspicious and a lot of rust users are doing it for the hype but. 1) rust genuinely is a great language and his opinion in the comment is something I have as a professional c++ programmer or the past 2) his comment history is only suspicious and only mildly, there's nothing outright contradictory. I would give him the benefit of doubt.
  - atombender 8y ago
    Talk about cherry-picking. It's pretty clear from those comments that they've worked with Erlang before, as well as Haskell and C++, and that they've transitioned to use Rust. For example, in the same comment that begins with "As a long time Erlang developer", they later continue: "I’m more optimistic about Rust ... We’ve been able to scale Rust to handle the same load as our Erlang cluster". So there's no contradiction here.

skyde 8y ago

I am a big fan of rust but I don’t think the Async using the ”await” keyword or using Future/promis is the way to go. I wrote a large web app in scala using Futur only and it turned into a monster because of it. Even if you don’t use callback you still need to manualy unwrap them and they pollute your méthode signature. Then more recently I wrote a pub/sub server in c# using the “await” keyword. While much better it still polute your method signature and make the debugger and stacktrace useless. Also you still have to think about trying to no make anything that could block spinlock or calling api that are not Async ex: Createfile Compare this to Golang where project like Groupcache (1) have super clean code that replaced a thousand line of code C++ system at google. Why do you think Golang fiber/gorotine are worse ? (1) https://github.com/golang/groupcache https://github.com/golang/groupcache

pcwalton 8y ago
Goroutines are just threads, with a particularly idiosyncratic implementation. You can use threads and blocking I/O in Rust too. You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason.
- comex 8y ago
  > You wouldn't want a Go-like M:N solution in Rust. It would be slower for no reason. Depends on how many threads you have and what OS you’re running on.
- skyde 8y ago
  Goroutine are very different from thread in practice. you don’t have to pay the memory usage and context switch cost you would have if using large amounts of threads. It’s also faster to do IO processing from a single thread in batch instead of having one OS thread per request.
  - pcwalton 8y ago
    Context switches on I/O are the same for 1:1 and M:N because you're eating the cost of a kernel to user context switch either way. Memory usage per thread is a property of the GC, not M:N threading. You can have very small stacks in a 1:1 implementation too.