Ask Slashdot: Is it Practical To Replace C With Rust?

interval1066 writes: I've heard of rust from various sources around the net for a few years and never paid it much mind, there are so many new languages out now since my early days doing C programming, which what I've stuck to and made me my career. Now I'm heading a project that uses a RoR application to control a large series of sensors and controls in a manufacturing process. Naturally I want to talk to the hardware using a GEM extension written in C, as I've done before.

But another engineer who is not a fan of C (seems few younger engineers are) said he could write the extensions needed easily in Rust. Seems like this is a thing. I took a closer look at rust and it looks to me like another attempt at "C" without pointers, except rust does have a kind of pointer, it appears. I like its ranking on a list of fastest languages, and it seems pretty simple with an initial tool footprint that is quite small.

But what are the trade offs? Another language, and one that few engineers know (much like Vala, which I like very much but has the same small user base). What if I need another engineer to work on the code? I pretty much know what I can expect from C/C++, rust is a huge unknown, what if I run onto a roadblock? The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?

Comments

You know the old saying...

[__aaclcg7560]

No one ever got fired for using C.

Re:You know the old saying...

[cruff]

No one ever got fired for using C.

Someone at Volkswagen might.

Re:You know the old saying...

[transfire]

There is always risk with embracing new tech, but I would be willing to bet you won't be disappointed with Rust.

Re:You know the old saying...

[__aaclcg7560]

I don't think you can blame the programming language for that one.

Re:You know the old saying...

[Mirar]

I thought Bosch wrote that code and told WV not to use it like that. Anyway, it's probably written in Simulink.

Re:You know the old saying...

[hawguy]

No one ever got fired for using C.

That phrase has also been used for heyday IBM and Microsoft. But both sucked.

Sometimes you have to choose between money and sanity.

It used to be true of IBM -- as long as you were willing to pay, you could get near perfect uptime and nearly unlimited scalability. But you definitely had to pay for it -- we had a dedicated IBM service rep with an office in our data center, that sort of service doesn't come cheap. But we had no significant downtime in my 4 years there. Sure we had some jobs fail here or there due to DASD failures, but the core mainframe never had a hiccup and we completed several online hardware upgrades with no downtime.

Of course, I can get even better scalability and uptime with a distributed system (geographically distributed) on commodity hardware today, but that wasn't always a viable option.

Re:You know the old saying...

[shaitand]

C has it's ups and downs but sucking isn't one of its properties.

Re:You know the old saying...

[DutchUncle]

No one ever got fired for using C.

That phrase has also been used for heyday IBM and Microsoft. But both sucked.

Heydey IBM didn't suck. You whippersnappers just don't appreciate what we had to do on mainframes to lay the groundwork for distributed computing. A lot of the ultra-modern pipelining in processors can be traced directly to Cray and Amdahl and other designers from the golden age, and if they could have had as much spare hardware and memory as a modern system-on-chip without blowing up both a bank and the power grid, who knows how much further we'd already be.

Re:You know the old saying...

[willworkforbeer]

Heydey IBM didn't suck. You whippersnappers just don't appreciate what we had to do on mainframes to lay the groundwork for distributed computing.

And in those day, laying groundwork was uphill. Both ways.

Re:You know the old saying...

[Beck_Neard]

I know that's a joke, but it's of course nonsense. Plenty of people have gotten fired for using C, especially when their code had dangerous security vulnerabilities (which it ALWAYS does).

Re:You know the old saying...

[pdxtabs]

This is very true, but...

I am a Senior Embedded Software Engineer at a Fortune 500 company. I work on a code-base of millions of lines of C with 300 of my closest development buddies who are located all over the world. The distribution of abilities is as you would expect with this statistically significant sample of developers. I spend a lot of my time tracking down tricky memory corruption bugs in C by hand that would have been caught by the Rust compiler. What's more, dangling pointers and buffer overflows are the worst kinds of bugs because they often lead to security vulnerabilities.

An excellent engineer can write excellent C, but a poor engineer can overflow buffers and leave dangling pointers hanging around... but not in Rust.

Re:You know the old saying...

[Tablizer]

