Hacker News new | past | comments | ask | show | jobs | submit login

I found the comment more interesting than the article, though it goes in a very different direction :)

As somebody coming from the other end of the spectrum (Java/Python and other dynamic languages), I'm curious to know what you think of Rust as a systems programming language, once it matures. You get a number of high-level/functional idioms, built-in concurrency and either garbage-collected or manually-managed memory.




Rust is a side-grade to C++, but I think its emphasis on immutability first, mutability only when necessary is important regardless of anything else they do.

Rust can elevate itself above the sidegrade moniker once they get regions working.

I think the Rust developers are going to be similarly disappointed as the Go developers were if they think they're going to convince a bunch of C++ programmers to come over.

Most C++ programmers are convinced they've solved their own problems using the same tools Rust purports to offer (unique pointer, shared pointer, etc). You won't be able to convince them to abandon all that knowledge for unfamiliar territory for a language that offers identical pointer semantics with slightly-easier-than-normal baked in concurrency.

There's fundamentally nothing Rust offers that one couldn't do in C++, and I don't mean that in some kind of silly "hurrr turing-complete!" sort of way. I mean it's a realistic fact of modern C++ development that apps written in C++ will bear some measure of resemblance to how Rust enforces it at the compiler level.

With Rust, however, you get immature tooling and maybe region-based memory management.

Maybe.

Feature-based programming language is more than a little silly, but that's how it's going to fly with the C++ devs. They have all the toys in their playpen that they like having available.

No proposition that supposes removing some set of those toys without offering something incredibly substantive in return is going to go over well.

Rust offers a lot less flexibility and control in terms of concurrency as well. If at any point the task-based concurrency should fall apart for your use-case, you're more or less fucked.

No C++ user would ever accept those kinds of constraints for the sake of making it easier to write stable, correct software. The degree of tooling that they have at their disposal already makes it eminently possible to do so.

Rust is a response to the C++ quagmire and the dissatisfaction with that. So was Java. I see Rust as serving the more hardcore flip-side to Java's use-case, whereas Go serves the softer side. Rust will be more suitable for tighter constrained software, but still won't offer the limitless control and power of other systems languages.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: