Hacker News Reader

To sit on the sidelines and wait till the technology and market matures is a smart decision. There's a lot of new things popping up, and not everything sticks. This is particularly true if you're running a business and you need to pick the right tech.

Learning a new language though is not a wasted effort, even if eventually the language becomes obsolete. It only takes a few days to get going with something new, and the lessons learned are useful regardless of if you use the language in the future or not.

But to say that there's no interest at all is pretty ridiculous, and there's plenty of people looking at rust and deploying it. That last statement made me feel you might just be a bit burnt out by change in general. Don't lose perspective. Going out of your comfort zone might be exactly what you need.

But one doesn't pick what to learn just between several languages, in fact I think they're a pretty poor investment after a certain count. When learning Obj-C I didn't get much out of it. I like several Swift idioms, but it was hardly worth it to learn a language for that.

In contrast I finished an architecture course recently that I expect will bring me 10x value of knowing both of the above languages.

Please see my answer to vvanders regarding interest vs industry interest.

What's the architecture course? I've been meaning to move from learning languages and APIs to learning more "lasting" things.

It was a course based on the book Software Systems Architecture by Rozanski & Woods. The trainer was Rebecca Wirfs-Brock.

Reading the book should be a very useful first step when learning about architecture.

If one decides to go to the course it's essential that there are also experienced architects participating and that one has an architectural case study that can be discussed.

I don't think you can unequivocally dismiss Rust, we've seen Dropbox and other companies pick it up(just yesterday Facebook announced a Mercurial alternative written in Rust).

As with each case, it depends. If you've got a well scoped project that is happy with a C ABI(or just stand alone exec) I think there's a compelling case for Rust.

I'd also argue if you're looking for top candidates having Rust in-house could be a perk rather than a negative.

To be more accurate, they didn't announce an alternative to Mercurial, but rather new Mercurial server software.

Yup you're right, I should have been a bit more explicit there, meant to say backend replacement.

I specifically said industry because projects come and go.

Yes, there are dozens of companies doing some project in Rust. That's true for almost any programming language.

I am guessing that it's going to be another 5-10 years until I would need to seriously consider learning Rust, assuming it will be able to break into the mainstream.

Safety-wise it could make sense for my industry, which seems to be overwhelmed by C and C++ (see Toyota).

Industry is great if you want to make safe, slow bets. PG's essay on lisp is a great example of why you may not want to follow industry.

However, the point I was making is there's not a binary switch between C/C++/Rust. There's a great interop/FFI story that allows a targeted/gradual adoption.

I know it's kind of hallowed ground around here, but IMO that essay has one of the highest ratios of survivor bias to good advice that I've ever seen.

Whatever happened to learning something to broaden your view? I doubt I'll get a job in Clojure anytime soon - but learning it has been the biggest eye opener to me as a programmer in the last 5 years.

> The answer to all these questions seems to be "no".

In conclusion you shouldn't be learning it and good luck to the company trying to hire people for Rust positions?

You're saying you should only learn what the industry is pushing towards. The thing is that the industry is pushing towards what sort of talent they can acquire - this is a vicious cycle.

Learning something to broaden my view is one of my favourite things to do. Except "something" is not a programming language.

If there's a worthwhile project that I want to contribute to, I will learn Rust. At least in automotive the industry is not necessarily pushing towards specific tools, they have constraints that limit choices to particular languages.

Not that long ago, the idea of trying to get into the automotive industry with a web background would have been laughable. Now, I frequently get inquiries from auto companies interested in my JavaScript experience, despite the fact that I left the Detroit area a few years ago. Even the auto industry changes when faced with a better way to do things, and its constraints actually seem to align well with Rust's core design principles. All it takes is a first mover.

They will use JS where it makes sense, e.g: web UIs to drive some background components. These are new projects.

Let's see if that first mover decides to show up.

> I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me.

May i ask why memory issues are not a pressing issue for you? having to hunt down memory corruptions / access to dangling pointer / memory leaks is a pretty frequent occupation for me (as a C/C++ developer). There are tools like valgrind that help, but well, it is a pain to deal with these issues.

I don't think that bulb ever dismissed entirely the idea of learning Rust for fun or for acquiring knowledge, did he?

I tend to think carefully about lifetimes, resource ownership and writing secure code. I am careful with threading, use language idioms to enforce safety and also use tools (such as valgrind, but also static analysis) to check the code.