It think it's safe to say that C as a language is optimized for speed, size, and hardware issues instead of software engineering issues.

Re:You know the old saying...

[gweihir]

On the minus side, a poor engineer will not even be able to do Rust at this time, so Rust benefits form that you likely get better people as you either have to get one of the very few people that can do Rust or get one that can learn it fast.

That said, do not mix languages on a large project unless you have to. And of you really go Rust, make sure you have more than one engineer who can work with it. Also counting against Rust is that it is too new.

I would also say that the person insisting on Rust is acting hugely unprofessional and trying to push his personal agenda on the project. That alone would be a valid reason to "bulldoze" him.

Re:You know the old saying...

[TheRaven64]

It's optimised for speed, as long as your target is basically a fast PDP-11. C does not allow the compiler to rearrange data layouts, which makes it hard to take advantage of SIMD or to avoid false sharing. C makes it very hard to statically reason about memory ownership, requiring a defensive programming style with redundant operations when writing multithreaded code. C only recently had a memory model for concurrent accesses at all and so most multithreaded C programs contain undefined behaviour.

Re:You know the old saying...

[TheRaven64]

An excellent engineer can write excellent C, but a poor engineer can overflow buffers and leave dangling pointers hanging around... but not in Rust.

A poor developer will write C code that doesn't work at all. A mediocre developer will write C code that works, but is rife with security vulnerabilities. An excellent developer will write C code that needs an excellent attacker to exploit. Unfortunately, the world has quite a lot of excellent attackers in it.

Re:You know the old saying...

[luis_a_espinal]

It takes work to write safe code in C.

Same with Java and even Ruby - Null refs, running out of mem, not closing database connections, etc - things that also characteristics of unsafe code. I've done the lot of it, C, C++, Assembly, Java, Python, what have you. For e-commerce as well as low level stuff.

And I've seen unsafe code written in all of them. Treating pointers as ohhh-chupacabara! is just ridiculous. People who program with discipline avoid those problems, whether they program in C or Python or what have you.

Your worst developers will use uninitialized variables, pointers to previously freed memory, and overflow buffers. But not in Rust.

Don't worry. Your worst developers will find ways to create unsafe code in Rust in one way or another.

Re:You know the old saying...

[TemporalBeing]

I know that's a joke, but it's of course nonsense. Plenty of people have gotten fired for using C, especially when their code had dangerous security vulnerabilities (which it ALWAYS does).

Wrong.

Yes, people have been fired for being bad programmers. I doubt many have been fired over security vulnerabilities, most likely because either (a) the vulnerability was discovered after the programmer already voluntarily left or (b) was rooted in standard operating procedures (e.g you just don't do that) - most due to people not realizing the consequences of network computers. (Prior to networking, security didn't really matter too much outside of specialized environments.)

Further more, C-based software probably runs about 99+% of devices out there - most notably everyone's favorite OS kernel - Linux - is entirely written in C, as is the Windows NT Kernel, the BSD Kernels, etc. Most all operating systems use it at the core, and many applications use it - IOW, the world runs on C; aside from Assembly is it probably the most used programming language out there when you look at all aspects of software (even C++ doesn't compare). It only bites you if, like with any tool (including Java), you mis-use it. Best practices will save you from 99.99% of issues.

Oh, and the OS's that don't use C in their kernel? They're all research or hobby stuff that more or less proves you could do it, but the performance is so abysmal (compared to the same thing in C) that no one would really use it, or they use C to bootstrap and load into their alternative language - typical of C++ OS Kernels. (Yes, there have been Java-based Operating Systems; they also relied on specialized hardware-based JVMs and no one uses them outside of small research projects.)

Cant we just talk directly instead?

[Anonymous Coward]

Im just 2 cubicles away from you, sad i read about it here

Is it practical to keep developing in C?

[Anonymous Coward]

You should definitely investigate rust. It's very well designed. It has great support to call into C code and C libraries. It compiles fast. The standard library is much more convenient than C/C++. You have complete memory safety by default, without garbage collection. It has great support for safe multithreading. Over time, your speed will increase because you won't be spending weeks tracking a heisenbug due to memory corruption. There is some learning overhead, but it's worth it.

