In Rust we trust? Yes, but we want better tools and wider usage, say devs

"The overriding problem hindering use of Rust is adoption," according to the language's official survey, with some developers struggling to be productive and hampered by limited IDE support. Rust is the "most-loved" language, the StackOverflow research says, and has been for four years in a row, but the new study shows that …

[bombastic bob]

despite the enthusiasm of developers [snip] adoption remains limited

I'd like to see more on this...

Otherwise it's starting to remind me of ADA [and why ADA was not widely accepted as a 'language of choice' for new development]

So I'm sticking with C, C++, PHP, and occasional Java and Python [and Javascript ONLY when other choices make very little sense] until there's some really compelling reason to pick a language like Rust.

(nice article though - provokes thought)

[DrXym]

Re: despite the enthusiasm of developers [snip] adoption remains limited

The compelling reason for Rust, is that eliminates bugs that plague software written in C or C++ such as null pointer exceptions, double frees, buffer overflows, data races. These can crash software or compromise its security - look at the Common Vulnerabilities & Exposures (CVE) database for examples.

As it's a compiled language it also has similar performance to C or C++. Whether that matters to you largely depends on what you are writing. If your game crashes it's merely a nuisance. If a critical component of your server crashes then it could mean much more.

[Anonymous Coward]

@DrXym Re: despite the enthusiasm of developers [snip] adoption remains limited

If you ever have to interview a developer, ask them to talk about their favorite programming language.

Ask them to name one thing that they absolutely love and one thing that they absolutely hate.

There is no right/wrong answer, but it will give you valuable insight into the candidate. ;-)

That said... C and then C++ really require those who develop to be very skilled at their art.

You will see a lot of the NPE, Memory Leaks drop off when the developer takes the time to craft their code properly.

The problem of course is that this is the minority of trained developers and very few want to pay for this level of expertise not to mention the amount of work outstrips those capable of doing the work properly.

That's why you see a dumb-ing down of the languages.

I'd look at Rust or other languages, however I've been pushed up the corporate ladder to a point where I'm not allowed to code anymore.

Mines the jacket with the key to the executive washroom that isn't an illicit copy, it its pocket. . ;-)

[DrXym]

Re: @DrXym despite the enthusiasm of developers [snip] adoption remains limited

The reality of programming is your team will have people at different skill levels and even the most skilled will make mistakes from time to time. I've programmed C and C++ for 25 years now (amongst many other languages) and I am modest enough to admit I make mistakes. I would be scared of anyone who claims otherwise. And as I said you only have to look at the CVE database (or any open source project's bug tracking) to see a multitude of errors happen for all the reasons I cite. In some cases, those bugs can be damned hard to find, for example if the heap gets corrupted and it only manifests somewhere else in the code. And that translates into slower time to market and more bugs including firedrills.

As for this developer you're interviewing. I would hope for them to express an interest in learning new technologies and keeping their skills fresh. Whether that be Rust, Go, Swift or some new framework. Something that demonstrates a flexibility and an interest in learning.

[James 47]

Re: despite the enthusiasm of developers [snip] adoption remains limited

Our server code is written in C++ and I can't remember the last time we had a crash or a memory leak. I'm not saying we're perfect but C++ has come on leaps and bounds since C++03. Rust protects you from this unless you go 'unsafe', and the devs that can still make modern C++ crash and leak will probably get to do the same in Rust.

That said, what will get Rust more widely used is the 3rd party libraries / source code. With C++ it's a pain and that random HTTP parser you cloned from github may not be the best quality.

Also, networking. C++'s ASIO stuff is a headache, I'd be surprised if Rust is in a similar boat. I'm considering dropping ASIO altogether and going straight to using io_uring.

[Anonymous Coward]

Re: despite the enthusiasm of developers [snip] adoption remains limited

"C++ such as null pointer exceptions, double frees, buffer overflows"

Code written in modern C++ (2011 onwards) doesn't have to suffer from any of that as all the containers you need to avoid manual memory allocation and raw pointers are there for you. And the bonus is that if you DO need raw pointers - for example when accessing H/W direct or doing other low level twiddling - then you still have them too.

As for data races - threading and multi process IPC is a black art which many people think they've grokked but often haven't and so leave nasty little once in a blue moon gotchas in their code. I doubt thats any different in Rust for any significant complexity of code as there's only so much the language and OS can do for you.

[DrXym]

Re: despite the enthusiasm of developers [snip] adoption remains limited

I've seen code where somebody has reset a raw pointer into a scoped pointer or screwed up a copy constructor and had issues. I've see plenty of null pointer exceptions. Buffer overflows are less common but they happen if you you're reading into a raw buffer and mess something up. While it is a good idea to use smart pointers, arrays etc. the reality is the compiler doesn't care if you use them properly and programming reality frequently means you can't (e.g. calling somebody else's library).

