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

261–270 of 379 posts

Re: Rust vs C Pitfalls

#261

Post by jtmarmon »

sidlls wrote: post #13

The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Rust has other features that make it generally superior in certain (many) contexts. The safety is a nice "add-on" effect, I suppose, but my view is that constantly hyping safety as the biggest selling point is missing a mark.

It's important for a lot of people and that's why it's marketed like that. It's also one of the most unique aspects of the language, and the primary goal of the entire project.

According to steveklabnik, about 50% of Firefox's critical security bugs were due to memory safety issues (source: " rel="nofollow">https://www.youtube.com/watch?v=_-fweBvtifA&t=27m20s>)

Presumably you don't think mozilla exclusively hires shitty developers.

Re: Rust vs C Pitfalls

#262

Post by millstone »

Odin78 wrote: post #237
rubber_duck wrote: post #225

Earlier quoted context omitted.

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.

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 borrow checker inflicts runtime overhead in this case.

Re: Rust vs C Pitfalls

#263

Post by tempodox »

mmstick wrote: post #210
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…

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.

> ...you don't know enough about Rust to see why they are promoting it.

If you have to know a lot about Rust to find out why you're using it in the first place, you certainly do have a chicken-or-the-egg problem. And, if the promotion doesn't leave you with a clear idea of why you might want to use Rust, that promotion couldn't have been very successful.

Re: Rust vs C Pitfalls

#264

Post by duneroadrunner »

zerofan wrote: post #32
gpderetta wrote: post #8

Earlier quoted context omitted.

I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.

To me it's almost the opposite. I like C a lot, but I ended up compromising on C++11 because in some programs I need more features to keep the implementation clean. I pay the cost of a messy language (C++) when implementing my libraries in order to have simpler applications that use those libraries. I've written C-like programs in Rust, and that goes very well. But I really like function overloading, generic operator…

> and so I'm stuck with C++

If you're stuck with C++, might as well do it safely:

(shameless plug) https://github.com/duneroadrunner/SaferCPlusPlus

Re: Rust vs C Pitfalls

#265

Post by _0w8t »

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.

In some cases those HFT installations are tuned not to run full Java GC within 8 hours during the trading day. Then they are rebooted.

Re: Rust vs C Pitfalls

#266

Post by blub »

pornel wrote: post #92
lacampbell wrote: post #6

Earlier quoted context omitted.

C is a very small and very portable language. Rust is not. I wondering why people bother comparing them at all.

