Hacker News Reader

Comment by vvanders | Hacker News Reader

I mean this in the most non-confrontational way: have you actually used/looked at Rust?

The reason I ask is just about every item you laid out I've had the opposite experience.

Talking with C/C++ is trivial with bindgen and clang. Embedding in C++ is likewise straightforward. I mean Firefox is one of the larger C++ codebases out there. The package manager is great and makes dropping in things much less painful.

On the security front I don't think you can compare the two, I can easily think of things like iterator invalidation that C++ just doesn't handle well.

The last big project I did in Rust ran on 6 different targets(x68 win32/linux/osx, android armv7/x86, wasm) targeting 3 different rendering stacks(OpenGL, HTML Canvas, Android Views) integrated deeply with a Lua interpreter. Having done cross-platform stuff like this in the past it was a build/toolchain nightmare. With Rust everything was straightforward and pretty darn painless.

View on HN

> I mean this in the most non-confrontational way: have you actually used/looked at Rust?

I follow Rust since Graydon Hoare's initial vision for it. Which i love it when it first came out. The garbage collected Rust had so much potential, in my point of view.

Then when i started to follow it, it was chaging into this current encarnation trying to chase C++, and market as a better C++.

I've coded in it for a period of 6 months, i like it, i understand its value, but somehow with the explicit lifetime thing, it started to become even more painful to code in it, even compared to C++, where you still have to create a header file and a impl file, without a proper module system.

The first Rust vision, now was re-created even more beautifully in Swift.

I get it what Rust is, i think it has its value and its place, im just saying that it will get a time where it will be very harsh to Rust get more adoption, because, even if you like it, you just cant get out of the great ecosystem all coded in C and C++. Interfacing with C for other languages is pretty easy, but you still have to wrap C++ interfaces, and use just some features, because you lost access to the whole thing (think LLVM for instance).

So C++ has this net effect, which it achieved by the virtue of all this amazing software ecosystem, where giving its talking its native language its much easear to interact with.

> The first Rust vision, now was re-created even more beautifully in Swift.

Had you said Poney I'd have agreed, but I don't see how Swift matches the first Rust vision (a safe concurrency model).

I meant Pony[1] obviously

[1]https://www.ponylang.org/

I have used Rust occasionally on weekend projects.

Rust toolchain still fails support on mixed mode debugging.

With C++, I can have a mixed .NET, JS and C++ solution and without problems debug and single step across all languages, regardless of targeting desktop, server or UWP.

Similar applies to Java or Android tooling.

Additionally if one is into native desktop coding, bindings to Gtk and Qt are still work in progress, and there isn't nothing that would match something like Blend.

Finally, the borrow checker still hinders some programming patterns that are quite common on GUI code, a few of them will be tackled with NLL.

Ah, and cargo does not support binary libraries although rustc can handle them, which is an issue for companies selling libraries.

I am aware all these issues will be eventually fixed, it is just as I see the situation currently.

The real problem is when it's not just binding: it's actually using metaprogramming, which is a huge part of why I use C++. There's no equivalent to blaze or eigen for linear algebra in Rust, and much of that heavy lifting is handled by templates. (There are some libraries with rudimental expression template-like behavior, but nothing as sophisticated.)

This is the sort of thing that bothers me about these kinds of arguments. Sure, you're always going to be able to find certain domains where existing libraries or language features make a certain ecosystem very well suited. And that's fine. No one's saying to discard the best tool for the job for another one that might have some general advantages but won't actually get you where you need to go.

But there are a ton of domains where C++ doesn't have anything special to offer and you could just as reasonably write the code in rust.

Perfect. I absolutely agree. The thing is, I use C++ because it does a lot of things specialized for what I need. I don't work on every problem, and I look forward to the chance to use Rust. That being said, for now, the problems I'm working on are domains that very much benefit from C++ and I will continue to use it.

I totally agree that Rust is a great language and has wide applications. It doesn't fit my current needs, but I don't doubt it meets many people's needs. More power to them -- and it's cool to have a "The new C++ killer language" which can actually live up to its hype, unlike Java and C# and Go and D.

What's wrong with D? I quite liked it when I used it (for a relatively small project). It's not really a C++ replacement (GC), but as a high-level language the only problem I found was lack of a large library ecosytem - the language itself was quite pleasant to work with (more so than C++ and even Rust, which I also like).

D seems not bad -- I just mean that Rust was the first "C++ killer" which actually could match C and C++ speeds. I also have a lot of respect for Walter Bright and Andrei Alexandrescu.

I'm sure I'd much prefer it over Go, for example.

That's probably where you and I differ, I don't see metaprogramming as a plus. More often then not it tends to lead to some long compile times(which is why boost never sees the light of day in any codebase I work in).

I'll also counter that having worked in a fairly math heavy 3D graphics space I've never needed them, although our requirements may be different.

Reply on news.ycombinator.com