The biggest issue is that you won't have as big of an ecosystem around rust. You won't find good support for all of the libraries that you might want to use. But those problems aren't insurmountable.

pointers & C

[Skewray]

The whole point of C is to be close to the hardware. The hardware has pointers. Why obfuscate?

Re:pointers & C

[serviscope_minor]

Sigh.

Rust does have pointers and it is close to the hardware. It has a very similar machine model to C and of course C++. It also has an advanced, modern type system that disappears during compilation which makes large classes of error which are easy in C flat out impossible.

It's not obfuscation. You're telling the compiler what your intent is and the compiler checks that you're doing what you say.

To the OP: it might not be a bad idea. Though if you're considering C and Rust, you really ought to have C++ on the table. It's got the same resource footprint as the other two. You can be much less foot-shooty in C++ than C if you use modern style (no loss of efficiency either), and the tooling is much more mature than Rust.

There's really no reason ever to use C over C++ if you have a C++ compiler available.

Re:pointers & C

[Anonymous Coward]

Obviously C has abstraction to some degree from the hardware, or you'd just use assembly. So you're basically arguing "C has what C has, so why wouldn't you use C?"

The answer is because there are problems with C, including pointers. If you pass a pointer to a child thread in C, what happens when you write through that pointer in the main thread? You're not required to use locks, and you're not required to remember that you don't own the pointer any more, so it's very easy to make a mistake and use a pointer when you're not supposed to. That's not so in Rust.

Just like static typing eliminates an entire class of error that you find in dynamic typing, Rust's borrow checker eliminates an entire class of error that you find in other languages. To pretend that there's no reason to look for an alternative to C is pretty ridiculous.

Re:pointers & C

[lgw]

The reason for empty destructors is that destructors that actually clean up resources are usually a bad idea. (Debugging-related stuff in destructors is different.) The "allocate in the constructor, clean up in the destructor" pattern was a natural evolution from well-written C code. If you were used to "allocate at the top of the function, clean up at the bottom", it was the obvious better approach. But it's still just as error-prone (just fewer places for errors), and the fact that the destructor doesn't get called if the constructor throws isn't broadly internalized by coders (and is my least-favorite intermittent resource leak to run down).

Having very small resource-specific classes, similar in functionality to auto_ptr or unique_ptr (just managing a file handle or whatever instead of memory allocation) is the better answer. Only clean up a resource in a class whose only purpose is to clean up a resource. Using those primitives as members in other classes, or as local variables, is as idiot-proof as C++ gets.

The resource-leak headaches saved by difference in approach is amazing when junior coders are involved, it's really a difference in kind. And it's dead easy to police in code-reviews. The last time I did C++ we had a single, templated class in library code, and nowhere else in the code base was a non-trivial destructor allowed. (Odd cases like adding an object to a global list, and removing it on destruction could be managed within this system.)

Re:pointers & C

[serviscope_minor]

The only benefit C++ arguably has over C in terms of avoiding common pitfalls is the STL and automatic destructors.

That's like saying the only thing we have better than the 1500s is electricity and internal combustion engines.

And if you follow a strict RAII pattern in C code, the lack of automatic destructors is much less of a burden.

But why bother? Do it in C++ and you get the same resource usage but with 1/10 of the typing and 1/10 of the bugs.

Every line of code you write is a potential bug. In C++ you can program the compiler to write them automatically for you bug free every single time.

Actually, the #1 reason not to use C++ is because if using C seems too tedious, then you should really consider using a higher level language altogether.

The lack of resource management makes C very tedious. C++ does it better than many other languages.

Re:pointers & C

[HiThere]

I'd settle for something good on how to use unicode with C OR C++. Saying "use ICU" doesn't help when there's no decent documentation on using ICU. After looking over the C++11 standard carefully, it looks as if it *is* possible to use unicode with C++, but it's still not clear how. Were I already an experienced C++ programmer, perhaps the discussion of facets would make sense. As it is...no. And there don't even seem to be any decent examples.

