5 ms·

I really, really like Rust. Yet, I use Go. This is mainly do to firstly, Go just fits way way better for my shop. The transition from my fellow employees from

I really, really like Rust. Yet, I use Go. This is mainly do to firstly, Go just fits way way better for my shop. The transition from my fellow employees from Python to Go is pretty straight forward. Secondly, Go is just nicely setup for ease. I had so much hell in Rust cross compiling a simple https server.. it was mind numbing. It might be better now, but I was shocked at how difficult it was. Finally, Go is just more nice to write in when you're.. well, writing it out. I guess I tend to write as I think about data structures, abstractions, general design. I don't draw it ahead of time or w/e, I just write code. Go is very minimal, and is pretty forgiving to quick rewrites/etc. In Rust I found myself writing myself into a corner constantly when all I was trying to do was get an idea out of my head. With that said, I vastly preferred Rust's feeling of knowing exactly what my program is doing. No question on if something is nil or not, you know it is or isn't (or know it's unknown haha). I think for me, in another 2 years I'll push again for Rust > Go in my shop as I imagine the Rust tooling will have improved to the point where it's easier and more quick to write things. Rust was experiencing a lot of cargo package churn, I spent hours debugging which packages worked together, it was a headache. Even understanding errors was a bit of a headache, despite the compiler trying really hard. Rust is making great strides though, and even though I use Go to get shit done, Rust is probably my favorite language.. that I don't use heh. edit: Oh yea, and green threads, god do I wish Rust had green threads. I found Rust to be similar to Go in multithreading ergonomics, but I couldn't use them in the same manner as with Go - ie, fire off as many as I want. There are several libraries in development that should take care of this though, I believe.

vanderZwan 8y ago
> Oh yea, and green threads, god do I wish Rust had green threads. They still don't? I thought they were working on that years ago, no?
- notheguyouthink 8y ago
  They had green threads, but removed it. To my knowledge, there are multiple libraries that effectively implement green threads, but it's still a work in progress. Might be production ready, not sure, but I believe at the very least the ergonomics are a work in progress.
  - vanderZwan 8y ago
    Hmm, sounds like the kind of thing that is hard to get right then. Maybe it's for the best that it isn't in the standard library until the design and implementation stabilises then. Sucks for early adopters though!
    - vertex-four 8y ago
      I doubt Rust will ever get green threads - it turns out that OS threads are good enough, and futures (async/await) is how IO will get dealt with at scale. Green threads don’t help compute-bound code, so with a solution in place for IO, they’re unnecessary.
      - steveklabnik 8y ago
        It's quite unlikely that Rust the language will get green threads, yes. We are getting stackless couroutines ("generators"), which are related but not the same thing. There's a ton of options in this space, and they're all slightly different, with different tradeoffs, so it's really hard to make good comparisons. You have to deeply understand exactly what each language is doing.
- steveklabnik 8y ago
  1. long ago, we used to have green threads and a runtime 2. we decided to eschew the runtime, and therefore, the green threads. 3. Since then, various libraries have implemented green threads in various ways 4. Tokio is basically green threads today. It really depends on what you mean exactly by "green threads".; but it schedules N tasks on M OS threads, so...
  - vanderZwan 8y ago
    Thank you for clarifying! > 2. we decided to eschew the runtime, and therefore, the green threads. The most important bit I guess, regarding the question of whether Rust will ever have green threads/fibers/trails/whatever (answer: no, because no runtime).
    - steveklabnik 8y ago
      Not built into Rust, yes. But since Rust has no runtime, if you want those things, you can bring them along, as a library. The danger there is splitting an ecosystem, but in general the community has been sensitive to this, and once Tokio was determined as the way forward, the other projects stopped to throw their weight behind it too.
pcwalton 8y ago
Did you try to spawn lots of threads? OS threads scale better than you'd think.
forgot-my-pw 8y ago
Right tool for the right job.

vanderZwan 8y ago

> Oh yea, and green threads, god do I wish Rust had green threads. They still don't? I thought they were working on that years ago, no?

notheguyouthink 8y ago
They had green threads, but removed it. To my knowledge, there are multiple libraries that effectively implement green threads, but it's still a work in progress. Might be production ready, not sure, but I believe at the very least the ergonomics are a work in progress.
- vanderZwan 8y ago
  Hmm, sounds like the kind of thing that is hard to get right then. Maybe it's for the best that it isn't in the standard library until the design and implementation stabilises then. Sucks for early adopters though!
  - vertex-four 8y ago
    I doubt Rust will ever get green threads - it turns out that OS threads are good enough, and futures (async/await) is how IO will get dealt with at scale. Green threads don’t help compute-bound code, so with a solution in place for IO, they’re unnecessary.
    - steveklabnik 8y ago
      It's quite unlikely that Rust the language will get green threads, yes. We are getting stackless couroutines ("generators"), which are related but not the same thing. There's a ton of options in this space, and they're all slightly different, with different tradeoffs, so it's really hard to make good comparisons. You have to deeply understand exactly what each language is doing.
steveklabnik 8y ago
1. long ago, we used to have green threads and a runtime 2. we decided to eschew the runtime, and therefore, the green threads. 3. Since then, various libraries have implemented green threads in various ways 4. Tokio is basically green threads today. It really depends on what you mean exactly by "green threads".; but it schedules N tasks on M OS threads, so...
- vanderZwan 8y ago
  Thank you for clarifying! > 2. we decided to eschew the runtime, and therefore, the green threads. The most important bit I guess, regarding the question of whether Rust will ever have green threads/fibers/trails/whatever (answer: no, because no runtime).
  - steveklabnik 8y ago
    Not built into Rust, yes. But since Rust has no runtime, if you want those things, you can bring them along, as a library. The danger there is splitting an ecosystem, but in general the community has been sensitive to this, and once Tokio was determined as the way forward, the other projects stopped to throw their weight behind it too.

pcwalton 8y ago

Did you try to spawn lots of threads? OS threads scale better than you'd think.

forgot-my-pw 8y ago

Right tool for the right job.