14 ms·

So, I've been eyeing Rust for a while and have messed around with it a bit in my free time. Here are some things I'd want to know before trying it out on a lar

So, I've been eyeing Rust for a while and have messed around with it a bit in my free time. Here are some things I'd want to know before trying it out on a large project: 1. What development environment are other developers using with very large code bases? Is the tooling responsive? 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? 3. Most of the code I write is in F#. The nice thing is, there is basically .NET library for everything under the sun. For example, over the weekend I was looking for a library that could decode OBD-II data from a car, and with a quick DuckDuckGo search I was able to find three or four. In a large-ish project, how often do Rust users typically find themselves coming up short for that kind of stuff? Obviously it varies a ton by domain, but maybe someone could tell me whether the answer is "you'll probably write all wrappers for 3rd party APIs yourself" or "there's a decent chance there's a library out there that you can adapt."

steveklabnik 9y ago
1. I personally use VS: Code and Vim. IntelliJ has an officially supported plugin that I haven't used, but heard good things about it. The Eclipse project is considering making a Rust IDE but hasn't decided yet. VS non-Code should work now, but I haven't given it a go personally. On the "responsive" question, it's still actively being worked on, generally, so "it depends". We're actively investing in things being more robust. 2. We expect async/await to be stable before August, but as always, It Depends. 3. As you say, varies a ton by domain :) What I will say is, two years ago, crates.io had ~3000 packages, last year, 7500, today, almost 14,000. So we're getting there...
- Q6T46nT668w6i3m 9y ago
  Steve, just so you know (for future answers), the IntelliJ plug-in is stupidly good considering its relative newness. You shouldn’t hesitate to recommend to existing IntelliJ users. :D
  - steveklabnik 9y ago
    Understood :) I usually try to be really clear about what my opinion is based on, especially when it's second-hand, like with IntelliJ. Have you tried debugging with CLion? I don't own a license so I haven't tried myself.
    - mjal 9y ago
      CLion debugging works pretty well for most cases, though there are some small issues every so often. I always make sure to report them to the appropriate place if they're not known already, though.
      - steveklabnik 9y ago
        Great, thanks!
Q6T46nT668w6i3m 9y ago
> 1. What development environment are other developers using with very large code bases? Is the tooling responsive? It’s solid. If you’re coming from Visual Studio, you’ll dig IntelliJ with the Rust plug-in. > 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? It’s painful. I don’t know if there’s a timeline. But I’m positive someone can say more. Edit: See Steve's response. He would know. > 3. Most of the code I write is in F#. The nice thing is, there is basically .NET library for everything under the sun. For example, over the weekend I was looking for a library that could decode OBD-II data from a car, and with a quick DuckDuckGo search I was able to find three or four. In a large-ish project, how often do Rust users typically find themselves coming up short for that kind of stuff? Obviously it varies a ton by domain, but maybe someone could tell me whether the answer is "you'll probably write all wrappers for 3rd party APIs yourself" or "there's a decent chance there's a library out there that you can adapt." If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. If you’re expecting the Python ecosystem, you’ll need to wait (or contribute back).
- mercurial 9y ago
  > If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. Not even close (100k unique packages on nuget, 13k crates on crates.io). On the other hand, you have easy interop with C (which doesn't give you stuff like safety, idiomatic error handling or nice APIs, but it's occasionally better than coding it yourself).
  - kbenson 9y ago
    It's not about total packages, but about quality of packages and whether they provide good coverage of most problem spaces. NPM claims to have close to 500k packages. Should we assume it solves 5x the problems that the .NET ecosystem does, that that perhaps by the 50th implementation of leftpad, there's some cruft on there? That's not to say that Rust's package ecosystem is large enough or sufficient in comparison to .NET, just that raw package count gets to be an extremely poor indicator of quality after a certain level has been reached. As a point of reference, I approach this from Perl and CPAN, which is one of the oldest large fully featured package networks. At this point, the problem is usually not finding a package that provides a solution, but finding the right package out of what's available. Different solutions exist, but a good curated list of well implemented solutions to common needs can help quite a bit.[1] 1: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho
notheguyouthink 9y ago
> Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? Can someone explain to me what async/await is, in the context of a language like Go? I've used Rust a fair amount, but Go has been my native language for ~5 years now. With that said, aren't both languages synchronous languages where you can drop into another thread (or green thread) whenever you want? What UX is improved by async/await? Eg, in Go I never felt the need for async/await (as I've used in JavaScript at least). If anything, Go's is better than async/await to me, because if I call `foo := bar()`, I don't have to know if `bar()` is an asynchronous function.. it just works. Is there something missing there? Again, I use Rust and Go similarly in this post because Go is my frame of reference. I thought they were the same on this front, though. No? What's missing here? What am I missing here?
- chatmasta 9y ago
  Async/await makes sense in python or JavaScript because it’s syntactical sugar that improves readability/maintainability and mitigates against concurrency errors stemming from the event loop (JS) or the GIL (python). I haven’t worked with Go beyond playing with it a bit, but it seems async/await would be utterly useless in Go since goroutines already accomplish the same thing in a much more performant manner.
  - eropple 9y ago
    C# was, as far as I'm aware, the first major language to implement async/await atop of Task<T> (akin to Java's Future<T>). The CLR uses native threads. Go channels are also orthogonal to async/await. Message passing is not a substitute for futures/tasks, though it can be used to achieve similar goals. I would be extremely cautious about claiming that Go channels would be "more performant" than an otherwise-equivalent futures implementation, too.
    - wahern 9y ago
      Goroutines are not the same thing as Go channels.
cpursley 9y ago
Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.
- jacquesm 9y ago
  The microcontroller component of that is going to be a walk in the park compared to the radio component.
  - NegativeLatency 9y ago
    Wifi with good antennas, or a cellular hotspot seems pretty easy.
    - jacquesm 9y ago
      Race engines are not known for their lack of EM emissions :) Vehicles are not friendly environments to begin with, race cars are outright hostile territory. Vibration & G forces, interference, fluctuating power, huge temperature variation, aerodynamic effects on antenna and cabling are all factors that will make this quite a bit of work to get to acceptable reliability levels. I like your idea of a cellular hotspot, that might be the easiest way to get to something that works. Compact, no external cabling. That's good. Edit: I tried running a webcam in a racecar in the mid 90's but it never got beyond the planning stage before the obstacles became insurmountable for the budget available, now, obviously a lot has happened in those years and F1 and other racing sports prove on a daily basis that the bandwidth is definitely there if you have the budget, you make me wonder how easy it would be to pull this off today, mostly likely you could just plug it together from some consumer components, a small tablet with a SIM card in a waterproof and vibration isolated enclosure would probably get you 90% there.
- Nelkins 9y ago
  Right now I just want to get more fine-grained data about my mileage. But maybe add some automation into the mix later on (remote start, etc.).
shpongled 9y ago
1. VS Code with the Rust plugin along with rustfmt and the rls is great - when it works. I've had some issues now and then, but the tooling is pretty great. 2. Not qualified to answer this 3. There's a ton of rust libraries out there. The whole cargo ecosystem is quite nice. Coming from a C background (and dabbling in lisp), I love Rust. It's C with batteries and concepts from functional programming - iterators, immutable data. The only times I've struggled with rust is when trying to mess with pointer arithmetic and evading memory safety (e.g. trying to program a garbage collector for a Lisp interpreter)
- bomb199 9y ago
  I've been using VS Code and WLS to execute the Ubuntu version of Rust from the bash console in VS Code. I'm not sure if this is a good method or not... but it feels very natural.
egnehots 9y ago
IntelliJ and a workspace based project will get you a modern IDE experience. However don't expect a responsive edit/compile cycle, compilation times just doesn't scale for large projects, even with incremental compilation. Linking against shared libraries for stable dependencies can help though. No the ecosystem is not mature enough to get the "enterprise" libraries. Wrappers to c/c++ libraries are often needed.
disordinary 9y ago
I just switched from VS Code to InteliJ and it's great. There's been huge improvements in IDE support recently.
- Inityx 9y ago
  Can you elaborate on the differences you've seen between VS Code + RLS and IntelliJ?
  - disordinary 9y ago
    Sure, VS Code keeps randomly asking me to choose my toolchain even though a toolchain is chosen, closing it down and re-opening it fixes that. InteliJ seems a little snappier, it's code completion a bit better. The biggest benefit in day to day usage is the inline type hinting.
coldtea 9y ago
>2. Using a language for a large project without some kind of async/await notation seems painful And yet most of the software we use, billions of lines of code, from Chrome to Linux, from Photoshop to bind, and from Nginx to Skype, has been created without such notation. Somehow we've managed.
- naasking 9y ago
  "Managed" and "seems painful" don't disagree with each other.
  - tytytytytytytyt 9y ago
    That doesn't make the assertion that you need async notation for any large project to not be painful any less ridiculous.
    - Nelkins 9y ago
      Of course you don't NEED it. It's just that I've become accustomed to the bells and whistles (and accompanying productivity) of a modern programming language. If I'm considering a new programming language I'd like the feature set to be comparable.