Most of the libraries for using unicode aren't sufficient for my needs. I need to be able to determine the general character class of each codepoint. (Actually, I only need the first letter of the general character class.) Every library seems to do this differently, and none do it intelligibly. This was easy in python, and feasible in Java (there were other reasons why those weren't preferred) but doing it in C++ *seems* not to be supported. The documentation says that it actually *is* suported, but how to do it is not obvious.

In Rust getting the character code is fairly easy, but walking a file directory seems to be unsupported. (Well, I think they supply all the pieces needed to build a directory path walker, but I'm not real sure. I keep ending up on paged marked "experimental" or "deprecated".)

That said, and if I can work my way past a few problems, Rust looks better than C because it allows owned data to be moved between threads. (Well, I think it does, and does it relatively simply.) C and C++ don't even have the concept of data dynamically becoming immutable. Thread local isn't the concept I'm after, though I need for all mutable data to be thread local...which is easy in Rust and difficult in C and C++. (Yes, I know you can do it. But you need to keep careful track of what needs to be marked thread local.)

OTOH, I haven't written anything original in Rust yet. I'm still studying to be sure that all the pieces I need are actually present. I haven't yet checked database access, or whether I can actually transfer immutable structs between threads easily, or whether I'll need to Box them, etc. And I'm certainly making no comment on either its compilation speed or its execution speed. (I've only run small test programs that I copied.)

This got a bit too long, and I'm not THAT experienced with C++, much less Rust, but my current evaluation is that for certain classes of programs Rust is a superior choice, and for other classes C++ is superior.