This is not as reliable as Rust's compile-time safety checks, but in practice it works well enough for me. I don't think this is typical for all C++ projects or programmers e.g. I am not particularly impressed by the (little) Firefox code I've seen.

I hope C++ continues to evolve safety features and get closer to Rust's guarantees. I don't think automotive or aviation will switch too soon.

Out of curiosity, do you have (open-source) examples of C++ projects that do it right?

In my numerous-though-irregular years as a C++ programmers, I haven't seen any project producing code that's convincingly safe. I won't list all the pitfalls of C++ here, but, well, who doesn't have war stories of bugs-because-of-aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-pointer-is-still-being-used-after-its-mutex-has-been-released, bugs-because-collection-has-somehow-been-mutated-during-traversal, etc? I have reached the point where I feel I can't trust any non-trivial C++ code, so I gladly switched to Rust for all my new non-webdev projects.

But back to the question, I would be really happy to see convincingly safe C++ subsets in action. I certainly hope that this would improve my life as a C++ developer, at least for future projects. As a side question, I wonder how many C++ developers actually produce such code.

Don't have a link to such a project, I didn't really look. I am seriously considering starting one though, perhaps it's necessary.

I am genuinely interested.

Also, I just realized that doing this right might require dropping lots of legacy C++ code, more or less as would starting in Rust.

>I tend to think carefully..

What about a team? If you are leading a team of programmers, would you rather use Rust (where finding if the code is doing anything unsafe using a simple grep) or C++ where finding dangerous code is a lot harder?

I think the point of using langauges like Rust and Haskell only comes into play when the development is done by a team. It is one thing to hope that every one in your team is as disciplined as yourself (including yourself on a bad day), and knowing for certain that the language won't allow bad stuff to happen...

Depends on the team. If they're not experienced writing safe C++, I'd go with a safer language (e.g. Java) or teach them if that's not possible. But this also depends a lot on the project, usually it's the case that C++ is the only option available.

We can't start using any languages we want, we have to consider industry standards, resource availability and other constraints.

Probably because people with experience know how to handle these things up front so that they don't occur. I've been writing C and C++ for a decade now and for the last 6 years or so i have had very few issues which stem from any of the things you mention.

> Probably because people with experience know how to handle these things up front so that they don't occur. bla bla bla.

especially if you are dealing with a large code base with shifting requirements, where the code has been written over a long time by a lot of people; in a real world system you just can't make these assumptions regarding 'skill' at all. Even skilled people will have to deal with issues like invalidated iterators / containers that have been modified in non obvious ways / lots of other goodies as well.

there are a lot of projects/products like this, my guess is that this is the case with the majority of projects.

another example that i had the other day: lets say you have a cache of some sorts, now you keep adding entries to the cache without deleting them, in the end it blows up because it is out of memory. Now technically it is not a leak, but the result is that of a leak.

Now good luck solving that with smart pointers and reference counting, etc.

In legacy codebases, this is common, and I agree this is very painful. But in modern C++, it's pretty easy to write code that doesn't leak or dangle references. Don't use new, don't use delete; no memory leaks (barring cycles w/ shared_ptr). Avoid raw pointers in favor of references, and there are only a couple of rare cases where you can have something dangle. In addition, the new sanitizers (asan, msan), do what valgrind does, but are about 10 times faster, that is they only slow your code down 2-3x. So you should be running it on your unit tests on a nightly basis, further catching any bad memory issues. On a green field project, you can write code like this and have processes like this from day one, and memory safety is not going to be something you spend much time on.

I've worked on C++ codebases where I just never spent any time on this stuff, at all.

And it sounds like he works in the auto industry. This is pretty depressing that the paycheck weighs more heavily than the safety factor. Toyota killed people with their bad code.

From the little that I know, safety-relevant code might be modeled in a high-level language that generates C. I don't work directly on safety-relevant features, but I'm sure there are other processes and practices in place.

Some bad news for you though: all automotive companies typically use the same tools and processes. Aviation is also like that. And they use a ton of C and C++.

We had our chance and lost it, the DoD was doing great things with Ada. But 1) the compilers sucked 2) they were hard to get ahold of and 3) there wasn't nearly as much training material on how to use Ada well. Then the DoD acquiesced on Ada and permitted embedded dev in C/C++.

