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?
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.
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".
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).
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.
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.
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.
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).
> 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.
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)
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.
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.
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.
Depending on your testing and release process using an unstable compiler may not be a big deal. Unlike a webserver or a JIT you run the rust compiler once with your final product and can spend as much time as you want to verify the result.
Any difference between production and dev/testing environments should be justifiable. Certainly in the last testing stage there should be no difference at all.
Nightly builds of any software are only there to enable testing 'in the wild' of that software. There's no justification for any other use.
Edit: The Rust community really needs to grow up...
I thought I had posted constructive comments on this discussion.
If discussing good software practices is "flamebait" that deserves to be downvoted, which was what my "growing up" quip was about, then I am at a loss as to what to do...
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 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.
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.
> 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.
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).
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.
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.
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.
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.
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.)
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.
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.
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).
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.
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.
> 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.
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...
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.
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.”
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.
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.
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.
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).
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 "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.
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.
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.
* 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.
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.
> 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 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.
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.
> 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(|_| ())`).
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.
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
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.
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".
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.
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++.
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.
Obvious troll is obvious. Try to name a non successful React/Vue/TypeScript/Node/WASM project. ES8 is here. I guess next you'll say Sublime isn't the best. I don't know why I keep coming here...
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.
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.
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.
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.
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.
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).
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:
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.
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 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.
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).
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 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?
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.
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.
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.
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.
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.
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’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!
> 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.
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.
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.
It is sad that I can't even reveal who I am to talk about this but it needs to be done. If you look at 3 recent surveys of developers you find that the % of women respondents is extremely low. For example:
Apparently answering an anonymous survey is either too much trouble for women to bother with or they just aren't participating in the development community at all. Women developers on HN, why aren't women participating? There are allegedly 25% women in development jobs. Are those surveys stretching the definition of developer? Why should companies be expected to hire women developers when it appears there are so few? The places with more than a few women developers also attract more, making it even more difficult for other companies to hire them. I am exasperated every time someone asserts that it isn't a pipeline problem. Based on these results there just aren't any out there at scale.
> Apparently answering an anonymous survey is either too much trouble for women to bother with
Comments like this are what put people off. Trying to find out why women or other minorities are not participating is constructive and useful, but not when you frame the problem as their fault.
I agree the GP comment was worded a little weirdly, but I'm not sure it actually is trying to frame the problem as their fault. Later portions, such as:
> Why should companies be expected to hire women developers when it appears there are so few? The places with more than a few women developers also attract more, making it even more difficult for other companies to hire them. I am exasperated every time someone asserts that it isn't a pipeline problem. Based on these results there just aren't any out there at scale.
Seem to indicate to me they view it more as the quoted industry numbers are wrong, at a minimum misleading (e.g. maybe female developers are much more likely to be relegated to junior positions or not have or feel they have the freedom to explore less mainstream solutions).
In any case, it's an interesting question. Why are there major discrepancies between what is reported by the industry for gender involvement and by community driven efforts?
Finally, I think it's worth noting that in a comment where the author felt the need to not only post it anonymously, but explain that they felt the need to do so, you picked out one sentence, chose a negative interpretation of it, and then called out the original comment for attibuting blame to women when the comment clearly ended with the sentiment "we need to make it easier for women to enter the industry." That doesn't exactly foster good discussion. :/
If I do or not do something, I take responsibility for it. Women developers often suggest that women don't have time or inclination to participate in the community (1). If so fine, but don't count on there being a ton talented women Rust developers in the future if they aren't participating right now.
Yeah, normally I don't want to touch these issues with a ten foot pole, but I'll comment here. I agree with the sibling commenter that your tone is too aggressive, but I think that, on average, it's just fewer women are interested in technology than men.
There's a prevailing opinion that tech is hostile to women, and that might be true, but I don't think that there would ever be a 50-50 split, even if the community were equally welcoming to both sexes. I also don't see why there's a big push to get women in tech but not an equally big push to get men in teaching, or nursing, or whatever, except for the fact that there's money in tech.
Completely anecdotally, the worst female developers I've worked with were "women in tech", for whom that was an identity. They weren't developers and women, they were "women in tech" evangelists. The great female developers I've worked with didn't care (or at least didn't talk about) being women, they just did their job, same as everyone else, and were treated like everyone else (or I didn't notice or hear about any difference).
In summary, I think harassment and bias in the workplace should be abolished, and I think that this has become a disproportionately large issue, to the point where you can't talk about it eponymously for fear of getting fired.
I'm a woman in software. I'm fairly junior, I have only been doing this for a few years now.
I have used Rust a few and did not participate in the survey, but I did participate in the Python user survey, because at least 50% of my time is working with Python.
My workplace is mostly men- in fact I am the only woman in our USA office. And I agree that I would prefer to work somewhere with more women, or more representation of women.
Representation isn't exactly linear either. If women in dev jobs at a company write blog posts for the company, for instance, that gives me a higher opinion of the company.
Finally, the majority of women who are in the community are likely a silent majority. I hardly ever make pull requests for packages I patch because of bad experiences I've had, I don't comment on message boards, and on HN I don't use my real name either.
I'd blame that, for me personally, on bad or frustrating experiences. And it's fine if the community acts that way, and it's fine if myself and other women choose to stay quiet.
> I'd blame that, for me personally, on bad or frustrating experiences. And it's fine if the community acts that way
Wait, why is it fine if the community acts in a way that provides bad or frustrating experiences for specific categories of people (in this case, minorities in comparison to the overall population of that group, which women are in software development)?
If someone said "I'm black and I interact with the community less because of bad or frustrating experiences", we probably wouldn't say that's okay, so I'm wondering why you feel it's okay for the community to act that way towards you as a woman? Or did I misinterpret?
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!
The "Do you consider yourself a member of an underrepresented demographic in technology" result is interesting - 92.06% No, but a total summing to 156.3%. Assuming this question was phrased as "either No, or check all that apply", this suggests that many of those who do feel underrepresented feel that way on multiple counts.
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.
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"?
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 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.
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.
> 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..
>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.
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".
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.
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.
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.
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.
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.
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.
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 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?
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 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.
reply