P.S.: Rust has just been released at 1.0, and I think prematurely. The absence of a directory walker program (that isn't marked either experimental or deprecated) is on reason why. But it still looks like a very good language for certain classes of program, even though it needs considerable development.

Re:pointers & C

[Ateocinico]

Since C++11 the destructor invocation in case of an exception is guaranteed. http://www.stroustrup.com/bs_f...

Re:pointers & C

[serviscope_minor]

C++ adds gives the writer the ability to use virtual methods very easily, you're kind of tying one hand behind your back if you don't use polymorphism

That's one of the easier things in C: just put a function pointer in the class, one function pointer for each method. Of course then you need a whole vTable per class, where as C++ has a single pointer to the vTable and then one copy of the vtable. The idiomatic C way is much more bloated.

so then you start getting bloat with your virtual tables, which can become quite massive.

Not a problem I've ever had, but I'm not a fan of deriving everything from everything else as was popular at one time. My code has very few virtual methods.

I don't think C++ is appropriate in many embedded applications.

Name one. It runs just fine on an ATTiny. Doesn't get much smaller than that.

Re:pointers & C

[TemporalBeing]

The only benefit C++ arguably has over C in terms of avoiding common pitfalls is the STL and automatic destructors.

I probably do more C and than C++ when writing C++ code. I typically use C++ classes (abstract, etc), namespaces, and (now) STL. This just helps with segregating the code into their logical parts so structure X doesn't get used on functions only meant to manage structure Y or data type Z.

new/delete? Well, I'll use them for classes only. Structures get allocated with malloc/free. Yes, a class is only use for data+functions and structures are only used for pure data; allocation patterns follow this same methodology which enables easy transition between pure C and C/C++ code when necessary. If a class allocates data, then I also provide an API in the class (typically instance agnostic) to clean it up to ensure that there is one-place that cleans it up, ensuring that the same allocator/destructor methods are used.

I also stay away from streams when I have a choice, and prefer C-style printf/scanf processing.

So there are useful bits in C++; you just have to find the right balance. Doing so makes for very easy to maintain code.

It's not already rusted?

[bluefoxlucid]

C is pretty rusty.

Re:It's not already rusted?

[gstoddart]

One might say 'crusty'.

No.

[Anonymous Coward]

No.

Re:No.

[phantomfive]

Rust has been developed by Mozilla for a specific problem they have, and their specific coding style. As far as I can tell it, works well for them and is a fine language.

Unfortunately, it's still in the "growing" stage of languages, and may never make it out of Mozilla world, and Mozilla themselves might even drop support, which means you're in trouble.

When you're choosing a language, you have to look at the entire ecosystem surrounding the language. It's not enough to look only at the language itself.

Re:No.

[ClickOnThis]

No one expects an obscure new language to gain mind-share without a good reason.

There is one crucial element to a new language gaining support: expressive power. Does it let you to express the solution to a problem in a better way than others?

Actually, there are two elements: expressive power and viable cross-platform support. Compilers and/or interpreters must perform well and be available for all platforms that matter.

Well, really there are three elements ... uh ...

I'll come in again.

kids these days...

[Anonymous Coward]

They don't like C because they haven't been taught it properly and instead go for things that are just trying to re-invent the wheel. Tell this guy to STFU, read a copy of the K&R book, and then get back to work using the native language of *nix.

Re:kids these days...

[fahrbot-bot]

They don't like C because they haven't been taught it properly and instead go for things that are just trying to re-invent the wheel.

... and C is hard and makes you have to think and stuff.

Re:kids these days...

[Eythian]

Rust is probably harder to get to grips with then C. The difference is that when you screw up in rust, it usually yells at you. When you screw up in C, it blithely goes on doing what it thinks you want.

Community Support

[freak0fnature]

Where I am they chose SpineJS a few years ago, looked like a great language, easy, etc. After a few years, one thing we noticed was the lack of online help when you run into issues. It's just not that widely used. Rust is ranked 49th on Tiobe. Maybe it will be the next best thing, but if it isn't, you'll be stuck with something that has little community support.

Re:Community Support

[dmoen]

The SpineJS repository has 4 contributors. The Rust/Lang repository has 1,188 contributors. (on github)

It's not the language itself...

[DrTJ]

... that determines its success or not in a non-nieche segment.

It's the mass of developers that already know it, it's the accumulated code base (both locally and globally) and most importantly: the eco system of tools surrounding it: the compilers, the IDEs, the debuggers, the static/dynamic code analysis, build systems, code generators, mock tools, coverage tools etc.

The new kids on the block have a lot of catching up to do in areas which are not directly language related.

Portability

[Locke2005]

If you're ever going to be porting it to another platform, then do it in C; there are C compilers available for almost every piece of hardware out there. If you're certain it only needs to run on a single, unchanging platform for the lifetime of the code, then using Rust might be a good idea.

Re:Portability

[Trepidity]

Yeah, for now this is one of the bigger drawbacks. The officially supported platforms are:

Windows (7, 8, Server 2008 R2)

Linux (2.6.18 or later, various distributions), x86 and x86-64

OSX 10.7 (Lion) or greater, x86 and x86-64

There is supposed to be ARM support in the works.

Re:Portability

[garethjrowlands]

What you say was true of early releases of Rust. But they removed all traces of any kind of runtime for exactly this reason. It was a breaking change but it happened quite a long time before the 1.0 release. Here's the documentation for the change: https://github.com/rust-lang/r...

Here's a blog entry on using Rust for embedded. It dates from February and uses 1.0-alpha but of course 1.0 is out now:

http://spin.atomicobject.com/2...

In these days of LLVM, the portability story is good, even relative to C. No C portability gotchas.

Consider more than just the implementation

[quietwalker]

How many other engineers are going to be expected to know and maintain this? Ones you have on staff? Are you making sure to hire for folks who know Rust? If you have one, is your ops team up to supporting applications written in Rust, familiar with the errors and can handle it? What's the life expectancy of the app? Ever going to need to port it in the future?

Don't forget to factor in the bus factor, when you lose a whole engineer.

Lots of folks end up missing these and you end up with mysterious legacy code the business completely depends on for day to day ops that no one knows or understands. Heck, the other day, I was asked to unlock a windows NT laptop because it was the only known repository of source code for an app that was written over a decade ago - hopefully.

Re:Consider more than just the implementation

[Austerity Empowers]

Any decently educated programmer can pick up any language quickly and easily.

Hire polyglots not language end-users.

I'm torn on this one. On one hand, yes, anyone with a CS background who didn't cheat through school can learn a new language quickly.

The issue is whether they can learn to write idiomatically correct code in that language, and whether they "think" in terms of how that language was designed. That usually requires a bit of time, not to mention some patience. Python is my usual example for this, it breaks a lot of (in my opinion) sensible conventions that people over 10 are used to: no need for semicolons (sneered at if you use them), mandatory white space, duck-typing, etc. Yes, you can learn python in a few hours, but to write "good" python that other python people can/want to support, and generally don't waste time fighting the language, you need to spend some time.

Generally when I see a language like this I want to barf, but it's hard not to run in to something like this a few times in life, and if you're on the hiring side and you have a pile of (say) Python, you probably want to hire someone that can do it properly, versus someone from say, C, who is going to be very upset with almost everything.

Use C

[menkhaura]

Show him this story to indicate your attention to him and use C instead of this new-fangled and still-evolving language anyway.

You'll get better debugging tools, more productivity (since you know C better) and a wider pool of replacement developers should the need arise.

Rust is cool

[radish]

But it's still immature. I wouldn't personally use it for anything important.

Concentrate on the Employee

[TechyImmigrant]

The engineer pushing for rust is emphatic, should I bulldoze him or take the plunge?

Take yourself out of the loop. Give it to the engineer. He/she wants to push it. Let him/her. Make the engineer responsible for pushing it, training people, documenting the procedures. Provide room to enable it to happen.

This is how the engineer grows and an engineer and how you grow as a manager, learning to trust the technical opinion of those doing to technical work.

Re:Why not to use Rust

[Fwipp]

Isn't humor supposed to be funny?

Re:wouldn't hold my breath

[dmoen]

1st paragraph is false, due to the rather extraordinary design process that Rust went through.

designers also go off on an ego-trip, introducing numerous gratuitous syntactic changes, overlooking important features in their predecessor language they didn't understand

The Rust community is quite large, including many skilled language designers. The Rust github repository has ~1200 contributers. With that pool of talent,
there are no features of C/C++ that the designers don't understand. With this kind of community, and a formal change review/feature addition process, there's not much danger of a single ego-tripping designer messing up the language.

adding features few people actually need

The project transitioned from a hobby project to an official Mozilla project in 2009. During the 6 years from 2009 to 2015 (when the Rust 1.0 design was stabilized and released), a lot of Rust code was written. Features that seemed like a good idea at the time, but which had little practical use, were removed before 1.0.

3rd paragraph is also incorrect. The main feature of Rust is guaranteed memory safety, without a garbage collector, enforced by compile time type checking rather than by introducing run-time overhead. This memory safety includes a guarantee that shared global data can't be corrupted by simultaneous writes from different threads, something that no other language offers. C++ doesn't offer this today, no other language does.

I agree that Rust will influence future languages, but I don't think it will have much effect on C. The C++ community is already looking at Rust and trying to figure out how to compete with what it offers.

Re:wouldn't hold my breath

[istartedi]

This. C can be fixed. It takes time, and compilers are usually ahead of the standard. How long did it take for C to get the restrict keyword? That allows us to control pointer aliasing in a portable way. The impetus for that was that FORTRAN could outperform C because, AFAIK, it assumes no aliasing.

There are already a lot of static checkers for C. I'm willing to wager they can catch just as many bugs at compile-time as Rust. Having such tools is almost as good as having checks integrated into a standard implementation. If you go ahead in C, the standard may catch up to you without you having to worry about the risk of a new language.

Re:Why not to use Rust

[dmoen]

1) The Rust project is not controlled by Mozilla. Just look at the copyrights on the rust source code. It's permissive open source, with copyright shared by ~1200 individuals, and Mozilla is not on that list. So this is like spreading FUD by warning people that Linux is controlled by the Linux Foundation (Linus's employer)--hint, it isn't.