Rust prevents data races stone dead. You CANNOT share data between threads unless you protect it with a mutex or a read/write lock and you CANNOT access the data until one thread first locks the data. If you attempt to share data between threads you will get a compile error. So not only does Rust stop data races, it does so at compile time. Rust also moves on assignment by default so if you want to send messages where the message has a payload between threads, that's safe too.

[Anonymous Coward]

Re: despite the enthusiasm of developers [snip] adoption remains limited

"You CANNOT share data between threads unless you protect it with a mutex or a read/write lock and you CANNOT access the data until one thread first locks the data."

Nice idea in theory but I suspect horrendous for performance in practice when dealing with read only data.

[diodesign]

"horrendous for performance in practice when dealing with read only data."

If you're just reading data with threads, the compiler realizes this, and you can share without a mutex. Rust has a concept of mutability. You declare a variable mutable (writable) or immutable (read only). Multiple threads can access an immutable variable without a lock.

If you want it to be mutable, you need a lock.

Rust is really cool.

C.

[DrXym]

Re: despite the enthusiasm of developers [snip] adoption remains limited

Use a read/write lock then and open the lock and keep it open for the duration that you want to use the data, i.e. in the scope of the thread using it. The penalty is minimal and none of the threads are going to be blocked because they're all using read locks too.

[cornetman]

I wonder if one of the reasons why people find Rust so difficult is that it forces us to think about things that many programmers gloss over, which is why traditional programs are so bug ridden these days.

Programming really well is HARD and I suggest that some people are just not capable of doing it. Rust just makes you think about some of the things that we are no accustomed to thinking about so completely and comprehensively. What should this code do if a memory allocation fails? Just what is the full lifecycle of this object?

I have looked into Rust from the perspective of a C/C++ programmer and I happen to think it is a breath of fresh air. Just a shame I cannot convince where I work to give it a try. I think we here are in the same boat as many C++ shops in that we have a lot of investment in the older languages and the risk of moving into something fairly new in product areas that are already highly developed is difficult to justify.

[DrXym]

That's exactly it. The C/C++ compiler is very limited trusts the programmer knows what they're doing even if they write horrible code which turns into bugs later on. The Rust compiler kicks their ass a lot harder at compile time. The language itself is designed to stop common gotchas in other languages, e.g. there is no magic NULL value.

That makes the learning curve a lot steeper, trying to figure out why the compiler is being so anal about stuff but when you get past it, it's no more hard to write Rust than another language. In fact, my experience of writing Rust is that I'm more conscious of avoiding certain anti-patterns in C or C++. So there is a positive feedback all around.

[Anonymous Coward]

If a developer needs an IDE to be productive

Then frankly he's a poor developer who obviously needs electronic nannying to understand the code he's working on. I develop C++ on *nix and I'm quite happy using the command line toolchain - vim, make, gcc, gdb, strace etc.

[diodesign]

"vim, make, gcc, gdb, strace etc"

I mean, you are using an IDE, it's just rather loosely integrated.

C.

[Brian Miller]

Re: "vim, make, gcc, gdb, strace etc"

But that's the environment I've been using with Rust, just not with gcc and make.

I have used Rust a bit, and I've found that I can get a mutex lockup using their standard library. Really, sometimes a mutex doesn't release when it's supposed to. I've had no problems with the parking_lot mutex, though.

The language is tricky, and the "helpful" error messages can very quickly lead a person astray. The checking up front is great, and there's other good concepts.

[Anonymous Coward]

Re: "vim, make, gcc, gdb, strace etc"

More like not integrated at all which means != IDE. I'd sooner deal with the OS itself via the shell when developing than some GUI interface which IME from having to use Visual Studio and Eclipse in the past often just got in the way of what I wanted to do. Eg: Simple things such as changing library or include paths in a Makefile are a convoluted nightmare in VS - so much so I wondered if it was deliberate in order to stop you messing about with them once your project had commenced.

[James 47]

Re: If a developer needs an IDE to be productive

Same boat as you but I used QTCreator just for code writing. They do actually help productivity.

But yes, gdb, make etc are still from the terminal.

[Elledan]

Got tools?

As a senior C++ developer and part-time Ada (among others) developer, my 'IDE' is either Notepad++ or Vim, and I use gdb, Valgrind, etc. on the CLI.

Perhaps ironically, I used to heavily use IDEs in the past, including Visual Studio 2010 Pro. Over the years I have moved away from all of those, as I didn't se the perceived benefit of using IDEs.

Maybe I'm just an odd-ball, but I see IDEs more like something that Java, Kotlin, JavaScript and Python developers would demand.

