Live data from Hacker News

Rust vs C Pitfalls

garin.io

231–240 of 379 posts

Re: Rust vs C Pitfalls

#231
post #219

Earlier quoted context omitted.

Java has not so great reputation about safety.

That's interesting because it is based on the same principles of not letting developers do harmful thing as a way to guarantee security.

Rust uses RAII for memory-safety, not just language constructions to raise some limitations.

Re: Rust vs C Pitfalls

#232
post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS). Basically, Go is good for 90% of what I used to use Java for and 80% of wha…

I'm learning Rust. I considered Go but feature wise compared to Rust it seems really boring and plain. IMHO modern language has to have functional flavor.

Re: Rust vs C Pitfalls

#233

Earlier quoted context omitted.

Java has not so great reputation about safety.

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

GC is not about safety at all, sorry. I'm not going to start flamewar, but just to answer your question: https://www.google.com/#newwindow=1&q=null+pointer+exception

Re: Rust vs C Pitfalls

#234
post #137

Earlier quoted context omitted.

What's a good example of it?

I don't want to single out anyone or any specific projects, so this is going to be a generalization, but since you asked: In my experience, there's a lot of hostility and arrogance. More than in any other community, I've seen Go developers shut down discussion by closing comment threads on Github; reject pull requests and refuse to debate the merits of the change; castigate people for "not following proper procedure"…

>I'm particularly happy with the Kubernetes team.

I find it pretty terrible that Kubernetes develops on Slack/Github/Videochats. For being an Open Source project, it rejects open source tooling and makes it difficult for people with poor english skills to participate (text-based meetings are much better for inclusiveness). Even if you do listen in on the video meetings, they give you a feeling as an outsider that many of the decisions have already been made elsewhere (some obscure github issue conversation, a google doc comment on a 1 year old doc, etc). It seems the only way to meaningfully participate in the k8s community is to be a known insider... :(

Re: Rust vs C Pitfalls

#235

Earlier quoted context omitted.

Good point. I agree there are other reasons to use Go, I what mean is that unless I have a project that gets a lot of bang for the buck out of those, the KISSness of Go wins out over those nice features and their correlated complexity. GC was just at the forefront of that list of features.

There's simple, and there's anti-intellectual. Go would be the latter.

Well, in many respects Basic, PHP, Javascript, Java all had various forms of "anti-intellectualism" baked. They lost some of them along the way.

Still, the fact that all those languages are in the top 10 of programming languages kind of says that people don't really care.

Re: Rust vs C Pitfalls

#236

Earlier quoted context omitted.

> In Go I can only write libraries for Go programs. That's not true. It's quite simple to create a loadable shared object in go and call it using anything with a c ffi.

Calling C from Go has significant overhead [1], doesn't that mean calling Go from C is equally slow? [1] https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...

It may be even worse calling Go from C since you are bring the whole Go runtime with GC and all when you call into Go.

Re: Rust vs C Pitfalls

#237
post #120

Earlier quoted context omitted.

> The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality.

Rust only deals with half of the story at the compile time because it can't deal with stuff like cyclical refs, etc., and even without it it also makes a lot of valid code invalid because of it's borrowing rules. That's not saying that borrow checker is worthless but it does add overhead and frankly in a lot of scenarios that's just not necessary, even with all that fancy compile time checking you still need to do te…

> That's not saying that borrow checker is worthless but it does add overhead

It's important to emphasize out that this is compile time overhead, not run-time overhead.

Re: Rust vs C Pitfalls

#238

Earlier quoted context omitted.

Good point. I agree there are other reasons to use Go, I what mean is that unless I have a project that gets a lot of bang for the buck out of those, the KISSness of Go wins out over those nice features and their correlated complexity. GC was just at the forefront of that list of features.

There's simple, and there's anti-intellectual. Go would be the latter.

Go is against the sort of programming that builds up conceptual dream worlds of gratuitous abstraction and needless complexity. When that's the only way you want to think, Go will indeed seem anti-intellectual.

Re: Rust vs C Pitfalls

#239

Earlier quoted context omitted.

I completely agree. The biggest reason I haven't seriously tried Rust yet is because, despite all the vocal pro-Rust opinions we've all been inundated lately, I struggle to name a single interesting thing about the language apart from "safety". I wish the Rust evangelists would come to terms with the fact that to many developers memory safety is not a particularly important concern (for many different and often very…

You're only going to anger people by referring to another group as 'evangelists' when you yourself have already made note that you don't know enough about Rust to see why they are promoting it. There's much more to Rust than safety. You should actually spend a few months with it, and then give your opinion.

I've used rust extensively and my opinion mirrors the parent comment precisely.

Safety is a cool feature, but Rust is more than just safety, and pitching it as 'rust is safe' when it's not (and, often, it's not...) and when people dont care about that, doesn't convince people.

There are a lot of people who blog about rust, and almost invariably the 'killer feature' they come up with is safety.

It's not the killer feature; it's the side effect of strong memory management without a GC on an excellent general purpose programming language.

We could certainly do with more posts about how great and practical rust is, what the state of rust tooling is, and what great rust libraries there are with no mention at all of safety.

(... because safety is a cool technical feature; but the others; tooling, libraries and productivity are active barriers to adoption)

Re: Rust vs C Pitfalls

#240

Earlier quoted context omitted.

Please expound on that. Garbage collection, no pointer arithmetic, and array bounds checking seems like good safety features.

Well, I don't know about java's reputation, but there's this: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vend... http://www.cvedetails.com/product/1526/SUN-JRE.html?vendor_i...

Security exploits say nothing about the language's memory safety design. Java still qualifies as a safe language.
Post reply on HN