I am totally fine with a high level tool emitting C. C is a fine portable target. But the high level system should pass some provable rigor.

Sorry but that's bullshit. C++ is just a dinosaur plagued with issues inherited by design decisions made before most of people here were born. Trying to replace it has nothing to do with looking for a perfect language.

Rust could have absolutely 0 memory safety features over C++ and it would still be a massive improvement over the mess that is C++ package management and build systems with Cargo. Same is true for many other features. It's not quite there yet in terms of maturity and adoption but there's significant momentum and interest from big players that learning it now will likely put you in demand in a few years.

That would be true if changing programming languages or adding new languages would be zero-cost. Then we could iterate fast to some close-to-ideal language.

This black and white thinking is just a sign of immaturity, not of knowledge of a deeper truth.

All mainstream languages are capable of delivering business value. I happen to prefer certain characteristics that led me to C++, but I also found Java to be quite fine. I don't think I'd mind doing PHP or even JS for an interesting project. I've done both in the past.

I'm not saying we should be completely dispassionate about our tools, it's normal to have likes (I do like C++). But hating languages is rather pathetic and unhealthy.

I don't hate C++, saying rust offers nothing other than memory safety is just wrong, just by being a modern language with zero cost abstractions with stuff expected of modern languages such as modules, package management, sane build system, potential for lower compile times, etc. It's not hard justifying costs of migration when considering C++ problems if something replaces it adequately. Rust has the potential to do that.

* can I get a good job programming in this? Without moving to another country or continent.

Yes, there are many large companies which are either actively deploying Rust, or planning to. Easily found if you search.

* is my industry showing interest in it?

Yes: security, high reliability, availability and safety oriented industries. Any industry looking to get themselves out of the entrenchment of C/C++ but still needs at least one of the major reasons why it persists.

* is any industry showing interest?

I haven't found any industry, primarily focused on software development, which isn't interested. I've been actively poking around to see which way the wind is blowing. I honestly haven't come across any industry which would actively say "No we're good with C", other than those were software is an annoyance which they grudgingly have to be involved in.

Downvoted because no references to back up anything you are saying. I also tried doing a quick search on stackoverflow jobs and only got back 5 results [1].

[1] http://stackoverflow.com/jobs?sort=i&searchTerm=rust

The "Friends of Rust" page here lists organizations who have voluntarily chosen to advertise their production usage of Rust: https://www.rust-lang.org/en-US/friends.html

Furthermore, I attend Rust meetups all over the country and invariably meet people using Rust for various tasks at their job, even if their company doesn't choose to deliberately advertise itself as a Rust shop.

We also have a large internal list of contacts at companies using Rust (publicly or otherwise) that we use to schedule periodic conference calls to discuss the needs of production users in order to prioritize language development (e.g. Dropbox and Mozilla really, really want faster compile times, which is why that's been a determined focus for this cycle).

Overall we're quite encouraged by how many folks are willing to use Rust in a production capacity considering how young and unproven the language still is. :)

>Furthermore, I attend Rust meetups all over the country and invariably meet people using Rust for various tasks at their job, even if their company doesn't choose to deliberately advertise itself as a Rust shop.

Shocking that you would find people using rust at rust meetups. I'm sure they're a good representation of the programming sector as a whole.

No need to be so dismissive, my friend. The parent poster asked for references of people using Rust professionally, and I can confirm that I have spoken to many who do.

It's a bad reference, so I dismiss it. To be extreme, you may as well say the earth is flat because you met a bunch of people at a local gathering of the flatlander society who believe it to be true. Obviously people are going to be enthusiastic about rust if they're taking time from their weekends to go hang out with others to talk about it. It's just an irrelevant data point.

This is not wikipedia, and we don't need [Citation Needed] for everything we say. As you point out yourself, you can easily find at least 5 results. You can also easily find references for everything else I say.

The standard here is not to LMGTFY every few words.

Find me an interesting job in Stockholm requiring Rust and I am your man!

This is rubbish. You make huge claims without providing a single proof.

  > HN has a high proportion of people with an unusual 
  > interest in trying out programming languages

Which is precisely why it makes sense to ask this question here. :P

In that case one could save some time posting the question about non-mainstream language X and just learn X. End result would be the same. :)