As for Rust itself... I looked at it, poked at it a bit, but to me it feels like someone mashed Python and C++ together, along with a few other weird choices (no OOP) and missing every single reason why Ada is the best and safest language out there (ergo it being used for avionics, etc.).

[Anonymous Coward]

Thoughts from an old fogey

First let's take as a given that everyone here can write better code than everyone else here, not to mention everyone not here.

That said I see many comments about what Rust won't let you do, about how it is a dumbed down or nanny language. Frankly that's a bad attitude.

If you are writing something for yourself, no worries. But chances are you're not and your code will need to be picked up and modified by someone who doesn't know you exist. A language that doesn't let you get weird will yield a program that can outlast you.

Certainly there are a few, a very few, cases where some C version functionality is required. For that matter there are a few that require assembly language. But for the overwhelming majority of applications maintainability is key.

So accept dumbed down because the next person who touches your code might not be as experienced or even as smart as you.

[Elledan]

Re: Thoughts from an old fogey

So you're making the argument that everybody should not be using Rust, but Go?

Because by those metrics, Go is a far better choice than Rust, providing memory safety and overall restricting what one can do. See for yourself: https://en.wikipedia.org/wiki/Go_(programming_language)

[Anonymous Coward]

Re: Thoughts from an old fogey

To be honest you could use his argument to suggest that everyone should be coding in VB. I'm afraid I have little time with the "keep your code simple so idiots can maintain it" argument. Sometimes code needs to be complex and if the company is using idiots to maintain a complex system then thats on then, it shouldn't be a concern of the original developer. Thats not to say that code shouldn't be clear and well commented however , just that you shouldn't avoid certain algorithms or patterns just because others might not understand them.

[Anonymous Coward]

Rust is loved and its language design widely admired

Reminds me of Eiffel. Anyone else remember this dead end?

[Addanc]

Re: Rust is loved and its language design widely admired

Object Oriented Software Construction by Bertrand Meyer, top book on OO.

[Sam Liddicott]

The biggest problem with rust is 3rd party library authors (or authors of wrappers) lying about ownership transference for those cases where Rust can't work it out -- thus undermining all the guarantees of rust.

[B83]

Realistic business scenario

I've looked at RUST and enjoyed working with it i.e. dabbling about, but I dont see any reason for it in my work. Admittedly I am database driven and spend most my time creating tables, ETL, stored procedures, etc. I do use other languages along with SQL i.e. C#, Javascript, VBA, yes VBA its going nowhere fast :), and python. All these languages have a use at my work but RUST just does not fit in. This leads me to my point, everyone else I have spoken to have heard of RUST but have no intention of learning it as they are in the same boat as me i.e. no real reason to use it, no business scenario that requires this language. They also see it as a very bespoke language that does not lead itself to any work projects.

RUST needs to be able to appeal past the in-depth/hardcore developer a bit of PR is required to try and sex it up a bit. If you can sex up code that is!

[DrXym]

Re: Realistic business scenario

Rust is a systems programming language. The basic rules of thumb of where it would be used are:

1. Would I otherwise have to use C/C++ to achieve the speed, low-level access or scalability of what I wanted to do but with a lot more stability / security? Examples might include be embedded systems, constrained devices, operating systems services / daemons, long running servers, games, factory control systems, automotive systems etc.

2. My high level language is too slow and I want to rewrite some or all of it in something faster. Example would include people using Python or NodeJS and discovering bottlenecks in their pipeline that they want to fix by using a library.

It's not much use if you're writing scripts, stored procedures or anything high level. Although having said that, Rust will get a lot of use for people writing Webassembly modules where applications suffer bottle necks or other issues from writing the same code using JavaScript.

[Elledan]

Re: Realistic business scenario

Considering that Rust is a weakly-typed language (akin to Python), I'd not want to use it over C++. While one can use strong typing in Rust, it is completely optional, with the default Python-like inferred typing the default.Using strong typing in Rust requires a significant amount more code, which makes what comes by default an error-prone business in Rust.

This in addition to the symbol soup Rust introduced instead of normal English phrases (like Ada) and a highly complicated 'alternative' to OOP and classes which has a beyond vertical learning curve, inviting even more errors in one's code.

Basically, just use Python or C++ (or Ada). But not Rust. Maybe use Go, if you really need to.

[noisy_typist]

Re: Realistic business scenario

Rust is a strongly typed language.

[cornetman]

Re: Realistic business scenario

> Considering that Rust is a weakly-typed language

What on earth made you think it is a weakly-typed language?

[Sp1tf1r3]

Evil Corp

So, Google who created Go, don't recommend using Rust, I wonder why that is.....