Rust 2018 survey results(blog.rust-lang.org)
blog.rust-lang.org
Rust 2018 survey results
https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html
197 comments
>It seems to exclude the possibility of women who don't identify as belonging to an underrepresented group.
Absolutely. If I had taken this survey, I wouldn't have checked "I feel underrepresented because I'm gay" because... well, it's literally never been an issue. In that sense, why would I care if I'm the only gay guy in a team of a million programmers? They all treat me just fine. Must I be "represented"?
I can imagine the numbers, for that reason, simply won't reflect the number of non-heterosexual people. It could be higher.
Absolutely. If I had taken this survey, I wouldn't have checked "I feel underrepresented because I'm gay" because... well, it's literally never been an issue. In that sense, why would I care if I'm the only gay guy in a team of a million programmers? They all treat me just fine. Must I be "represented"?
I can imagine the numbers, for that reason, simply won't reflect the number of non-heterosexual people. It could be higher.
Yes, they used "_do you consider yourself_ underrepresented". And there's also the implicit "and _do you feel like this matters_ for this survey". Some people may feel underrepresented but don't feel like this should matter on this survey, so they'd be likely to answer "No".
So a decrease in the "underrepresented" statistics doesn't necessarily mean it's dealing with the actual situation.. It wouldn't necessarily imply anything "bad" or "undesired".
So a decrease in the "underrepresented" statistics doesn't necessarily mean it's dealing with the actual situation.. It wouldn't necessarily imply anything "bad" or "undesired".
And this is why every survey I've ever taken has pissed me off and now I don't take them at all. I've never felt that the information gleaned from a survey was honestly useful for making decisions.
This is typical of political surveys and other surveys where there is a "preferrable" outcome, but I don't think in this case they are trying to get a specific outcome. Maybe feedback can make subsequent surveys better and reduce the ambiguity of results.
It's typical of all surveys. You either need to go into extensive detail to remove the ambiguity of the questions, or you need to allow people to state what they think in plain language. Taking surveys to gather information is like using record sales to measure what kind of music is best; there are a billion confounding factors and none of them are covered by the abjectly simple metric used.
> as the number of women is still lower than the industry average of women in programming fields
I think averages shouldn't be goals by themselves. And there's no good reason on why should Rust approach this Hypothetical Average, since Rust Lang != Hypothetical Average Lang.
I mean that I guess being closer to this hyp. avg. doesn't make it "better", whatever that means..
I think averages shouldn't be goals by themselves. And there's no good reason on why should Rust approach this Hypothetical Average, since Rust Lang != Hypothetical Average Lang.
I mean that I guess being closer to this hyp. avg. doesn't make it "better", whatever that means..
It was a bit weird to me as well. There's like 7.x% of gay people which would leave 0.4% for non-gay people that feel that they belong to some kind of minority. It makes gay people look like having a ton of issues at once and I can't imagine that's true.
Or is it: "Yes I'm a woman, but I don't feel underrepresented"?
Or is it: "Yes I'm a woman, but I don't feel underrepresented"?
Women are definitely underrepresented in technology relative to their representation in the human population at large. LGBT are not underrepresented in my experience. If anything, a higher percentage of technologists are LGBT vs. the general population.
I'm not sure what population the survey intends to look at; it's not Rust users because 25% of respondents aren't using it (per the first question). We don't know how the survey was conducted. We don't know if women or others are overrepresented or underrepresented in the results - and that's relative to an undefined population. We know very little, and thus we can't begin to know the reasoning behind the quoted comment.
> women who don't identify as belonging to an underrepresented group
The existence of significant numbers of such people seems to be the object of much speculation on HN, possibly because it would undermine attempts to increase the representation of women. However, I have not seen evidence that such a population exists. Also, underrepresentation in this case is much more a matter of math and not one of chosen identity.
> women who don't identify as belonging to an underrepresented group
The existence of significant numbers of such people seems to be the object of much speculation on HN, possibly because it would undermine attempts to increase the representation of women. However, I have not seen evidence that such a population exists. Also, underrepresentation in this case is much more a matter of math and not one of chosen identity.
I think being a woman means (and certainly is intended to mean) you're automatically part of an under-represented group - namely, that of women. There are (far) fewer women among Rust users than in the general population, which you could say is the (a?) definition of under-represented.
The percentages can add up to >100% because you can be part of multiple groups, e.g. a gay woman.
The percentages can add up to >100% because you can be part of multiple groups, e.g. a gay woman.
1. Yes, but if the "women" stats only come from a question about self-identifying as underrepresented, your "automatically" doesn't kick in. If women don't check that box, you don't know they're there.
2. I get that, I'm just surprised it's so pronounced. With most statistical distributions, when 0 (flavours of underrepresentation) covers 92% of responses, you'd expect 1 to cover a major chunk of the remainder, and that doesn't appear to be the case here.
2. I get that, I'm just surprised it's so pronounced. With most statistical distributions, when 0 (flavours of underrepresentation) covers 92% of responses, you'd expect 1 to cover a major chunk of the remainder, and that doesn't appear to be the case here.
Can someone explain to me what a good use-case for Rust would be? I mean, why would I pick it over C#/Go/Python for web development? Does it only outperform them, or is it also a pleasant language to use?
I think the consensus among Rustaceans is that using Rust for web development today is an...aggressive choice. Especially with async/await not yet stabilized. I think most of the people doing it either have very specific requirements (wasm experiments maybe) or do it because it's fun to be on the ground floor of a new thing.
That said, I find Rust very pleasant to use. I don't have to make as many defensive copies of things or reach for as many immutable data structures, because I have much stronger guarantees around what code is allowed to mutate what data. I'm a fan of static typing, and I really like that enun matches will fail to compile by default if you haven't handled all the cases. There's a lot of explicitness like that, and I find explicitness pleasant. But of course different people feel differently about that, and there's also the widely acknowledged learning curve for lifetimes and borrowing.
That said, I find Rust very pleasant to use. I don't have to make as many defensive copies of things or reach for as many immutable data structures, because I have much stronger guarantees around what code is allowed to mutate what data. I'm a fan of static typing, and I really like that enun matches will fail to compile by default if you haven't handled all the cases. There's a lot of explicitness like that, and I find explicitness pleasant. But of course different people feel differently about that, and there's also the widely acknowledged learning curve for lifetimes and borrowing.
Rust web dev-- aggressive? I struggle more with relational data modeling and refactoring my early design decisions than I struggle with Rust for web dev. I am not happy that the futures I painfully walked over hot coals to make work will be easily replaced by async/await but that's on me for not waiting until some undisclosed time in 2019 for async/await to release.
If anyone likes to compare apples with oranges and benchmarking web frameworks, actix-web framework (optimised for benchmarking, naturally) is leading in many categories: https://www.techempower.com/benchmarks/#section=data-r17&hw=...
With actix-web, you can run asyncio and sync code in the same server. It lets you take full advantage of Rust's concurrency.
If anyone likes to compare apples with oranges and benchmarking web frameworks, actix-web framework (optimised for benchmarking, naturally) is leading in many categories: https://www.techempower.com/benchmarks/#section=data-r17&hw=...
With actix-web, you can run asyncio and sync code in the same server. It lets you take full advantage of Rust's concurrency.
> I am not happy that the futures I painfully walked over hot coals to make work will be easily replaced by async/await
Glad I'm not the only one who was struggling with gigantic and confusing error messages that were fixed by trial and error (usually adding a `.map_err(|_| ())`).
Glad I'm not the only one who was struggling with gigantic and confusing error messages that were fixed by trial and error (usually adding a `.map_err(|_| ())`).
> With actix-web, you can run asyncio and sync code in the same server. It lets you take full advantage of Rust's concurrency.
Will actix-web become obsolete or be replaced when Rust releases async/await in 2019?
Will actix-web become obsolete or be replaced when Rust releases async/await in 2019?
No; async/await produces Futures, which is what actix-web uses.
It will use a slightly older futures, but that's why there's a compatibility layer, and I'm sure they'll update fairly quickly after stabilization and so you could just use that version as well.
It will use a slightly older futures, but that's why there's a compatibility layer, and I'm sure they'll update fairly quickly after stabilization and so you could just use that version as well.
Rust shines where you need robust code, speed (including reliable multicore processing, low memory usage) and possibly low-level interaction with the OS or hardware.
For me the robustness is great. It's not just memory safety, but strong type system without nulls is superb for avoiding stupid bugs (no more "undefined is not a function").
If you're writing a small blog, you probably don't need any of this — you won't hit resource limits, and you'll manage to write 100 lines properly in any language.
But if you need to process gigabytes of data, Rust may be super helpful:
https://blog.sentry.io/2016/10/19/fixing-python-performance-...
For me the robustness is great. It's not just memory safety, but strong type system without nulls is superb for avoiding stupid bugs (no more "undefined is not a function").
If you're writing a small blog, you probably don't need any of this — you won't hit resource limits, and you'll manage to write 100 lines properly in any language.
But if you need to process gigabytes of data, Rust may be super helpful:
https://blog.sentry.io/2016/10/19/fixing-python-performance-...
If I were writing a small blog today, I would probably still go with Rust, just for the robustness. Catching bugs at compile time is so much nicer no matter how good your unit test coverage is (and especially when coverage is not great).
Performance is great, but the breadth of usage enabled by the small run-time (including no GC) makes it more exciting.
Performance is great, but the breadth of usage enabled by the small run-time (including no GC) makes it more exciting.
Rust is a general purpose programming language, and as such, has a wide array of use-cases. Current production uses of Rust include:
* Extending other languages, like Ruby, Python, and JavaScript, for various tasks. Usually when performance is paramount.
* Web services (though see below)
* Infrastructure, such as Amazon's announcement today: https://news.ycombinator.com/item?id=18539539 and quite a few other things, like Chef's Habitat product, Boyant's linkerd2, Dropbox's core infrastructure, or System76's hardware flashing tooling
* Cryptocurrency stuff of various kinds
* Databases, such as PingCap's TiDB
* Operating systems, like Google's Fuchsia (This one is arguably not "production", but they are one of the largest employers of Rust programmers, and keep hiring... so maybe consider this, maybe don't.)
* Version Control systems, like Facebook's Mononoke, or the internals of mercurial itself, as well as things like Pijul
* Cryptography, in some cases working alongside C to slowly port things over
* Video games, mostly indie stuff, though some AAA studios have started to use Rust for various things, and a new studio, Embark, is going all-in
We have a partial list of companies that describe their usage here: https://www.rust-lang.org/en-US/friends.html
This year, we identified four areas we really wanted to improve Rust on:
* Embedded development
* Network services
* WebAssembly
* CLI tools
These are other common areas we see people wanting to use Rust in the near future, or areas where we could significantly improve Rust for that given case.
EDIT: I forgot to answer your other question
> Does it only outperform them, or is it also a pleasant language to use?
Performance is a key thing we hear from people in web development, but increasingly, it's also memory usage, both in amount and stability. Less memory means less money spent on servers, and steady usage makes scaling calcuations easier. For example, crates.io is a rust-based web application, and it uses about 30MB memory resident at all times, last I checked. That's very little. More serious systems use more, but often significantly less than the JVM.
* Extending other languages, like Ruby, Python, and JavaScript, for various tasks. Usually when performance is paramount.
* Web services (though see below)
* Infrastructure, such as Amazon's announcement today: https://news.ycombinator.com/item?id=18539539 and quite a few other things, like Chef's Habitat product, Boyant's linkerd2, Dropbox's core infrastructure, or System76's hardware flashing tooling
* Cryptocurrency stuff of various kinds
* Databases, such as PingCap's TiDB
* Operating systems, like Google's Fuchsia (This one is arguably not "production", but they are one of the largest employers of Rust programmers, and keep hiring... so maybe consider this, maybe don't.)
* Version Control systems, like Facebook's Mononoke, or the internals of mercurial itself, as well as things like Pijul
* Cryptography, in some cases working alongside C to slowly port things over
* Video games, mostly indie stuff, though some AAA studios have started to use Rust for various things, and a new studio, Embark, is going all-in
We have a partial list of companies that describe their usage here: https://www.rust-lang.org/en-US/friends.html
This year, we identified four areas we really wanted to improve Rust on:
* Embedded development
* Network services
* WebAssembly
* CLI tools
These are other common areas we see people wanting to use Rust in the near future, or areas where we could significantly improve Rust for that given case.
EDIT: I forgot to answer your other question
> Does it only outperform them, or is it also a pleasant language to use?
Performance is a key thing we hear from people in web development, but increasingly, it's also memory usage, both in amount and stability. Less memory means less money spent on servers, and steady usage makes scaling calcuations easier. For example, crates.io is a rust-based web application, and it uses about 30MB memory resident at all times, last I checked. That's very little. More serious systems use more, but often significantly less than the JVM.
Such a great explanation. Really going to spend some time on rust this weekend.
I had no idea rust was that prevalent
I had no idea rust was that prevalent
Thanks! There’s so much that I didn’t even cover. It’s been a great year :)
Rust is a modern, memory safe systems language. The code you write compiles to native machine which executes in a predictable way every time you run it.
If you need to write firmware for, say, a satellite, C# and Python are out because they have an intermediate step between your deployable and the machine instructions you eventually execute. You have an external dependency which adds a level of unpredictability. All three of your example languages are out because they are garbage collected languages, which makes them inherently unpredictable at runtime. The last thing you want is an OOM in the middle of a rocket engine burn.
Go and C# are competing with Python, Java, Ruby, etc. All languages you would write a web application in, but not a satellite's firmware.
Rust is competing with C and C++.
If you need to write firmware for, say, a satellite, C# and Python are out because they have an intermediate step between your deployable and the machine instructions you eventually execute. You have an external dependency which adds a level of unpredictability. All three of your example languages are out because they are garbage collected languages, which makes them inherently unpredictable at runtime. The last thing you want is an OOM in the middle of a rocket engine burn.
Go and C# are competing with Python, Java, Ruby, etc. All languages you would write a web application in, but not a satellite's firmware.
Rust is competing with C and C++.
1. You can get an OOM error (or a stack overflow) in most languages (including Rust).
2. Safety-critical hard realtime systems require far more determinism guarantees than a language/runtime alone can provide. For example, they require deterministic scheduling of threads (usually round robin with very strong prioritization guarantees and bounded task-switching latence), and so require a realtime OS. Also, safety-critical realtime systems have ways of guaranteeing bounded memory growth, for both the stack and the heap. These exist in specialized languages for realtime such as SPARK (an Ada variant) and SCADE.
3. Java is actually used in safety-critical hard realtime systems, including avionics, but in a special, hard realtime JVM that has different kinds of deterministic guarantees (when run on a realtime OS), including memory allocation, scheduling and hard deadlines for asynchronous events (see https://www.aicas.com/cms/en/rtsj). What's particularly cool about realtime Java is that it allows for a safe mix of realtime and non-realtime threads, as even in realtime systems, the actual realtime part is usually a small portion of the program.
2. Safety-critical hard realtime systems require far more determinism guarantees than a language/runtime alone can provide. For example, they require deterministic scheduling of threads (usually round robin with very strong prioritization guarantees and bounded task-switching latence), and so require a realtime OS. Also, safety-critical realtime systems have ways of guaranteeing bounded memory growth, for both the stack and the heap. These exist in specialized languages for realtime such as SPARK (an Ada variant) and SCADE.
3. Java is actually used in safety-critical hard realtime systems, including avionics, but in a special, hard realtime JVM that has different kinds of deterministic guarantees (when run on a realtime OS), including memory allocation, scheduling and hard deadlines for asynchronous events (see https://www.aicas.com/cms/en/rtsj). What's particularly cool about realtime Java is that it allows for a safe mix of realtime and non-realtime threads, as even in realtime systems, the actual realtime part is usually a small portion of the program.
Someone hasn't payed attention to the AOT compilers available for C# and Java, their widely deployment on embedded platforms, PTC, MicroEJ, Aicas, WebSphere Real Time, Android Things, wearOS, Ricoh, Cisco, Netduino, Meadow, IoT Core and many others.
Yes, maybe not on a satellite's firmware, but on a Gemalto firmware, certainly.
https://www.gemalto.com/m2m/solutions/modules-terminals/indu...
https://www.gemalto.com/m2m/solutions/modules-terminals/indu...
Just two examples from their portfolio.
Naturally it depends on how much memory is available and real time constraints.
However something like MicroEJ is already happy with an ESP32 variant, and I guess Rust could replace its C layer.
Yes, maybe not on a satellite's firmware, but on a Gemalto firmware, certainly.
https://www.gemalto.com/m2m/solutions/modules-terminals/indu...
https://www.gemalto.com/m2m/solutions/modules-terminals/indu...
Just two examples from their portfolio.
Naturally it depends on how much memory is available and real time constraints.
However something like MicroEJ is already happy with an ESP32 variant, and I guess Rust could replace its C layer.
You should think of Rust as a better systems language, a better C. This was something that Go was pitched as but as a GC language it just doesn't fit a bunch of systems applications.
What I think is driving Rust and will continue to drive Rust is how it compares to C/C++ in certain key areas:
- Ownership is enforced at compile time. C++ obviously has smart pointers now (ie std::unique_ptr and std::shared_ptr) but these come with not insignificant runtime cost. What's more you end up passing around raw pointers anyway at least some of the time.
- C/C++ do suffer from and will continue to suffer from memory corruption, buffer overruns and undefined behaviour resulting from this. This has been and will continue to be the source of security vulnerabilities.
- Security is becoming so important and software so large and complex that the need for memory safety without sacrificing runtime speed will become increasingly important.
I honestly see a point where there'll be a need for a safe OS that is written in Rust or something like it.
One other thing about Web development: I think this is one area where Rust offers no real benefits (other than memory safety). Honestly I think the best model for serving HTTP requests is the cooperative multitasking model used by Hack (FB's PHP successor) where everything the request uses and does is created and torn down within the scope of a single request. This is a model that's far easier to reason about.
I came from years of doing Java where we had to deal with full GC pauses (something Go isn't immune to either).
What I think is driving Rust and will continue to drive Rust is how it compares to C/C++ in certain key areas:
- Ownership is enforced at compile time. C++ obviously has smart pointers now (ie std::unique_ptr and std::shared_ptr) but these come with not insignificant runtime cost. What's more you end up passing around raw pointers anyway at least some of the time.
- C/C++ do suffer from and will continue to suffer from memory corruption, buffer overruns and undefined behaviour resulting from this. This has been and will continue to be the source of security vulnerabilities.
- Security is becoming so important and software so large and complex that the need for memory safety without sacrificing runtime speed will become increasingly important.
I honestly see a point where there'll be a need for a safe OS that is written in Rust or something like it.
One other thing about Web development: I think this is one area where Rust offers no real benefits (other than memory safety). Honestly I think the best model for serving HTTP requests is the cooperative multitasking model used by Hack (FB's PHP successor) where everything the request uses and does is created and torn down within the scope of a single request. This is a model that's far easier to reason about.
I came from years of doing Java where we had to deal with full GC pauses (something Go isn't immune to either).
You should think of Rust as a better systems language, a better C.
I think C++ is a more apt comparison. C is such a barebones language. Yes, it's very unsafe and Rust goes a long way to fix those issues, but Rust brings a lot of other features along with it which dial the language complexity up to 11.
I would like to see a simple language that fixes C's biggest problems. I think that would be really interesting to work with. Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
I think C++ is a more apt comparison. C is such a barebones language. Yes, it's very unsafe and Rust goes a long way to fix those issues, but Rust brings a lot of other features along with it which dial the language complexity up to 11.
I would like to see a simple language that fixes C's biggest problems. I think that would be really interesting to work with. Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
One of C's big problems is that it doesn't provide many efficient abstractions, and fixing that problem will lead you to something which is not like C for the same reasons Rust is not like C.
I agree that Rust is more like C++, especially since C++11, than it is like C. Rust has type deduction, closures, iterators, and Traits (which behave a lot like C++ class methods).
> I would like to see a simple language that fixes C's biggest problems. I think that would be really interesting to work with. Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
Honest question from an embedded C developer who's learning Rust, but still very beginner:
Wouldn't using a subset of Rust provide the same thing you're asking for?
> I would like to see a simple language that fixes C's biggest problems. I think that would be really interesting to work with. Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
Honest question from an embedded C developer who's learning Rust, but still very beginner:
Wouldn't using a subset of Rust provide the same thing you're asking for?
> Nobody seems to want to do it though, or if they have, they haven't been able to get any attention.
Cyclone, Safe C, Checked C, static analyzers deliver with the compiler, ...
The problem is on the receiving end, some devs won't change no matter what.
So far Android and Solaris (SPARC) seem to be the only platforms with memory validation compilation turned on.
Cyclone, Safe C, Checked C, static analyzers deliver with the compiler, ...
The problem is on the receiving end, some devs won't change no matter what.
So far Android and Solaris (SPARC) seem to be the only platforms with memory validation compilation turned on.
I've used it for:
* Processing 300GB of zipped text/access logs (my first attempt was in python and was much slower)
* Writing a git hook / git repo processor (again, first attempt was in python doling out to the git process alot. It was nice to compile a single binary for the hook, instead of worrying about having the correct python version installed)
* I'm writing a web service in Rust right now. It's a little rough around the edges honestly, but once async/await lands, I think I'll be much happier. The type safe templating and endpoint definitions I'm using are very nice, but probably not unique to rust. The compiler is also slow.
So probably not the best bet for webdev yet, but useful in other contexts.
* Processing 300GB of zipped text/access logs (my first attempt was in python and was much slower)
* Writing a git hook / git repo processor (again, first attempt was in python doling out to the git process alot. It was nice to compile a single binary for the hook, instead of worrying about having the correct python version installed)
* I'm writing a web service in Rust right now. It's a little rough around the edges honestly, but once async/await lands, I think I'll be much happier. The type safe templating and endpoint definitions I'm using are very nice, but probably not unique to rust. The compiler is also slow.
So probably not the best bet for webdev yet, but useful in other contexts.
> once async/await lands, I think I'll be much happier
The current futures proposal is on track for stabilization[1]. You can use futures with async/await today in nightly, and what you use will probably be exactly what lands in stable soon.
The biggest missing piece is documentation, but thats starting to improve. My go-to for examples is the futures test suite[2]. And if you want more features, futures-preview 0.3alpha adds a bunch of useful future combinators[3]. futures-preview now just wraps nightly's std::future, which is very nice.
Except for the missing documentation, rust's futures are looking great. You can have a play today if you feel keen to jump in. But, as you said it will take some time for the web development ecosystem to mature around the futures API.
[1] https://github.com/rust-lang/rfcs/pull/2592
[2] https://github.com/rust-lang-nursery/futures-rs/blob/master/...
[3] https://crates.io/crates/futures-preview/0.3.0-alpha.10
The current futures proposal is on track for stabilization[1]. You can use futures with async/await today in nightly, and what you use will probably be exactly what lands in stable soon.
The biggest missing piece is documentation, but thats starting to improve. My go-to for examples is the futures test suite[2]. And if you want more features, futures-preview 0.3alpha adds a bunch of useful future combinators[3]. futures-preview now just wraps nightly's std::future, which is very nice.
Except for the missing documentation, rust's futures are looking great. You can have a play today if you feel keen to jump in. But, as you said it will take some time for the web development ecosystem to mature around the futures API.
[1] https://github.com/rust-lang/rfcs/pull/2592
[2] https://github.com/rust-lang-nursery/futures-rs/blob/master/...
[3] https://crates.io/crates/futures-preview/0.3.0-alpha.10
It’s more like C than any of the high-level languages you mentioned, so yeah, it usually outperforms most of them. It’s basically “memory-safe C” with some modern constructs thrown in for good measure.
I personally wouldn’t build a website in Rust, but a webserver? Yeah, maybe.
I personally wouldn’t build a website in Rust, but a webserver? Yeah, maybe.
Getting concurrency right is difficult, even in Go (I know, I have been there, it was a huge pain in the a$$). Rust guarantees via the borrow checker that the code is data race free. This alone is a huge advancement. I would argue that Rust contains as much boilerplate as Java, but Rust is as fast as C++ and safer than both.
-> You trade some code noise for safety and speed. Compared to C++ the code has even less noise.
Turning code into concurrent code is super easy in Rust. Just use the Rayon crate and change iter() functions into par_iter() and you are done (if the borrow checker doesn't complain).
-> You trade some code noise for safety and speed. Compared to C++ the code has even less noise.
Turning code into concurrent code is super easy in Rust. Just use the Rayon crate and change iter() functions into par_iter() and you are done (if the borrow checker doesn't complain).
If you want a really fast webserver. Tokio's[1] zero-cost abstractions are amazing. Further, the examples provided make futures/async/low-level socket work quite understandable.
[1] https://github.com/tokio-rs/tokio
[1] https://github.com/tokio-rs/tokio
Shameless plug: my friend and I are working on a UDP game networking library purely in Rust, built on Tokio: https://github.com/conwayste/netwayste
(at the moment, it's tightly coupled to our game, however)
(at the moment, it's tightly coupled to our game, however)
>I mean, why would I pick it over C#/Go/Python for web development?
Who said it should be picked for web development?
It's however good for systems programming, libraries, embedded, data crunching, network systems, and so on...
Who said it should be picked for web development?
It's however good for systems programming, libraries, embedded, data crunching, network systems, and so on...
Why is everyone so focused on pigeon holing languages like this? There was a time when I wrote web services in C, then C++, a little Perl, and mostly Java. Then we needed dynamic pages and turned to Javascript, and now that’s on the backend with node.
Personally I love Rust. I would choose to use it for web development top to bottom at this point, even with the current limitations of WASM (which is getting better) on the client side.
I’ve never used a language that can be brought to bear from the top of the stack to the bottom with the safety that Rust brings.
That’s of course me, and I wouldn’t force others to use it. I can finally use one language for everything, and that makes me happy. It’s entirely up to you to choose your language, and if you want to use a new one that has growing communities in each of these area, Rust is a great one to choose.
Personally I love Rust. I would choose to use it for web development top to bottom at this point, even with the current limitations of WASM (which is getting better) on the client side.
I’ve never used a language that can be brought to bear from the top of the stack to the bottom with the safety that Rust brings.
That’s of course me, and I wouldn’t force others to use it. I can finally use one language for everything, and that makes me happy. It’s entirely up to you to choose your language, and if you want to use a new one that has growing communities in each of these area, Rust is a great one to choose.
Because not every problem is a nail.
Right. I won’t use Rust to build hardware, only software.
I have many hammers, one for small nails, on for large nails, a rubber one for joining things, even large sledge hammers. Each has its job.
But if I could only have one, that was flexible enough to use across all situations where I need to hit things, that would be great.
I have many hammers, one for small nails, on for large nails, a rubber one for joining things, even large sledge hammers. Each has its job.
But if I could only have one, that was flexible enough to use across all situations where I need to hit things, that would be great.
Rust still has a lot to catch up on Qt, JavaFX, Android, Cocoa, Forms, WPF, UWP, Unreal, Unity, Hibernate, EF, code generation/reverse engineering from architecture modelling tools, ....
Personally, as polyglot developer, I rather use the best tool for each part of the stack.
Currently I see Rust better taylored for the low level layers that Windows, Android, macOS, iOS, MicroEJ still write in C or C++.
Do you also plan to replace SQL with Rust?
Personally, as polyglot developer, I rather use the best tool for each part of the stack.
Currently I see Rust better taylored for the low level layers that Windows, Android, macOS, iOS, MicroEJ still write in C or C++.
Do you also plan to replace SQL with Rust?
I see all of the gaps you mention as things that are being worked on activily. For some of the things you mention there are already decent Rust libraries: Hibernate => Deisel; Unity/Unreal => there are a bunch of things being worked on eg Piston and others (not yet fully featured of course); code generation => macros_rules! and proc macros, and custom derives can be extended to support this; javafx => yew?.
I’m not saying there are things available for all of these areas, nor am I saying that I think necessarily others should choose to rely on the language in some of these areas, unless you want to directly contribute to filling in those gaps (there are many people who are doing this). What I am saying, is that based on my experience with the language, especially in the context of Web Development, I would pick it for frontend and backend development at this point.
I agree that there are areas it really shines in right now, and if you’re working in those areas than I definitely push people in that direction. But yeah, for native GUI stuff, if you need to do more that toy stuff, it’s not ready yet.
> Do you also plan to replace SQL with Rust?
I’ve considered it! As a way of more replacing DB side procedures: https://github.com/clia/pgxr (an example of one option). What we can do with SQL is use code generators to type check the SQL at compile time.
I’m not saying there are things available for all of these areas, nor am I saying that I think necessarily others should choose to rely on the language in some of these areas, unless you want to directly contribute to filling in those gaps (there are many people who are doing this). What I am saying, is that based on my experience with the language, especially in the context of Web Development, I would pick it for frontend and backend development at this point.
I agree that there are areas it really shines in right now, and if you’re working in those areas than I definitely push people in that direction. But yeah, for native GUI stuff, if you need to do more that toy stuff, it’s not ready yet.
> Do you also plan to replace SQL with Rust?
I’ve considered it! As a way of more replacing DB side procedures: https://github.com/clia/pgxr (an example of one option). What we can do with SQL is use code generators to type check the SQL at compile time.
>Who said it should be picked for web development?
These perhaps?:
https://github.com/SergioBenitez/Rocket
https://github.com/actix/actix-web
https://github.com/carllerche/tower-web
Not saying that is the primary use, but still a valid question as long as these libraries are being built/pushed.
These perhaps?:
https://github.com/SergioBenitez/Rocket
https://github.com/actix/actix-web
https://github.com/carllerche/tower-web
Not saying that is the primary use, but still a valid question as long as these libraries are being built/pushed.
Additionally, npm is a production user that runs at least one web service that we know of, for example.
A web service is not web development though. At least I didn't consider "web development" in the parent's sense with "running a backend REST service", but more like "running websites".
That might be fair, yeah. I've seen some sharply make this distinction, and others not care.
I think things are much more viable for "services" rather than "sites" right now. And the npm thing is a service.
I think things are much more viable for "services" rather than "sites" right now. And the npm thing is a service.
The way I'd describe Rust is, it's what C++ would have been if it used ML as a source of inspiration rather than Simula, and didn't care about preserving syntactic compatibility.
To unpack, this means that it's still a language that is very "close to the metal" in terms of lack of overhead, and broadly follows the don't-pay-for-what-you-don't-use C++ maxim. But at the same time, it's a very high-level language with lambdas and ADTs and destructuring.
To unpack, this means that it's still a language that is very "close to the metal" in terms of lack of overhead, and broadly follows the don't-pay-for-what-you-don't-use C++ maxim. But at the same time, it's a very high-level language with lambdas and ADTs and destructuring.
Yeah, however that is exactly why C compiler vendors did embrace C++, and it got a foothold in OS SDKs.
Had Bjarne not taken that decision and C++ would having drinks with Modula-2, Pascal, Oberon and others.
So it was both a bless and a curse.
Rust seems to be increasingly adopted in spite of being different, so lets see when it gets a nice OS SDK sweet spot.
Had Bjarne not taken that decision and C++ would having drinks with Modula-2, Pascal, Oberon and others.
So it was both a bless and a curse.
Rust seems to be increasingly adopted in spite of being different, so lets see when it gets a nice OS SDK sweet spot.
Rust might be good for algorithmic trading, and is good for other real-time uses. It's good for building wasm modules. It's good for most any kind of performance sensitive or resource constrained application. If you need high throughput, low latency network services, it's good for that. CLI tools. You can build libraries to expose through C FFI, and even plug them into nodejs to do heavy lifting for existing js codebases. I think its good for anything c and c++ get used for and a lot more.
It's not that good for rapid prototyping, won't please many big enterprises who don't trust it and can't hire maintainers easily, and it can't do much on mobile phones. There are also some types of integration work where you'd be wasting your time with rust due to lack of domain specific crates.
It's not that good for rapid prototyping, won't please many big enterprises who don't trust it and can't hire maintainers easily, and it can't do much on mobile phones. There are also some types of integration work where you'd be wasting your time with rust due to lack of domain specific crates.
I would not pick Rust over C#/Go/Python for web development.
Go?
Here's Rust enum for working with JSON
enum Value { Null, Bool(bool), Number(Number), String(String), Array(Vec<Value>), Object(Map<String, Value>), }
How would this look in Go?
enum Value { Null, Bool(bool), Number(Number), String(String), Array(Vec<Value>), Object(Map<String, Value>), }
How would this look in Go?
throwing annotations on structs and letting the library generate suitable serializers and deserializers works reasonably well in Go, as long as the JSON is not too unstructured. The same applies for Java and C# (here the JSON libs might be even better). And obviously for Rust too via serde.
Thats a fairly big restriction though and a sign of type system that is not flexible enough.
Maybe. However your representation isn't without drawbacks either: All fields are typed by strings, and are thereby not strongly typed. And each additional level (in an array or object) requires mandatory boxing and allocations. The codegen variants on pure structs don't have this drawbacks.
I would say your representation is favorable when someone wants to work with arbitrary JSON in a flexible fashion. However if schemas and code generators are available, I would prefer to use those.
I would say your representation is favorable when someone wants to work with arbitrary JSON in a flexible fashion. However if schemas and code generators are available, I would prefer to use those.
Thing is in Rust you can do both
Not proficient in Go but I see an interface{} somewhere in the answer.
At which point type safety goes out the window
Try percy. It's still in alpha, but it awesome.
I think "web development" is too generic to say something like that.
I'd consider a small data processing service, maybe a service invoked from the web server you're already using in Ruby or whatever, is a perfectly pleasant place to use Rust, and often likely to be 1:1 identical to those other languages.
I'd consider a small data processing service, maybe a service invoked from the web server you're already using in Ruby or whatever, is a perfectly pleasant place to use Rust, and often likely to be 1:1 identical to those other languages.
I've been deploying Rust to AWS Lambdas for months for a side project. I chose rust because it's just my favorite language to work in - I'm very productive in it. I also really wanted predictable, solid performance, and Rust is a great fit for that.
I don't really like any of the 3 languages you mentioned though.
I don't really like any of the 3 languages you mentioned though.
How are you wrapping your Rust code? Lambda doesn't support it yet, does it?
Many use the Go runtime, which doesn’t care what kind of binary you actually use. There’s tooling to support this too.
aaaaaaaaaaaaaand today they announced support!
If you had to pick a fourth language what would it be?
I honestly don't know. I primarily work in Python professionally. Java before that. I guess of that list C# seems the most tolerable but I have the least experience with it.
I'm a front-end developer, but I picked up Rust originally to do some audio processing in the browser/node - a thing that's still a little to heavy and time-critical for JavaScript.
Also the compiler is pleasant and gives you helpful advice on how to make your program compile.
Also the compiler is pleasant and gives you helpful advice on how to make your program compile.
It will outperform them (although not by much in the case of Go and C#), and it's also a pleasant language to use. It has a number of features like traits and enums which make it possible to expresa business logic in a way that can feel more natural than OOP classes.
It's also fantastic for reliability. In the same way that Java and C# represent a step up from python/php/js in compiler driven correctness, Rust represents another jump of similar magnitude.
It's also fantastic for reliability. In the same way that Java and C# represent a step up from python/php/js in compiler driven correctness, Rust represents another jump of similar magnitude.
Depending on what you're measuring, it can outperform Go and c# by an appreciable margin. I built http APIs in all three languages which depended on json parsing speed and PRNG speed and the Rust version was well ahead, but these were pretty naive implementations, no 3rd party PRNGs or anything.
In short: any place you would use C/C++, and lots of places where you wouldn't.
> Does it only outperform them, or is it also a pleasant language to use?
I think you'll find a wide range of responses to this question, as personal preferences tend to vary quite a bit. For my two cents, I really enjoy using Rust, and I find myself super productive in it compared to other languages. In broad terms, I find Cargo to be miles ahead of any other build tools/language-specific package managers in terms of ergonomics, and in broad terms, I find the language to be expressive enough to save me a lot of time in having to define things I would have to in other languages and the compiler powerful enough to ensure that I don't break things when doing so. Granted, it takes time to learn how to leverage the expressiveness, and I can understand that not everyone will value this as much as things like being able to ramp up new developers quickly. I'll give the caveat that I don't actually do much web development, so my comments about expressivity/ergonomics describe the language itself and not the web ecosystem.
tl;dr Pleasant is subjective, but yes, some people (like myself!) really enjoy using it
I think you'll find a wide range of responses to this question, as personal preferences tend to vary quite a bit. For my two cents, I really enjoy using Rust, and I find myself super productive in it compared to other languages. In broad terms, I find Cargo to be miles ahead of any other build tools/language-specific package managers in terms of ergonomics, and in broad terms, I find the language to be expressive enough to save me a lot of time in having to define things I would have to in other languages and the compiler powerful enough to ensure that I don't break things when doing so. Granted, it takes time to learn how to leverage the expressiveness, and I can understand that not everyone will value this as much as things like being able to ramp up new developers quickly. I'll give the caveat that I don't actually do much web development, so my comments about expressivity/ergonomics describe the language itself and not the web ecosystem.
tl;dr Pleasant is subjective, but yes, some people (like myself!) really enjoy using it
It's interesting how 7.71% of respondents said they felt they were underrepresented due to being non-heterosexual. If 7.71% of Rust users are non-heterosexual wouldn't that be roughly in line with the expected number, since less than 10% of people fall into this category? It is also possible that this study is not a representative sample of Rust users, but then that also makes the rest of the results less useful as well.
The question asked about "technology", not the Rust community. It can be interpreted as implying that non-heterosexuals are underrepresented and simply asking if the respondent identifies as non-heterosexual. Also, people's concepts of representation often include visibility.
Should they have had a perfect idea of how many others were non-heterosexual?
Well that's my point, they seem to have a perception of the Rust community that is incorrect. It's not neccesarily a bad thing, just an observation.
Ah, doesn't sound surprising to me. If the topic isn't regularly discussed I'd assume that most minorities would feel underrepresented. Also not necessarily a bad thing.
Rust is such a great language, and I wish I had more excuses to use it frequently. It is well-designed and pleasant to use. It has a vibrant and friendly community. It is fast. The library ecosystem is getting there. Go Rust!
How/why are so many people using nightly as their rust version? Usually companies are conservative about jumping onto newer compiler versions.
Right now, a lot of people want nightly (and [Rust 2018]) for NLL. It makes the borrowchecking system a lot more precise and less conservative, which in turn makes the language much less annoying to use.
Using nightly as the compiler is much easier in Rust than, for example, using Python 3 early on was, because unlike, say, Python 3, nightly is fully backwards-compatible to earlier stable releases. (While not being backwards-compatible to previous nightlies.)
This means it's easy to limit yourself to the features used in stable + one major change you want, and if there is no change to that major feature, you won't even notice all the instability of the compiler.
There has been some hope of people moving to stable versions as NLL hits them, I think most people will always want the next big feature (personally waiting for const generics) on nightly, at least until the language is a lot more complete.
Using nightly as the compiler is much easier in Rust than, for example, using Python 3 early on was, because unlike, say, Python 3, nightly is fully backwards-compatible to earlier stable releases. (While not being backwards-compatible to previous nightlies.)
This means it's easy to limit yourself to the features used in stable + one major change you want, and if there is no change to that major feature, you won't even notice all the instability of the compiler.
There has been some hope of people moving to stable versions as NLL hits them, I think most people will always want the next big feature (personally waiting for const generics) on nightly, at least until the language is a lot more complete.
In case anyone else was wondering what this jargon meant, "non-lexical lifetime":
https://github.com/rust-lang/rust/issues/43234
Took me a bit of websearching to figure out what people were excited about.
https://github.com/rust-lang/rust/issues/43234
Took me a bit of websearching to figure out what people were excited about.
Good call, thanks.
Additionally, even that is kind of jargon. The simplest answer is “the borrow checker will allow some kinds of code that is sound, but the previous borrow checker could not understand that it was sound.”
Additionally, even that is kind of jargon. The simplest answer is “the borrow checker will allow some kinds of code that is sound, but the previous borrow checker could not understand that it was sound.”
I see that NLL makes the borrow checker easier to work with for developers, but does NLL actually change when objects will be dropped at run-time?
NLL does not affect things that implement Drop. This is called "eager drop", and while it would only affect unsafe code, we deemed it to be too likely to cause problems with said code. Even though it's unsafe, we don't want to make that even harder to understand.
That makes sense. A developer writing unsafe code can more easily and clearly control their drops by introducing new scopes than deciphering where the eager drop happened.
[deleted]
> Right now, a lot of people want nightly (and [Rust 2018]) for NLL.
9 more days!
9 more days!
NLL is stable in 1.31?
For 2018 edition code, yes. 2015 will come later.
I am incredibly excited for this!
> at least until the language is a lot more complete.
Or used in larger projects. Or used in environments where (a) dev's prefs cannot be nightly.
Or used in larger projects. Or used in environments where (a) dev's prefs cannot be nightly.
What's a "large project" to you, incidentally?
We know of several codebases that are over a million lines. To some people, that's big, and to many, it's not.
(Note also that this data shows a majority of people do use stable.)
We know of several codebases that are over a million lines. To some people, that's big, and to many, it's not.
(Note also that this data shows a majority of people do use stable.)
Maybe I should have said "used in large project more often"
> (Note also that this data shows a majority of people do use stable.)
Well, that kinda proves my point then, right?
> What's a "large project" to you, incidentally?
It's more that the larger the project (either in code or number of devs working on it), the more tool-stability becomes a requirement. Just my experience, and it is quite understandable.
> (Note also that this data shows a majority of people do use stable.)
Well, that kinda proves my point then, right?
> What's a "large project" to you, incidentally?
It's more that the larger the project (either in code or number of devs working on it), the more tool-stability becomes a requirement. Just my experience, and it is quite understandable.
Ah, cool, thanks :)
> To some people, that's big, and to many, it's not.
This boggles my mind, so I have to ask, who considers a million lines of code in a code base not a large project? I mean, sure there are plenty of projects larger than that, but when considering whether a project is large or not, I think I would consider a million lines of code well into the "large" category.
This boggles my mind, so I have to ask, who considers a million lines of code in a code base not a large project? I mean, sure there are plenty of projects larger than that, but when considering whether a project is large or not, I think I would consider a million lines of code well into the "large" category.
As with most things, people's experience is colored by their previous experience. There are people who work on 10MM LOC codebases that say "oh well you don't even have one of those", or for example, take Google's C++ codebase, which last I saw is estimated at something like 2 billion lines? Yes, that's a bunch of small projects, but since it's in a monorepo and uses one big build system, to people thinking about scale, they consider it one, or so I've heard.
Add in a general sense of bragging rights, and well, I've heard people say "call me when you have a real project" about more absurd (to me) things than just this in the past...
Add in a general sense of bragging rights, and well, I've heard people say "call me when you have a real project" about more absurd (to me) things than just this in the past...
Nightly isn't really as unstable as the name implies. Without invoking `#![feature(...)]` flags it's basically functions identically to stable. Sure, occasionally something breaks, then you type `rustup default nightly-<a date a few days ago>` and keep on chugging.
Meanwhile you get access to more and better tools, which has no impact on the stability of your code base but a positive impact on productivity. It enables you to decide to bite the bullet and give up on language stability for new useful features if you want to (which I often do, for nll).
So, what I do is develop on nightly, and make things I want other people to use work on stable.
Meanwhile you get access to more and better tools, which has no impact on the stability of your code base but a positive impact on productivity. It enables you to decide to bite the bullet and give up on language stability for new useful features if you want to (which I often do, for nll).
So, what I do is develop on nightly, and make things I want other people to use work on stable.
> what I do is develop on nightly, and make things I want other people to use work on stable.
What do you do with the stuff you make on nightly? Use it only for yourself?
Edit: oh, I think I see: you don't use any new features when you develop on nightly.
What do you do with the stuff you make on nightly? Use it only for yourself?
Edit: oh, I think I see: you don't use any new features when you develop on nightly.
Some people use nightly to actually build, but don't turn on any nightly-only features. This means that they get early access to bugfixes and improvements, but don't actually restrict their users to nightly.
(This may not be what your parent is talking about, but it is a use-case I've seen before.)
(This may not be what your parent is talking about, but it is a use-case I've seen before.)
This is what I'm talking about.
> When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm.
as for how `rustup install nightly`
as for how `rustup install nightly`
Companies? Only 30% of respondents reported using Rust at work. Presumably a majority of Rust hobbyists use nightly and less so for those writing Rust for a job.
At this point, I think it's mostly being used to it as nightly was more convenient for a long time.
I've currently switched to nightly to use the 2018 edition changes already, which will soon be unnecessary.
Almost all libraries work fine on stable now. (the new async/wait support is an exception, but it's still very experimental right now and not used by many)
Important note: You can always develop on nightly and get potential speedups etc, but not use any features and then deploy only with stable.
I've currently switched to nightly to use the 2018 edition changes already, which will soon be unnecessary.
Almost all libraries work fine on stable now. (the new async/wait support is an exception, but it's still very experimental right now and not used by many)
Important note: You can always develop on nightly and get potential speedups etc, but not use any features and then deploy only with stable.
For a long time, there were really useful things that were available only in nightly, I believe.
The Rust team has also done an unprecedented job of balancing stability and improvement.
The Rust team has also done an unprecedented job of balancing stability and improvement.
Yes. Note that there’s also lag, this survey was taken much earlier this year. And so:
> When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm.
wasm, clippy, embedded, and proc macros aren't nightly any more. NLL, 2018 edition are coming soon. (December 6)
> When asked why they used nightly, people responded with a broad range of reasons including: access to 2018 edition, asm, async/await, clippy, embedded development, rocket, NLL, proc macros, and wasm.
wasm, clippy, embedded, and proc macros aren't nightly any more. NLL, 2018 edition are coming soon. (December 6)
Some of the packages I use require nightly, Like the syscall crate and iirc I had to use the nightly compiler for inline assembly as well.
Yes, inline asm is still nightly only, and the syscall crate uses it.
Incidentally, what do you use the syscall crate for? I'm very curious!
Incidentally, what do you use the syscall crate for? I'm very curious!
Rewriting a system call fuzzer I wrote in C several years ago in Rust. I ran into many problems with the C version with memory management across multiple child processes. I figure rust would make the memory management much easier and it would be a great way to learn Rust. So far Rust is making the project much simpler and more robust, with similar performance to the C version.
Neat! That sounds like a great use-case. Thank you :)
Yea when it's usable to people other then me I'll open source it. But so far it's FreeBSD only and I want to get Linux and MacOS support going as well.
You're using inline assembly for syscalls on FreeBSD? My recollection when I last looked into it was that FreeBSD only defined syscalls as C function calls, and did not have a stable ABI at the assembly level.
(I was looking into it because I was trying to do system calls without having a stack page mapped as part of an assembly sandbox).
(I was looking into it because I was trying to do system calls without having a stack page mapped as part of an assembly sandbox).
The majority of system calls are going through the syscall crate, but system calls not yet supported by the syscall crate are being called with assembly directly. However going forward I plan on just updating the syscall crate so it supports newer system calls and make a pr into the syscall repo, instead of manually calling system calls with assembly.
I believe you’ll have to fork the crate, the owner of it no longer programs in Rust.
They may also be willing to hand it over to you, I don’t know.
They may also be willing to hand it over to you, I don’t know.
Any reason you can't use libc::syscall?
While this is true (Windows is another example), that doesn't stop people from doing this. It's how Go works most of the time, for example.
I've seen some people gladly using nightly rust but restricting themselves with the GCC and CMake that comes with CentOS 6. The damage done by distributions shipping development toolsets is never-ending.
> The damage done by distributions shipping development toolsets is never-ending.
You say that, but we've already come out the other end of the period where linux was still on the upward swing of popularity and if a development toolchain wasn't as easily available a lot of software may never have taken off as quick.
The ability to easily install a development toolset to compile (even if safely hidden behind a script to download and compile something like Ruby, Python, Perl, or a module for one of them) is a major boon, even if just used to create packages for the distribution's package system for local distribution (e.g. creating an RPM from spec).
Given the choice between an easily installable default that might get old or no first party option provided, having a default available is vastly better. Blame companies for poor options they choose, not the people and organizations that do their best to provide even a single option.
You say that, but we've already come out the other end of the period where linux was still on the upward swing of popularity and if a development toolchain wasn't as easily available a lot of software may never have taken off as quick.
The ability to easily install a development toolset to compile (even if safely hidden behind a script to download and compile something like Ruby, Python, Perl, or a module for one of them) is a major boon, even if just used to create packages for the distribution's package system for local distribution (e.g. creating an RPM from spec).
Given the choice between an easily installable default that might get old or no first party option provided, having a default available is vastly better. Blame companies for poor options they choose, not the people and organizations that do their best to provide even a single option.
The biggest reason (for me anyway) to restrict which gcc I use (and stick to the system-provided one) is so I don't need to distribute libstdc++ and libgcc_s with my program.
The RedHat devtoolset was a nice solution to this (use a newer gcc version, but link to the system libraries), but if that isn't available, then building with the system compilers helps in this area.
Rust doesn't have this problem when rust programs are statically linked, but if distros start shipping rust shared libraries which other programs start depending on, and/or some of the rust standard lib ends up in a system shared library, some of the same issues may arise (or maybe not, rust may have solved them in a clever way).
The RedHat devtoolset was a nice solution to this (use a newer gcc version, but link to the system libraries), but if that isn't available, then building with the system compilers helps in this area.
Rust doesn't have this problem when rust programs are statically linked, but if distros start shipping rust shared libraries which other programs start depending on, and/or some of the rust standard lib ends up in a system shared library, some of the same issues may arise (or maybe not, rust may have solved them in a clever way).
It's not the end of the world for distros; they pick a single Rust version, and so shared libraries work for them.
They do need to recompile the world when they update the compiler, but it's a single recompile each time.
They do need to recompile the world when they update the compiler, but it's a single recompile each time.
Right - and so you get same situation that you have in C++-land (if I'm understanding you correctly) where compiling arbitrary rust programs with the distro compiler level may benefit you if you want to depend on the system-provided rust shared libraries.
Yep.
DLL hell on Linux.
Not really; there's a few substantial differences between shared objects with SONAMEs and link-time vs run-time file system names and LD_LIBRARY_PATH and /etc/ld.so.conf vs DLLs and searching PATH (starting with ".").
I don't know much about modern Windows (SxS, etc) so things may have improved there, but last I looked (a while back admittedly) DLL hell and shared object issues were in different leagues.
I don't know much about modern Windows (SxS, etc) so things may have improved there, but last I looked (a while back admittedly) DLL hell and shared object issues were in different leagues.
Well, I might have misunderstood the original problem.
>so I don't need to distribute libstdc++ and libgcc_s with my program
Could you explain why you want to avoid that?
>so I don't need to distribute libstdc++ and libgcc_s with my program
Could you explain why you want to avoid that?
There’s a DTS that ships Rust 1.26 (rust-toolset-7), however, it requires RHEL/CentOS 7. Red Hat’s been doing a pretty good job with providing newer toolkit’s through the DTS system, but some of them didn’t find their way to RHEL 6.
They also announced this recently: https://developers.redhat.com/blog/2018/11/20/support-lifecy...
That's mostly because those two are stable, and there is near to no gain on going into the bleeding edge. When people gain something from an upgrade, they do it.
That's because the libraries come from the same source and work together. Rust/cargo is it's own little universe ignoring the rest of the system.
Companies using Rust are not too conservative I think. Conservative companies use Java or C++, or something similarly stable and easy to hire for.
It's not really a question of being conservative but of being professional, I would say.
Using unstable anything on production software is not professional, on mission critical software it is reckless incompetence.
Using unstable anything on production software is not professional, on mission critical software it is reckless incompetence.
It's very easy to use nightly (install via rustup, then `cargo +nightly blah --args` instead of `cargo blah --args`), and there are (ugh, still) a number of somewhat popular libraries that require nightly versions of the compiler.
In particular, using nightly allows you to opt-in to a number of experimental language features in exchange for maintenance burden. It's not a choice I make, although it's fun to do every now and then just to get a feel for what's available in the nightly builds.
In particular, using nightly allows you to opt-in to a number of experimental language features in exchange for maintenance burden. It's not a choice I make, although it's fun to do every now and then just to get a feel for what's available in the nightly builds.
I've been able to find good libraries for everything I need on stable now that Diesel is on stable, so there's not really a requirement anymore to use nightly for most things.
For example, I use actix, which works really well. It's not as ergonomic as Rocket, but it's way faster and quite useable. The same is true for pretty much everything I need, so I only use nightly when I'm dinking around with something that doesn't need to go to production anytime soon.
For example, I use actix, which works really well. It's not as ergonomic as Rocket, but it's way faster and quite useable. The same is true for pretty much everything I need, so I only use nightly when I'm dinking around with something that doesn't need to go to production anytime soon.
I think `async/await` is the big one for network stuff. Rocket is the library I was thinking of when I wrote that, though.
My (possibly mistaken) understanding is that my coworkers who do more web servery stuff than me prefer actix to rocket for other reasons too, and wouldn't use rocket even if it worked on stable.
I don't really know the arguments around them, TBH.
My (possibly mistaken) understanding is that my coworkers who do more web servery stuff than me prefer actix to rocket for other reasons too, and wouldn't use rocket even if it worked on stable.
I don't really know the arguments around them, TBH.
The big one is that Actix is able to use async IO, but Rocket is sync.
We ship all stuff on stable but I regularly use nightly for local development to get extra features for debugging (for instance cargo expand is nightly only).
The biggest one for me is the async/await support for futures, which is not stabilized quite yet. In Rust it buys you not only the usual ergonomics, it also allows you to handle lifetimes in futures in ways that are basically impossible when using only combinators.
when i was checking things out a while back, it felt like every interesting library required nightly. it was a significant turnoff. :\
Depending on when "a while" is, it may be significantly different now. We've had at least two big releases that have shifted a significant amount of the ecosystem, and many smaller ones that have improved things too.
The most surprising thing was "Rust should do more marketing, not many people know about it".
I would have thought literally every programmer on earth would have heard of rust. Whether they have looked into it or use it would be a different question. But unless those programmers don't keep up with their tools, I find it hard to believe they don't know about Rust.
I would have thought literally every programmer on earth would have heard of rust. Whether they have looked into it or use it would be a different question. But unless those programmers don't keep up with their tools, I find it hard to believe they don't know about Rust.
Most of the programmers out there do not have any community contact outside of the company they are part of.
We are not representing the majority here
We are not representing the majority here
I assume they would have read news, Reddit, or Digg ( in the old days ) Internet forum, HN etc.
If they have not heard of Nim, Crystal, D, then I would not be surprised. But Rust?
If they have not heard of Nim, Crystal, D, then I would not be surprised. But Rust?
A lot of people do not read reddit, digg, hacker news, or internet forums. Way way more than those that do.
I don't mean normal everyday consumers. But I would be surprise if programmer don't go on internet often for information. Not information on latest news, but documentation, problem solution, etc. Stackexchange, Google. Even good old manuals of long lost chips, reference in assembly languages. The chances of these people never heard or bump into the word "Rust"?
That is like saying programmers have never heard of Swift.
They may not know anything about it. But not "heard" of it, is.... strange?
That is like saying programmers have never heard of Swift.
They may not know anything about it. But not "heard" of it, is.... strange?
And still it is the truth. More than you think.
Hell i work for a car manufacturer with thousands of devs. Most of them have not heard from anything since early 00s Perl, PHP and Java. And they have not moved. Everything newer is "Startup stuff, we live in the real world here"
Hell i work for a car manufacturer with thousands of devs. Most of them have not heard from anything since early 00s Perl, PHP and Java. And they have not moved. Everything newer is "Startup stuff, we live in the real world here"
I mean wow, just wow.
Yeeeep.
I see you have dealt with some of them recently :D
I mean to be honest, it is a great thing for me. As my specialty is to cleanup and replace that kind of systems, ala 18f/USDS. I have an easy job finding for my whole life.
But hell it makes it hard to talk with the "vocal" people out there.
I mean to be honest, it is a great thing for me. As my specialty is to cleanup and replace that kind of systems, ala 18f/USDS. I have an easy job finding for my whole life.
But hell it makes it hard to talk with the "vocal" people out there.
Nitpick: Some of those pie charts are not very nice to read. Some of the busy ones have me scanning for labels left and right. A table would be simpler to read (especially as the labels are small and light grey for some reason).
I think pie charts are perhaps better when you've got, say two to four items and labels are short enough to be in place instead of off to the side.
I think pie charts are perhaps better when you've got, say two to four items and labels are short enough to be in place instead of off to the side.
Thanks! And to jononor's comment below as well.
We're not exactly data scientists... maybe for next year we'll make some of these changes.
We're not exactly data scientists... maybe for next year we'll make some of these changes.
No worries. It's a great survey regardless, so thank you!
I’m surprised to see library support so high on the “needs to improve” list.
It makes sense when compared to the rich Python ecosystem. Coming from a C++ background I consider the Rust library ecosystem to be one of its strong points already!
It makes sense when compared to the rich Python ecosystem. Coming from a C++ background I consider the Rust library ecosystem to be one of its strong points already!
I have a feeling some of it is due to all the "Why isn't X in the std library" questions being bundled into library support.
If this is the case then its a bit misleading as it could be loads of people asking for a single thing, rather than people asking for better library support in general.
I don't think the Rust Standard lib is too bad, so i'm also surprised its so high up.
If this is the case then its a bit misleading as it could be loads of people asking for a single thing, rather than people asking for better library support in general.
I don't think the Rust Standard lib is too bad, so i'm also surprised its so high up.
> Coming from a C++ background I consider the Rust library ecosystem to be one of its strong points already!
In a sense, I agree with you. Certain kinds of features available in the Rust ecosystem are much more easily available than in the C++ world, and there's been a lively pace of articles published about libraries and applications in Rust. But another sense I got from looking at libraries to use myself and applications to learn from was that the ecosystem is quite smaller and ... not quite as matured as the C/C++ ecosystem (I'm _completely_ ignoring FFI for this argument). Of course, all of this is completely natural, and I'm simply not expecting them Rust ecosystem to be competitive with the much older C/C++ ecosystem(s), but this realization does temper my excitement with Rust a bit.
In a sense, I agree with you. Certain kinds of features available in the Rust ecosystem are much more easily available than in the C++ world, and there's been a lively pace of articles published about libraries and applications in Rust. But another sense I got from looking at libraries to use myself and applications to learn from was that the ecosystem is quite smaller and ... not quite as matured as the C/C++ ecosystem (I'm _completely_ ignoring FFI for this argument). Of course, all of this is completely natural, and I'm simply not expecting them Rust ecosystem to be competitive with the much older C/C++ ecosystem(s), but this realization does temper my excitement with Rust a bit.
Some of my excitement is for potential rather than current offerings.
But having a gamedev background we tend to roll most things ourselves. C++ is such a hodgepodge of mixed build systems that adding a moderately sized library is a huge PITA.
But having a gamedev background we tend to roll most things ourselves. C++ is such a hodgepodge of mixed build systems that adding a moderately sized library is a huge PITA.
I don't program in Rust regularly, but it's on my short list of languages that I keep up on and am a member of the local user group (Meetups, to use the commercial implementation). I have a trio that I keep up on, C# (gen purpose, my language of choice), Rust (systems) and Elixir (web).
I only really use C#. I've kicked the tires on Rust and Elixir, and I could see myself using Elixir on a personal project but unlikely I'll ever have a good usecase for Rust.
It does power a large portion of my Firefox browser, so from that sort of usage viewpoint I'm using something built with Rust everyday, which I can't say likely will never say for Elixir, discounting the other language on the BEAM platform.
I only really use C#. I've kicked the tires on Rust and Elixir, and I could see myself using Elixir on a personal project but unlikely I'll ever have a good usecase for Rust.
It does power a large portion of my Firefox browser, so from that sort of usage viewpoint I'm using something built with Rust everyday, which I can't say likely will never say for Elixir, discounting the other language on the BEAM platform.
I wonder what the correlation is between "took a long time to become productive in Rust" and "uses Rust rarely."
Coming from Crystal/Ruby, I just could never get it to do what I wanted it to do. Tried writing a generic stream API, and using closures naturally like anyone would to do things like "on_data" etc., only to run into insurmountable life cycle and borrowing problems. Tried for 4 weeks straight to get the same 100 lines of code to work. Ended up giving up when the rust gitter told me it was impossible to do this sort of thing, and wrote a perfectly working implementation in crystal in an afternoon.
I find a lot of the frustration with such things in rust is because people try to optimize things very early with rust, because it makes it explicit when you are opting into something which costs some performance. Many beginners try to write something with references which either won't work (and in C++ would simply crash) or requires substantial effort to accomplish without some degree of indirection, runtime tracking, or allocation.
In higher-level languages the indirection and allocation are so ingrained into the language users don't even realize it's there (how many people know that basically every class member access or function call in python involves a hash table lookup?). If you try to do the same in rust you find you need to say where you want the runtime tracking and indirection to occur, and in general this means you use less of it, but it doesn't mean you should tie yourself in knots trying to avoid it. A little more eager use of trait references, Rc, and RefCell makes for a much better rust experience, but there's a strange psychology to it which makes people unwilling to do it, even when they know it's there and how to use it (and there is a difficulty of teaching beginners that it is there and how to use it).
In higher-level languages the indirection and allocation are so ingrained into the language users don't even realize it's there (how many people know that basically every class member access or function call in python involves a hash table lookup?). If you try to do the same in rust you find you need to say where you want the runtime tracking and indirection to occur, and in general this means you use less of it, but it doesn't mean you should tie yourself in knots trying to avoid it. A little more eager use of trait references, Rc, and RefCell makes for a much better rust experience, but there's a strange psychology to it which makes people unwilling to do it, even when they know it's there and how to use it (and there is a difficulty of teaching beginners that it is there and how to use it).
Perhaps a GC would help Rust being this productive?
Rust had an optional GC once, they removed it. Nim is the answer to scrubs like me who thought Rust was interesting up until that point, since Nim is super fast and lets you allocate/deallocate directly (use of GC is optional) and has three different GC implementations to choose from (including a soft real time one).
despite the name for the syntax, rust never really had a GC, just a slightly shorter syntax for reference-counted heap-allocated objects and a vague idea of 'probably it'll handle loops one day', until the language design solidified around an extremely minimal runtime and preferring standard library features over language features.
Or crystal.
We have a ton of GC languages already. Rust is unique for being able to do a lot of things very safely, but also fast because it does not require a GC.
Being able to generate fast code doesn't imply not having a GC.
It is all a matter how it is implemented and the additional language features for manual types and control of allocations, and how good the compiler backend is transforming all that AST information into actual code.
Something like Modula-3, Active Oberon, System C#, Eiffel, D and so forth.
It is all a matter how it is implemented and the additional language features for manual types and control of allocations, and how good the compiler backend is transforming all that AST information into actual code.
Something like Modula-3, Active Oberon, System C#, Eiffel, D and so forth.
I use Rust daily, and it took me a while to be productive. Productive is hard to define, and I guess I'm not "all the way there"; the design of a Rust project still takes me longer than a C++ or JavaScript one, mostly due to its pervasive restrictions around mutability.
There are still things I'd have trouble doing. I used to do game development professionally, and I still don't think I'd use Rust for it. I also have worked on virtual machines and high level programming language runtimes, and I wouldn't want to write a GC in Rust.
(Yes, I've seen shifgrethor[0] and the rustconf 2018 closing keynote[1] (I was there, actually) -- both are great, but they're almost more examples of my point; Rust makes certain patterns much harder).
[0]: https://github.com/withoutboats/shifgrethor/
[1]: https://kyren.github.io/2018/09/14/rustconf-talk.html
There are still things I'd have trouble doing. I used to do game development professionally, and I still don't think I'd use Rust for it. I also have worked on virtual machines and high level programming language runtimes, and I wouldn't want to write a GC in Rust.
(Yes, I've seen shifgrethor[0] and the rustconf 2018 closing keynote[1] (I was there, actually) -- both are great, but they're almost more examples of my point; Rust makes certain patterns much harder).
[0]: https://github.com/withoutboats/shifgrethor/
[1]: https://kyren.github.io/2018/09/14/rustconf-talk.html
Agreed. I also wonder what "productive" means. It would be interesting if they framed it in terms of other languages ("I'm as productive as I am in my most-frequently-used non-Rust language") or similar.
This is still a meaningless question, because different languages are good for different things.
Are you as productive in rust when doing web front-end development as in javascript? Are you as productive when doing one-of scripts as in perl? Are you as productive when doing exploratory data analysis as in python? Are you as productive when doing database queries as in SQL?
Are you as productive in rust when doing web front-end development as in javascript? Are you as productive when doing one-of scripts as in perl? Are you as productive when doing exploratory data analysis as in python? Are you as productive when doing database queries as in SQL?
I disagree.
This is obviously a subjective question. You will feel productive once you have a sufficient grasp on the language and the parts of the ecosystem you need.
Basically no-one will have Rust as a first language so there will be a point of comparison to other languages too.
This is obviously a subjective question. You will feel productive once you have a sufficient grasp on the language and the parts of the ecosystem you need.
Basically no-one will have Rust as a first language so there will be a point of comparison to other languages too.
Nobody said anything about feeling productive. They're talking about being productive.
It's not meaningless; it's just not very meaningful. You can doctor the phrasing to filter out the specific issues you raised (hence, "or similar"). More importantly though, it's never going to be a perfect metric because there is some inherent subjectivity; however, it's still far more meaningful than the current question. There is a difference between "meaningless" and "not 100% meaningful".
In case you guys want a comparison to a similar survey for another language, here is Nim's 2018 survey results: https://nim-lang.org/blog/2018/10/27/community-survey-result...
I really wish languages would standardize on at least some of these questions to make comparisons possible.
Side note: Pie charts are terrible for conveying any real information. Stick with bar charts for ratios.
Are these results published in multiple languages, as the survey was conducted in multiple languages?
Not currently, as we only blog in English.
We’re still, as a project, working on i18n. Conducting the survey was one of the big first steps. We’ll get there.
We’re still, as a project, working on i18n. Conducting the survey was one of the big first steps. We’ll get there.
The low contrast of the text in the graphs makes them near illegible to me.
Pie charts :(
Is the "The survey also highlights some challenges, as the number of women is still lower than the industry average of women in programming fields" editorial comment based solely on this result? It seems to exclude the possibility of women who don't identify as belonging to an underrepresented group.