Because Rust is IMHO the first viable replacement for C. Well-written C programs translate almost 1:1 to Rust. It can do (roughly) everything C can, i.e. it's natively compiled, gives control of memory layout, and doesn't depend on a GC runtime. Previous C killers were either dependent on a fat runtime (which isn't a big problem in general, but is a problem for some of niches dominated by C), or didn't offer meaningf…

Easy on the propaganda there.

* "First viable replacement for C" - C++ was invented decades before Rust.

* "Well-written C programs translate almost 1:1 to Rust" - C programs can be compiled with minimal changes as C++.

* "or didn't offer meaningful improvement in safety/concurrency/expressiveness." - C++ offers major improvements in all of those areas.

A lot of C programmers don't want to switch to C++ and they won't want to switch to Rust either, because they favor simplicity and neither Rust nor C++ are simple. They'll probably switch to golang for some stuff if anything and just stick to C for the rest.

Re: Rust vs C Pitfalls

#267

Post by burntsushi »

Manishearth wrote: post #124
burntsushi wrote: post #109

Earlier quoted context omitted.

> The point is that I wrote naive approach in both languages and it's a lot faster in Go. I tried your challenge, and the first data point I uncovered contradicts this. Here is the source code of both programs: https://gist.github.com/anonymous/f01fc324ba8cccd690551caa43... --- The Rust program doesn't use unsafe, doesn't explicitly use C code, is shorter than the Go program, faster in terms of CPU time and uses less…

... whoa that's a comprehensive comment. Do you think you could refactor out bytestring-based string manipulation into its own library? Even better would be something that worked for all encodings (using https://github.com/servo/tendril or something)

> Do you think you could refactor out bytestring-based string manipulation into its own library?

IIRC, someone was working on making the Pattern trait work on &[u8], but I'm guessing that work is stalled.

To factor it out into a separate crate means copying the &str substring routines, since there's no way to safely use them on an &[u8] from the standard library. (bluss did that in the `twoway` crate, so we could just use that.)

It does seem like a plausible thing to do, at least until std gets better &[u8] support.

> Even better would be something that worked for all encodings

I suspect the standard practice here is something like "transcode to UTF-8 and then search the UTF-8." (This is what I hope to do with ripgrep.)

> (using https://github.com/servo/tendril or something)

I don't think I know what problems tendril is solving, so it's not clear to me what it's role is.

Re: Rust vs C Pitfalls

#268

Post by burntsushi »

degurechaff wrote: post #167
burntsushi wrote: post #109

Earlier quoted context omitted.

> The point is that I wrote naive approach in both languages and it's a lot faster in Go. I tried your challenge, and the first data point I uncovered contradicts this. Here is the source code of both programs: https://gist.github.com/anonymous/f01fc324ba8cccd690551caa43... --- The Rust program doesn't use unsafe, doesn't explicitly use C code, is shorter than the Go program, faster in terms of CPU time and uses less…

woah, amazing comment. I usually just a silent reader on hacker news, but this comment urge me to create an account. I think lossolo just want a flamewar. He already has opinion which you cannot easly change. So any futher discussion after this comment will be pointless. EDIT: and how can you have time to write this? I just usually close the browser tab when this situation occurs...

Thanks! I like to think I usually close the browser tab, but text search is just kinda my thing. :-)

Re: Rust vs C Pitfalls

#269

Post by blub »

groovy2shoes wrote: post #257
mmstick wrote: post #193

Earlier quoted context omitted.

The problem with your concept is that C does not offer an official standard library and compiler suite, so you're trying to compare the C spec to the Rust standard library + compiler. The actual Rust API has changed very little since the 1.0 release. All the changes that have occurred have been mere additions to the language -- nothing breaking. Hence why the 1.0 release was termed as a 1.0 release. There won't be an…

C does have a standard library. It's described in full in the ANSI/ISO/IEC standard for the C programming language, and it's on your system, likely called libc or something along those lines. Anyway, I don't think that's a problem with my concept at all. What I want for Rust, and what I think will eventually be feasible for Rust as the language matures, is a standard that can be shared by compiler writers and Rust pr…

When Rust (or Swift or golang) gets ISO standardized we'll know that it's mature and left the "move fast and break things" phase. This won't happen, because it's still growing now, so it doesn't make sense to standardize. They might even always want to be able to move fast. I don't see golang ever being standardized.

The fact that someone says on HN "we're backwards compatible" doesn't quite offer the same level of trust as an ISO standard. Especially when there are some conflicting reports out there i.e. there are many super-awesome libraries that only work with nightly (I think it's called), because many of those maintainers are early adopters that love to try out new features.

Programming languages and libraries are building blocks, I don't want them to change under me in the middle of a project. This is why I dropped Swift, the 1.0 -> 2.0 migration was a very painful, and from what I hear recent major version changes aren't running smooth either.

Re: Rust vs C Pitfalls

#270

Post by notsoeasy »

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.

> I think most programs are less latency sensitive than that.

Hardly, compared to anything that takes user input and aims at 60/120 FPS (where you inevitably end up bypassing GC if you can't force it to run when you want to).

https://www.quora.com/Is-Java-overtaking-C++-in-the-HFT-worl...

> One thing about HFT is that the speed of the language oddly doesn't matter much. You are talking about latencies of 20 milliseconds, and any language can do 20 milliseconds since CPU times are measured in nano-seconds rather than milisecond.

and

> If you are playing in the sub 10 microsecond range doing everything in C++ helps a lot. [..] A lot of high frequency strategies run in the 20-30 microsecond time frame. I think this is where a lot of diversity in terms of setup occurs.

and

> To lower execution costs, we need a low latency system that has good determinism in response times. You cant pause for hash table rebucketing or garbage collectors or the OS taking away your time slice or moving you to a diferent processor or whatever. There are guys who try this in Java, and spend most of their time trying to make Java work deterministically. Good luck

and

> If you are in ultra HFT then C++ is the only answer (besides custom hardware - FPGA & ASIC). You just can't afford garbage collector.

Post reply on HN