spease 9y ago
Nightly rust can use this async / await crate, but it will likely be deprecated once language support is available (later this year iirc) https://github.com/alexcrichton/futures-await/blob/master/README.md https://github.com/alexcrichton/futures-await/blob/master/RE...

steveklabnik 9y ago

1. I personally use VS: Code and Vim. IntelliJ has an officially supported plugin that I haven't used, but heard good things about it. The Eclipse project is considering making a Rust IDE but hasn't decided yet. VS non-Code should work now, but I haven't given it a go personally. On the "responsive" question, it's still actively being worked on, generally, so "it depends". We're actively investing in things being more robust. 2. We expect async/await to be stable before August, but as always, It Depends. 3. As you say, varies a ton by domain :) What I will say is, two years ago, crates.io had ~3000 packages, last year, 7500, today, almost 14,000. So we're getting there...

Q6T46nT668w6i3m 9y ago
Steve, just so you know (for future answers), the IntelliJ plug-in is stupidly good considering its relative newness. You shouldn’t hesitate to recommend to existing IntelliJ users. :D
- steveklabnik 9y ago
  Understood :) I usually try to be really clear about what my opinion is based on, especially when it's second-hand, like with IntelliJ. Have you tried debugging with CLion? I don't own a license so I haven't tried myself.
  - mjal 9y ago
    CLion debugging works pretty well for most cases, though there are some small issues every so often. I always make sure to report them to the appropriate place if they're not known already, though.
    - steveklabnik 9y ago
      Great, thanks!

Q6T46nT668w6i3m 9y ago

> 1. What development environment are other developers using with very large code bases? Is the tooling responsive? It’s solid. If you’re coming from Visual Studio, you’ll dig IntelliJ with the Rust plug-in. > 2. Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? It’s painful. I don’t know if there’s a timeline. But I’m positive someone can say more. Edit: See Steve's response. He would know. > 3. Most of the code I write is in F#. The nice thing is, there is basically .NET library for everything under the sun. For example, over the weekend I was looking for a library that could decode OBD-II data from a car, and with a quick DuckDuckGo search I was able to find three or four. In a large-ish project, how often do Rust users typically find themselves coming up short for that kind of stuff? Obviously it varies a ton by domain, but maybe someone could tell me whether the answer is "you'll probably write all wrappers for 3rd party APIs yourself" or "there's a decent chance there's a library out there that you can adapt." If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. If you’re expecting the Python ecosystem, you’ll need to wait (or contribute back).

mercurial 9y ago
> If you’re expecting the F# (and .NET) ecosystem, you’ll likely be satisfied. In fact, it might be better. Not even close (100k unique packages on nuget, 13k crates on crates.io). On the other hand, you have easy interop with C (which doesn't give you stuff like safety, idiomatic error handling or nice APIs, but it's occasionally better than coding it yourself).
- kbenson 9y ago
  It's not about total packages, but about quality of packages and whether they provide good coverage of most problem spaces. NPM claims to have close to 500k packages. Should we assume it solves 5x the problems that the .NET ecosystem does, that that perhaps by the 50th implementation of leftpad, there's some cruft on there? That's not to say that Rust's package ecosystem is large enough or sufficient in comparison to .NET, just that raw package count gets to be an extremely poor indicator of quality after a certain level has been reached. As a point of reference, I approach this from Perl and CPAN, which is one of the oldest large fully featured package networks. At this point, the problem is usually not finding a package that provides a solution, but finding the right package out of what's available. Different solutions exist, but a good curated list of well implemented solutions to common needs can help quite a bit.[1] 1: https://metacpan.org/pod/Task::Kensho https://metacpan.org/pod/Task::Kensho

notheguyouthink 9y ago

