The language everyone lies about loving
-
97% of people who claim to love working with Rust freely admit they've never actually used it.
Programming language Rust's adoption problem: Developers reveal why more aren't using it
The Rust project wants more developers to use the programming language but admits it has a challenge with adoption.
-
Well, it has a compiler that only accepts code where it can statically verify at least some things are correct. That excludes it from being usable by at least 95% of monkeys that just throw shit at the wall.
@Mason_Wheeler said in The language everyone lies about loving:
97% of people who claim to love working with Rust freely admit they've never actually used it.
The article doesn't actually say that.
-
Written by Liam Tung, Contributing Writer on April 21, 2020
Maybe check if there are any updated numbers since then?
-
@topspin said in The language everyone lies about loving:
The article doesn't actually say that.
The article said:
"despite developers' positive feelings toward Rust, 97% of them hadn't actually used it. "
-
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
The article doesn't actually say that.
The article said:
"despite developers' positive feelings toward Rust, 97% of them hadn't actually used it. "
And you said: "claim to love working with Rust"
"Positive feelings towards" != "claim to love working with"
-
@JBert said in The language everyone lies about loving:
Maybe check if there are any updated numbers since then?
It's still going to have problems making headway simply because of the sheer size of existing codebases. And it won't make much progress against Java or C# or Python, where programmers will just go "Needing to put lots of effort into lifetime tracking? When I have GC already? Lolnope!".
-
@topspin said in The language everyone lies about loving:
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
The article doesn't actually say that.
The article said:
"despite developers' positive feelings toward Rust, 97% of them hadn't actually used it. "
And you said: "claim to love working with Rust"
"Positive feelings towards" != "claim to love working with"
-
@topspin said in The language everyone lies about loving:
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
The article doesn't actually say that.
The article said:
"despite developers' positive feelings toward Rust, 97% of them hadn't actually used it. "
And you said: "claim to love working with Rust"
"Positive feelings towards" != "claim to love working with"
The discussion was specifically about a StackOverflow poll where people voted Rust the "most-loved" programming language. Grow some reading comprehension already!
-
Developers provided a variety of reasons for never having used Rust.
There's one they probably didn't provide - it's ugly
-
@Applied-Mediocrity said in The language everyone lies about loving:
Developers provided a variety of reasons for never having used Rust.
There's one they probably didn't provide - it's ugly
Or the most important one. Linus thinks it's a good thing
-
@Applied-Mediocrity said in The language everyone lies about loving:
Developers provided a variety of reasons for never having used Rust.
There's one they probably didn't provide - it's ugly
Compared to what?
-
@topspin said in The language everyone lies about loving:
@Applied-Mediocrity said in The language everyone lies about loving:
There's one they probably didn't provide - it's ugly
Compared to what?
Rakudo.
-
@izzion said in The language everyone lies about loving:
@Applied-Mediocrity said in The language everyone lies about loving:
Developers provided a variety of reasons for never having used Rust.
There's one they probably didn't provide - it's ugly
Or the most important one. Linus thinks it's a good thing
For him it probably is. Remember that the *nix world has been flailing ineffectively against the memory safety flaws in the C language for over 30 years now. But Linus's project bears very little resemblance to your project, for practically any given value of "your."
-
@dkf said in The language everyone lies about loving:
against Java or C# or Python, where programmers will just go "Needing to put lots of effort into lifetime tracking? When I have GC already?
Also if I need a counted reference, I can make or use one.
-
@Mason_Wheeler This might be a post for the embarrassing programming confessions thread but I don't even know how I would use Rust even if I wanted to. Did Visual Studio start supporting it or something?
-
@Zenith I see you're not with the cool kids who use VS Code and keep a permanent "Hide the pain, Harold" grin on their faces, because otherwise they'd be kicked out of the cool kids club.
-
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
The article doesn't actually say that.
The article said:
"despite developers' positive feelings toward Rust, 97% of them hadn't actually used it. "
And you said: "claim to love working with Rust"
"Positive feelings towards" != "claim to love working with"
The discussion was specifically about a StackOverflow poll where people voted Rust the "most-loved" programming language. Grow some reading comprehension already!You've conflated two things:
- Rust is the most-loved language
- 97% of programmers have never used it
This does not mean that 97% of the people who love Rust haven't used it. But I get what you're saying, at least.
-
@PotatoEngineer said in The language everyone lies about loving:
- Rust is the most-loved language
- 97% of programmers have never used it
- If the other 97% of programmers had ever used it, it wouldn't be the most-loved language.
-
@Zenith said in The language everyone lies about loving:
I don't even know how I would use Rust even if I wanted to. Did Visual Studio start supporting it or something?
Visual Studio 2008 certainly didn't
-
@loopback0 said in The language everyone lies about loving:
@Zenith said in The language everyone lies about loving:
I don't even know how I would use Rust even if I wanted to. Did Visual Studio start supporting it or something?
Visual Studio 2008 certainly didn't
Hey, I use 2012 sometimes! Sadly, that was about the last version with a load time under five minutes.
-
@dkf said in The language everyone lies about loving:
@JBert said in The language everyone lies about loving:
Maybe check if there are any updated numbers since then?
It's still going to have problems making headway simply because of the sheer size of existing codebases. And it won't make much progress against Java or C# or Python, where programmers will just go "Needing to put lots of effort into lifetime tracking? When I have GC already? Lolnope!".
Yeah...the low levelish nature of rust code vs java on performance, etc, wise would just not be worth it for enterprisey development.
-
@Zenith said in The language everyone lies about loving:
@Mason_Wheeler This might be a post for the embarrassing programming confessions thread but I don't even know how I would use Rust even if I wanted to. Did Visual Studio start supporting it or something?
It works with notepad if you’re into self-inflicted pain.
-
@PotatoEngineer said in The language everyone lies about loving:
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
@Mason_Wheeler said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
The article doesn't actually say that.
The article said:
"despite developers' positive feelings toward Rust, 97% of them hadn't actually used it. "
And you said: "claim to love working with Rust"
"Positive feelings towards" != "claim to love working with"
The discussion was specifically about a StackOverflow poll where people voted Rust the "most-loved" programming language. Grow some reading comprehension already!You've conflated two things:
- Rust is the most-loved language
- 97% of programmers have never used it
This does not mean that 97% of the people who love Rust haven't used it. But I get what you're saying, at least.Can I vote Charlize Theron my most-loved actress even though I haven't used her?
-
This post is deleted!
-
This post is deleted!
-
@Mason_Wheeler said in The language everyone lies about loving:
@izzion said in The language everyone lies about loving:
@Applied-Mediocrity said in The language everyone lies about loving:
Developers provided a variety of reasons for never having used Rust.
There's one they probably didn't provide - it's ugly
Or the most important one. Linus thinks it's a good thing
For him it probably is. Remember that the *nix world has been flailing ineffectively against the memory safety flaws in the C language for over 30 years now. But Linus's project bears very little resemblance to your project, for practically any given value of "your."
-
#iam3%
-
@Zenith said in The language everyone lies about loving:
This might be a post for the embarrassing programming confessions thread but I don't even know how I would use Rust even if I wanted to.
Step 1: https://www.rust-lang.org/learn/get-started
Step 2: IntelliJ IDEA with IntelliJ Rust plugin. Or CLion if you also want a debugger and are willing to pay for it. But you don't need a debugger all that much with Rust - compared to e.g. C++ almost every subtle bug is hard compile error instead, and compared to e.g. JS you don't have to wonder what fields and methods even exist in your objects.
-
@boomzilla said in The language everyone lies about loving:
@dkf said in The language everyone lies about loving:
@JBert said in The language everyone lies about loving:
Maybe check if there are any updated numbers since then?
It's still going to have problems making headway simply because of the sheer size of existing codebases. And it won't make much progress against Java or C# or Python, where programmers will just go "Needing to put lots of effort into lifetime tracking? When I have GC already? Lolnope!".
Yeah...the low levelish nature of rust code vs java on performance, etc, wise would just not be worth it for enterprisey development.
Rust being low-level is one of the biggest misconceptions about it. And this misconception is the main reason behind its slow adoption. Yes, technically speaking it has manual memory management. But in practice, when was the last time it really made a difference to you whether your GC is mark-and-sweep or reference-counting?
Rust is very high-level in all the ways that matter. Higher-level than Java, I'd say. In normal, non-system code, you don't have to think about the underlying platform at all. In normal, non-serialization code, you never have to read/write individual bytes at all. Primitive types have a whole bunch of methods, they even implement interfaces. Hell, you can make up brand new interfaces and make primitives implement them. You have typeclasses, extension methods, LINQ-like iterators, async/await, and type inference so good you sometimes forget it's a statically typed language until compiler yells at you. It doesn't have exception but there's enough syntax sugar to make you believe it does. And all the different language features and standard library functions fit together perfectly. And its build system slash package manager is super easy to use. Unlike Go, Kotlin, and other crap of that era, it actually feels like it was designed in 2015 by people who know what they're doing.
-
@Gustav said in The language everyone lies about loving:
@boomzilla said in The language everyone lies about loving:
@dkf said in The language everyone lies about loving:
@JBert said in The language everyone lies about loving:
Maybe check if there are any updated numbers since then?
It's still going to have problems making headway simply because of the sheer size of existing codebases. And it won't make much progress against Java or C# or Python, where programmers will just go "Needing to put lots of effort into lifetime tracking? When I have GC already? Lolnope!".
Yeah...the low levelish nature of rust code vs java on performance, etc, wise would just not be worth it for enterprisey development.
Rust being low-level is one of the biggest misconceptions about it. And this misconception is the main reason behind its slow adoption. Yes, technically speaking it has manual memory management. But in practice, when was the last time it really made a difference to you whether your GC is mark-and-sweep or reference-counting?
Rust is very high-level in all the ways that matter. Higher-level than Java, I'd say. In normal, non-system code, you don't have to think about the underlying platform at all. In normal, non-serialization code, you never have to read/write individual bytes at all. Primitive types have a whole bunch of methods, they even implement interfaces. Hell, you can make up brand new interfaces and make primitives implement them. You have typeclasses, extension methods, LINQ-like iterators, async/await, and type inference so good you sometimes forget it's a statically typed language until compiler yells at you. It doesn't have exception but there's enough syntax sugar to make you believe it does. And all the different language features and standard library functions fit together perfectly. And its build system slash package manager is super easy to use. Unlike Go, Kotlin, and other crap of that era, it actually feels like it was designed in 2015 by people who know what they're doing.
After writing a small server in Rust, I can't say that it's harder to use than Java either. I mean, it's significantly different and doesn't have the stupid large amount of libraries, but I didn't find it particularly hard. It seems built for the programmers, compared to, say, Haskell, that just gives me headaches.
-
@Gustav My impression is that it is very good at writing some types of code, and people who mostly work in domains where that type of code is prevalent think that everyone should use it. The problem with that is that there are other types of code that fit other problems better. That is why programming language evangelism is a bad idea: reality is more complex than most programmers' experience of it.
Rust does appear to have a good chance to displace the C++ dumpster fire. Eventually; there's literal billions of lines of code existing and that will take a long time to do even with management buy-in (not a done deal). Displacing C will be harder, because some of what C is used for is programming where the safety properties are extremely difficult to write in Rust (highly relevant in realtime work, for example). Displacing Java or C# or scripting languages will be much more difficult than that; they're mostly already memory-safe and are worrying about other problems entirely.
-
@Gustav said in The language everyone lies about loving:
@boomzilla said in The language everyone lies about loving:
@dkf said in The language everyone lies about loving:
@JBert said in The language everyone lies about loving:
Maybe check if there are any updated numbers since then?
It's still going to have problems making headway simply because of the sheer size of existing codebases. And it won't make much progress against Java or C# or Python, where programmers will just go "Needing to put lots of effort into lifetime tracking? When I have GC already? Lolnope!".
Yeah...the low levelish nature of rust code vs java on performance, etc, wise would just not be worth it for enterprisey development.
Rust being low-level is one of the biggest misconceptions about it. And this misconception is the main reason behind its slow adoption.
I wanted to comment on that, but figured I'd wait for you to say something more insightful about it (especially considering the OP of this thread).
As far as I can tell, it's a language you can use to build high-level abstractions over quite low-level code. Which does make it suitable for systems programming, but doesn't make all code low-level.Yes, technically speaking it has manual memory management. But in practice, when was the last time it really made a difference to you whether your GC is mark-and-sweep or reference-counting?
I wouldn't even call RC manual. It's 99% automatic if the compiler does the job for you.
Rust is very high-level in all the ways that matter. Higher-level than Java, I'd say.
But as I mentioned above, its demands on the programmer to have an idea what they're doing seems to be higher than some other languages. (Mostly compared to scripting languages, maybe not so much compared to other compiled languages.)
It doesn't have exception but there's enough syntax sugar to make you believe it does.
What's the situation with panics nowadays? I read something about writing "panic safe" code which felt basically the same as exception safe, and it appears that panics can be unwinding, so the non-aborting panics look like exceptions to me.
-
@dkf said in The language everyone lies about loving:
My impression is that it is very good at writing some types of code, and people who mostly work in domains where that type of code is prevalent think that everyone should use it.
It seems quite opiniated to solve the 95% use case, which is a good thing. If your problems just don't work well with e.g. the ownership model, then go for something else.
But I don't think anyone is really arguing for Rust to be a replacement of, say, Python.
-
@topspin said in The language everyone lies about loving:
But I don't think anyone is really arguing for Rust to be a replacement of, say, Python.
Nobody sensible is arguing that.
-
@dkf fair enough.
-
@dkf said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
But I don't think anyone is really arguing for Rust to be a replacement of, say, Python.
Nobody sensible is arguing that.
When is the last time you encountered someone sensible?
-
@HardwareGeek said in The language everyone lies about loving:
@dkf said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
But I don't think anyone is really arguing for Rust to be a replacement of, say, Python.
Nobody sensible is arguing that.
When is the last time you encountered someone sensible?
It was a breezy day in 1938, and I was drinking Red Bull like it was eventually going to come into style...
-
@HardwareGeek said in The language everyone lies about loving:
@dkf said in The language everyone lies about loving:
@topspin said in The language everyone lies about loving:
But I don't think anyone is really arguing for Rust to be a replacement of, say, Python.
Nobody sensible is arguing that.
When is the last time you encountered someone sensible?
Here?
-
@dkf said in The language everyone lies about loving:
@Gustav My impression is that it is very good at writing some types of code, and people who mostly work in domains where that type of code is prevalent think that everyone should use it. The problem with that is that there are other types of code that fit other problems better. That is why programming language evangelism is a bad idea: reality is more complex than most programmers' experience of it.
I thought so too, until I spent the last year building a GUI application entirely in Rust. It works surprisingly well.
Displacing C will be harder
I thought so too, until Linux kernel adopted Rust recently. The second ever language allowed in Linux kernel. After that, it wouldn't surprise me if more C projects went that way, especially the likes of OpenSSL who don't want another Heartbleed to happen. And it's rather easy to replace C with something else compared to C++, for the same reasons why it's easy to interop with C compared to C++. So I wouldn't be surprised if C++ ended up sticking around much longer than C.
because some of what C is used for is programming where the safety properties are extremely difficult to write in Rust (highly relevant in realtime work, for example).
That's what
unsafekeyword is for. Unsafe Rust can do everything that C can, and it's still safer than C. The only problem is that Rust uses LLVM, so it's constrained to platforms that LLVM can compile for. But GCC is already working on their own Rust frontend, so soon enough the problem will be that Rust is constrained to platforms that LLVM and/or GCC can compile for.It's kinda funny. Rust was originally meant to be full-blown functional language with full-blown GC and all that jazz, totally unsuitable for C-like code. But with a few small changes they managed to make it work runtime-less on bare metal, and now it has the reputation of being totally unsuitable for anything but C-like code.
Displacing Java or C# or scripting languages will be much more difficult than that
I'm literally displacing C# as we speak. I know, I know, anecdata. But an amusing coincidence.
Java and C# are memory-safe only in so far that you can't write over uninitialized memory or do incorrect downcasts. They won't save you from data races between threads or accidentally using already disposed objects. Rust will.
-
@topspin said in The language everyone lies about loving:
It doesn't have exception but there's enough syntax sugar to make you believe it does.
What's the situation with panics nowadays? I read something about writing "panic safe" code which felt basically the same as exception safe, and it appears that panics can be unwinding, so the non-aborting panics look like exceptions to me.
But yeah, in general nobody cares and panic=abort. Which is a good thing. And by "might not catch all panics", they mean that on some platforms, exceptions are super annoying to implement and they didn't bother.
-
@Gustav said in The language everyone lies about loving:
But yeah, in general nobody cares and panic=abort. Which is a good thing.
Seems unfortunate to me. Despite what the game dev weenies say, exceptions are actually faster (when not taken) than error code based stuff. (
Resultis spiritually just error codes, but with much saner ergonomics.) The only problem is the unwind table bloat, but that only makes it unsuitable for some embedded stuff.
-
@Gustav said in The language everyone lies about loving:
especially the likes of OpenSSL who don't want another Heartbleed to happen
"The likes of" OpenSSL are a prime candidate for things that should've switched to Rust yesterday already. However, what I remember from the reporting after Heartbleed, OpenSSL code is a nightmare and the maintainers unlikely to change that. The OpenBSD people forked it to throw away old trash.
-
@Gustav said in The language everyone lies about loving:
Java and C# are memory-safe only in so far that you can't write over uninitialized memory or do incorrect downcasts. They won't save you from data races between threads or accidentally using already disposed objects. Rust will.
You literally can't use disposed objects in Java; if you have a handle to them, they're not disposed. (Yes, there are — rarely used — weak references, but getting a normal strong reference back from those is runtime checked; that's nor a safety hole.)
The problem with Rust on inter-thread safety is that there are safety models it cannot express. You don't see it in coding for desktop or server systems due to their uncertain relationship with time, but TDMA is a very effective safety approach in realtime systems, and Rust cannot write that constraint. Rust assumes that locking is relatively easy to do, but on some architectures that's a hard No; it depends very strongly on the hardware memory consistency model (in ways that are rather complex and peel back many layers of abstraction).
-
@dkf said in The language everyone lies about loving:
@Gustav said in The language everyone lies about loving:
Java and C# are memory-safe only in so far that you can't write over uninitialized memory or do incorrect downcasts. They won't save you from data races between threads or accidentally using already disposed objects. Rust will.
You literally can't use disposed objects in Java; if you have a handle to them, they're not disposed. (Yes, there are — rarely used — weak references, but getting a normal strong reference back from those is runtime checked; that's nor a safety hole.)
There's also soft and phantom references, but given the wording I think he was talking about
IDisposable/AutoCloseable.
-
@dkf said in The language everyone lies about loving:
TDMA is a very effective safety approach in realtime systems, and Rust cannot write that constraint
But that's firmly in the < 1% use case.
-
@topspin said in The language everyone lies about loving:
But that's firmly in the < 1% use case.
Like Rust
-
@dkf said in The language everyone lies about loving:
The problem with Rust on inter-thread safety is that there are safety models it cannot express. ... but TDMA is a very effective safety approach in realtime systems
I don't think you have to reach that far.
It doesn't seem like Rust will help you with lock-free style shared-memory data structures, e.g., that you manipulate via atomic or whatever. Maybe you can rephrase the problem by using a pile of atomic types, but the hard part is outside of those.
-
Gee, it’s almost like it picked a problem to try to solve in the general case and that the fact it doesn’t try to solve all the edge cases is actually a feature…
-
@cvi said in The language everyone lies about loving:
It doesn't seem like Rust will help you with lock-free style shared-memory data structures, e.g., that you manipulate via atomic or whatever.
It does, actually. Rust has Send and Sync traits (very very special pair of traits that are mostly auto-implemented). Send means your type is safe to be moved from one thread to another (e.g. regular Rc smart pointers are not Send because the ref counter isn't atomic, but Arc has atomic ref counter so it's Send). Sync means that it's safe to access object through immutable references from several threads at once. By default, all types are Send+Sync. You can explicitly mark type as !Send and/or !Sync if needed. Then every type that contains your type as a member automatically becomes !Send/!Sync, unless they explicitly re-implement it (requires
unsafekeyword). You can even selectively implement it based on generic arguments (e.g. Arc<T> is only Send if T is Send+Sync. I don't know why it doesn't disallow !Send/!Sync outright but here we are).Immutable reference doesn't always mean the data itself is immutable. Rust allows interior mutability through UnsafeCell type. As the name suggest, it's
unsafeto use. It's also !Sync. But there are safe wrappers around it, like Cell and RefCell. They don't require unsafe code but they're still !Sync. There are also dedicated atomic primitive types that can be modified only through atomic operations. They have UnsafeCell inside but they explicitly implement Sync. There are also 3rd party crates (libraries) that allow atomic operations on more complex types, e.g. ArcSwap. You can implement your own if needed. The standard library extensively uses trait bounds on all thread-related functions to make sure Send and Sync actually means what it's supposed to. 3rd party crates too unless they fuck it up (but to date I've never seen such a fuckup).What this all means in practice:
- All global variables are either constant or atomic.
- A bunch of wrapper types available for both locking and lockless synchronization on whatever data you want - and you can make your own if needed.
- If you can modify some object from a given thread, it's virtually guaranteed it's safe for that thread to modify it at any time it has access to that object.
- Fearless concurrency yadda yadda.
- TDMA cannot be safely implemented, but that's what
unsafeis for. Some compile errors are disabled then for a given block of code, and if you're careful about what you're doing, you won't trigger any UB either - exactly like in C except better because unsafe Rust still has more compile-time checks than C.
-
@topspin said in The language everyone lies about loving:
@Gustav said in The language everyone lies about loving:
But yeah, in general nobody cares and panic=abort. Which is a good thing.
Seems unfortunate to me. Despite what the game dev weenies say, exceptions are actually faster (when not taken) than error code based stuff. (
Resultis spiritually just error codes, but with much saner ergonomics.) The only problem is the unwind table bloat, but that only makes it unsuitable for some embedded stuff.On one hand, yes there's a tiny performance drawback (that can be eliminated with profile-guided optimization). On the other, Results are much more convenient to work with than exceptions. You are less tempted to ignore them, handling recoverable errors requires less code thanks to chaining methods, you can easily convert between Options and Results, there's always only one type of error object per function, never-failing functions are marked as such with zero extra effort, and you don't have a bunch of whiny bitches whining about having to declare their checked exceptions.
catch_unwind in std::panic - Rust