2) Mozilla and Oracle are quite different. The Mozilla Foundation is a non-profit, open source organization that exists to provide a public benefit through the creation of open source software. The Mozilla Corporation (employer of some of the Rust developers) is a wholly owned subsidiary that donates all of its profit to the foundation. By contrast, Oracle is known for being one of the most rapaciously greedy software organizations in existence: just consider the Oracle article on Slashdot right now, about how Oracle rips off customers via "traps" in the opaque licencing terms.

3) How can you be sure that Rachael Craig and Nicolette Verlinden are cisgender males? They have female names and photos.

So yeah, I'm pretty sure the parent is a troll, and I fell for the bait.

Re:wouldn't hold my breath

[NotInHere]

Even if templates are already present in C++, they are a PITA to use. Rust is really really easy to use for those.

Re:wouldn't hold my breath

[DuckDodgers]

The interesting feature of new programming languages is often not what they make possible - you can write any program in the world in assembler, after all - it's what they make default.

Rust doesn't allow null values or null pointers. The Rust compiler automatically frees memory when the last reference to it goes out of scope. Variables are immutable by default. You can't use pointer arithmetic by default. Only one mutable reference to any piece of memory is permitted to exist at any one time by the compiler.

You don't need a new programming language for those features, you can write code in any existing language that follows those conventions. But by making good software development practices the default and having the developer jump through extra hurdles to do things in a way that might be dangerous, the general level of code quality is improved. C or C++ might evolve to the same defaults in 20 or 30 years - but if you want to write low defect systems code quickly today, Rust deserves a look.

