Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust vs C Pitfalls

garin.io

Post reply on HN
Print view View original

291–300 of 379 posts

Re: Rust vs C Pitfalls

#291

Post by the8472 »

EugeneOZ wrote: post #283
cesarb wrote: post #249

Earlier quoted context omitted.

Java's bad safety reputation comes mostly from the Java plugin, where many inventive ways to bypass its sandbox have been discovered. When used as a normal programming language, without depending on it for sandboxing (that is, when all code running in the JVM is trusted), its safety is quite good. (Java also has a not so great reputation about speed. That one also comes from the Java plugin, which often took minutes…

I see a lot of NPE in IntelliJ IDEA, especially EAPs. It's not browser's plugin.

NPEs are not a security issue in the same sense as a buffer overflow or null pointer dereference.

Re: Rust vs C Pitfalls

#292

Post by the8472 »

adrianN wrote: post #244
hueving wrote: post #229

Earlier quoted context omitted.

>It's plenty fast Unless you need guarantees that can't be offered by garbage collection.

Java is pretty popular for HFT applications. I think most programs are less latency sensitive than that. But of course, Java is not for you if you have hard real time constraints.

There's a commercial pauseless GC offering for java. It's pretty much aimed at HFT applications.

https://www.azul.com/resources/success-stories/

Re: Rust vs C Pitfalls

#293

Post by netheril96 »

burntsushi wrote: post #277
millstone wrote: post #262

Earlier quoted context omitted.

It adds runtime overhead by forcing the programmer to work around the single-ownership rules, via runtime checking (Arc, etc) and more expensive interfaces. For example, consider a simple thread-local counter. In C this would be e.g. an object in the tdata section, accessible via thread-local addressing. But in Rust, you have to use something like RefCell, which requires runtime tracking of mutable borrows. So Rust's…

That's not actually true though. You can use an atomic with a relaxed ordering. For example: https://is.gd/M1Q3Bu Now, to be fair, this is only one example and I'm sure you could come up with a better one. But this isn't especially controversial. Rust's entire standard library is living proof that you need unsafe to do some things efficiently. The value proposition is that such things can be bundled up behind an abst…

Why is a thread local variable atomic?

Re: Rust vs C Pitfalls

#294

Post by keldaris »

Manishearth wrote: post #199
keldaris wrote: post #23

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…

I see a lot of folks talking about this, but I live in a Rust bubble. From my POV a lot of the folks using Rust use it for primary reasons other than memory safety; many could afford to use python or something and get away with it. I suspect there are fewer blog posts about this, however. I'll take a shot at some of the advantages: Algebraic datatypes : Seriously. These are amazing. C++ has them with Boost's variant…

Thank you, this is exactly the sort of comment I was hoping to inspire, and it gave me some food for thought.

On first glance, I can see some utility in the ADT matching, but not necessarily something I miss in C++ (std::variant + templates gets me most of the way, although there are some issues with that approach). On the other hand, the clean separation of concerns and clear syntax of the traits example looks very useful indeed, and quite tempting.

Re: Rust vs C Pitfalls

#295

Post by keldaris »

Ar-Curunir wrote: post #241
keldaris wrote: post #23

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…

> Memory safety is not a concern That is how we end up with the miserably insecure state of affairs of today :)

Except not everyone is writing software remotely relevant to security. If the goal is to market Rust as a niche language for the security-conscious, that's fine, but there seems to be a drive to show that it's a superior general programming language. The safety argument doesn't do that for most people.

Re: Rust vs C Pitfalls

#296

Post by the8472 »

adrianN wrote: post #200
Manishearth wrote: post #146

Earlier quoted context omitted.

> If you're fighting, you've lost. I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. > Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly p…

I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.

Java's FFI story is not as good as rust's though. So if you're interacting with the OS / native libs a lot then it might not be a good choice.

Although there's JNR and JNA and it might become a standard feature at some point in the future[0]. But for a good FFI experience you also need arrays-of-structs, which means you need value types in java. So it's a long journey to get there.

[0] http://openjdk.java.net/jeps/191

Re: Rust vs C Pitfalls

#297

Post by naasking »

grzm wrote: post #182
naasking wrote: post #179

Earlier quoted context omitted.

> If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO. And if the types of programs you're talking about ar…

If the software does what you want includes all of those criteria. If you find that there are deficiencies in any of those areas, that would qualify as a reason to make changes, weighed against the cost of doing so.

> If the software does what you want includes all of those criteria.

Except most people don't consider those as criteria at all. The only criteria considered are "does it run and produce the output I want".

Re: Rust vs C Pitfalls

#298

Post by naasking »

groovy2shoes wrote: post #250
naasking wrote: post #179

Earlier quoted context omitted.

> If the software does what you want, being able to run on 30 years worth of hardware with just a recompile is a good thing That's not a responsible metric. 30 year old software was written against 30 year old APIs vulnerable to known attack vectors, and with 30 year old notions about security. The belief that this software is suitable for modern use is absurd IMO. And if the types of programs you're talking about ar…

More often than not, brand-spanking-new software is written against 30-year-old APIs. Lots of software we use day-to-day is old . For example, a couple years ago I fixed a 20-year-old bug in netcat, which itself hadn't been updated since the mid 90s. After I fixed the bug, I didn't need to fish out an old compiler or any compatibility libraries; I just compiled it with the latest GCC and glibc, and carried on with my…

> More often than not, brand-spanking-new software is written against 30-year-old APIs.

Let's assume this is true, brand-spanking new software will be written against 30 year old APIs that have survived 30 years of attacks and audits, but will avoid the ones that have proven vulnerable.

> I'm just less enthused about the prospect of refactoring my codebase once every few months to stay current.

The perception that you need to do this is false. You might feel pressured to refactor simply because of new syntactic improvements that make code clearer (like switching try!() macro to infix ?), but that pressure is a fiction. There's no real need to do it.

Re: Rust vs C Pitfalls

#299

Post by burntsushi »

netheril96 wrote: post #293
burntsushi wrote: post #277

Earlier quoted context omitted.

That's not actually true though. You can use an atomic with a relaxed ordering. For example: https://is.gd/M1Q3Bu Now, to be fair, this is only one example and I'm sure you could come up with a better one. But this isn't especially controversial. Rust's entire standard library is living proof that you need unsafe to do some things efficiently. The value proposition is that such things can be bundled up behind an abst…

Why is a thread local variable atomic?

Because an atomic provides interior mutability for `usize`.

(It's a hack that plays on the GP's specific example of a counter. It doesn't generalize arbitrarily to removing use of RefCell for thread locals in safe code.)

Re: Rust vs C Pitfalls

#300

Post by lmm »

copperx wrote: post #217
EugeneOZ wrote: post #211

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.

No sum types (the Java alternative to Rust enums is the horribly verbose visitor pattern, so a lot of the time people don't bother). null. A verbose and unabstractable "checked exception" system (that the standard library uses poorly in places) that leaves many users resorting to unchecked exceptions (panics) instead. Uninitialized field problems because methods are virtual even when called from superclass constructors. Excessive overhead to custom types that leads to using weakly typed Strings etc. rather than domain types. Poor abstraction facilities that lead to a culture of "magic" annotations and runtime reflection (or worse, proxies and bytecode manipulation) e.g. @Transactional, @Inject.

Java is safer than C, but it's a long way behind a modern functional language like Rust.

Post reply on HN