> Using a language for a large project without some kind of async/await notation seems painful. How bad is it using only combinators for async (assuming you want to stay on stable)? And is there a date yet when async/await will be stabilized? Can someone explain to me what async/await is, in the context of a language like Go? I've used Rust a fair amount, but Go has been my native language for ~5 years now. With that said, aren't both languages synchronous languages where you can drop into another thread (or green thread) whenever you want? What UX is improved by async/await? Eg, in Go I never felt the need for async/await (as I've used in JavaScript at least). If anything, Go's is better than async/await to me, because if I call `foo := bar()`, I don't have to know if `bar()` is an asynchronous function.. it just works. Is there something missing there? Again, I use Rust and Go similarly in this post because Go is my frame of reference. I thought they were the same on this front, though. No? What's missing here? What am I missing here?

chatmasta 9y ago
Async/await makes sense in python or JavaScript because it’s syntactical sugar that improves readability/maintainability and mitigates against concurrency errors stemming from the event loop (JS) or the GIL (python). I haven’t worked with Go beyond playing with it a bit, but it seems async/await would be utterly useless in Go since goroutines already accomplish the same thing in a much more performant manner.
- eropple 9y ago
  C# was, as far as I'm aware, the first major language to implement async/await atop of Task<T> (akin to Java's Future<T>). The CLR uses native threads. Go channels are also orthogonal to async/await. Message passing is not a substitute for futures/tasks, though it can be used to achieve similar goals. I would be extremely cautious about claiming that Go channels would be "more performant" than an otherwise-equivalent futures implementation, too.
  - wahern 9y ago
    Goroutines are not the same thing as Go channels.

cpursley 9y ago

Neat, what is your use-case for OBD-II data? I've been investigating ways to get data from a race car back to the pit crew via something like a raspberry pi.

jacquesm 9y ago
The microcontroller component of that is going to be a walk in the park compared to the radio component.
- NegativeLatency 9y ago
  Wifi with good antennas, or a cellular hotspot seems pretty easy.
  - jacquesm 9y ago
    Race engines are not known for their lack of EM emissions :) Vehicles are not friendly environments to begin with, race cars are outright hostile territory. Vibration & G forces, interference, fluctuating power, huge temperature variation, aerodynamic effects on antenna and cabling are all factors that will make this quite a bit of work to get to acceptable reliability levels. I like your idea of a cellular hotspot, that might be the easiest way to get to something that works. Compact, no external cabling. That's good. Edit: I tried running a webcam in a racecar in the mid 90's but it never got beyond the planning stage before the obstacles became insurmountable for the budget available, now, obviously a lot has happened in those years and F1 and other racing sports prove on a daily basis that the bandwidth is definitely there if you have the budget, you make me wonder how easy it would be to pull this off today, mostly likely you could just plug it together from some consumer components, a small tablet with a SIM card in a waterproof and vibration isolated enclosure would probably get you 90% there.
Nelkins 9y ago
Right now I just want to get more fine-grained data about my mileage. But maybe add some automation into the mix later on (remote start, etc.).

shpongled 9y ago

1. VS Code with the Rust plugin along with rustfmt and the rls is great - when it works. I've had some issues now and then, but the tooling is pretty great. 2. Not qualified to answer this 3. There's a ton of rust libraries out there. The whole cargo ecosystem is quite nice. Coming from a C background (and dabbling in lisp), I love Rust. It's C with batteries and concepts from functional programming - iterators, immutable data. The only times I've struggled with rust is when trying to mess with pointer arithmetic and evading memory safety (e.g. trying to program a garbage collector for a Lisp interpreter)

bomb199 9y ago
I've been using VS Code and WLS to execute the Ubuntu version of Rust from the bash console in VS Code. I'm not sure if this is a good method or not... but it feels very natural.

egnehots 9y ago

IntelliJ and a workspace based project will get you a modern IDE experience. However don't expect a responsive edit/compile cycle, compilation times just doesn't scale for large projects, even with incremental compilation. Linking against shared libraries for stable dependencies can help though. No the ecosystem is not mature enough to get the "enterprise" libraries. Wrappers to c/c++ libraries are often needed.

disordinary 9y ago

I just switched from VS Code to InteliJ and it's great. There's been huge improvements in IDE support recently.

Inityx 9y ago
Can you elaborate on the differences you've seen between VS Code + RLS and IntelliJ?
- disordinary 9y ago
  Sure, VS Code keeps randomly asking me to choose my toolchain even though a toolchain is chosen, closing it down and re-opening it fixes that. InteliJ seems a little snappier, it's code completion a bit better. The biggest benefit in day to day usage is the inline type hinting.

coldtea 9y ago

>2. Using a language for a large project without some kind of async/await notation seems painful And yet most of the software we use, billions of lines of code, from Chrome to Linux, from Photoshop to bind, and from Nginx to Skype, has been created without such notation. Somehow we've managed.

naasking 9y ago
"Managed" and "seems painful" don't disagree with each other.
- tytytytytytytyt 9y ago
  That doesn't make the assertion that you need async notation for any large project to not be painful any less ridiculous.
  - Nelkins 9y ago
    Of course you don't NEED it. It's just that I've become accustomed to the bells and whistles (and accompanying productivity) of a modern programming language. If I'm considering a new programming language I'd like the feature set to be comparable.

spease 9y ago

Nightly rust can use this async / await crate, but it will likely be deprecated once language support is available (later this year iirc) https://github.com/alexcrichton/futures-await/blob/master/README.md https://github.com/alexcrichton/futures-await/blob/master/RE...