Also, the language designers list most of the features they listed and what they drew them from, and some features in the 0.x releases were dropped when they found few practical uses for them.

Re:Failures with IBM Computers

[stridebird]

So you spent 5 hours of your time, and 5 hours of tech support time, to avoid the data entry clerk spending 6 hours simply rekeying the data? Why? Doesn't sound like the right choice, unless the clerk had gone home already or something.

Re:wouldn't hold my breath

[Tailhook]

The C++ community is already looking at Rust and trying to figure out how to compete with what it offers.

Like what?

Here is Stroustrup talking for over and hour and a half just three weeks ago about how to both narrow and enhance C++ to achieve, among other things, a degree of memory safety, pervasive ownership semantics (std::owner<>) and enabling the compiler do a better job of detecting faulty code. The parallels with Rust are impossible to miss.

It has been a long time since anything challenged the C/C++ paradigm. In that time a large number of non-"systems" languages have emerged, leaving the low-level stuff to C/C++, and a smaller number of systems languages (Objective C, D, etc.) have also emerged, but nothing so far has provided enough value to motivate broad adoption. I think Rust is a language that does bring sufficient value. I am certain it is inspiring people to use and advocate it, as evidenced by this story.

It's disappointing to see the sheer number of Rust haters emerging from among C/C++ programmers. You can pan around the comments in this story yourself and read an abundant supply of irrational, ignorant and petulant comments. If Rust disappeared tomorrow it wouldn't cause a ripple, yet it's hated like Java or SQL. Sad.

Re:what about OS's or small footprint?

[serviscope_minor]

What about for something like an OS?

The only coherent argument I've seen for writing an os C rather than C++ is the annoyance of setting up the C++ runtime (it can be done though). The only other arguments I've seen basically assume that the world of computing has not advanced since about 1995. What were valid points then are simply wrong now.

Or for tiny little embedded stuff where memory is an issue? (Honestly curious, I'm not current with the latest C++ developments.)

C++ doesn't use more memory than C. In fact because the language is more advanced, idiomatic code is often more efficient and less consuming of memory than C. C++ runs just fine on an ATtiny MCU and things don't get much smaller than that.

Bear in mind C++ is almost a strict superset of C. Everything you can do in C, you can do in C++. But C++ is a more powerful language and it gives you the power without compromising on size or speed.

Re:Failures with IBM Computers

[towermac]

Reminds me of the time the owner and his wannabe tech friend were poking around the IT closet one night, and mysteriously, our payments database crashed, corrupted, and unrecoverable. I spent all night trying to restore the previous days receipts. Hell, I even tried a hex editor to get something, anything. The file was complete garbage. Probably $100K unaccounted for, I was thinking the bank and investors are not going to like that, the company may be toast.

The next morning, I told the accounting boss (owner's daughter) I had to use the backup, and all the payment records from the previous day were lost. She got the four accounting clerks to re-enter the previous days payments in about 30 minutes. Dang, no big deal.

I learned a valuable lesson that day, and hopefully, so did the boss.