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

271–280 of 379 posts

Re: Rust vs C Pitfalls

#271

Post by rubber_duck »

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.

Sorry I meant overhead in terms of code size/use case complexity - not runtime performance (although like someone below mentioned you can often do "unsafe" stuff that's faster but can't be proved by Rust)

Re: Rust vs C Pitfalls

#272

Post by blub »

groovy2shoes wrote: post #247
steveklabnik wrote: post #94

Earlier quoted context omitted.

There's at least two alternate compilers I know of in the works. We'll see when they're in a workable state, or at least, enough to compile rustc. > In the meantime, I'd settle for an "LTS" release or something. That could work. This is something we've discussed. I imagine it will happen. At first, I would expect six month LTSes, then longer ones as time goes on.

I could definitely live with such a solution, but even six months might be too quick. So, as long as the plan is to lengthen the LTS window, I think that could work. The company that employs me just upgraded to a C++11-capable version of GCC three months ago. Even C++'s three year cadence seems like it might be too fast! Thing is, the company wants to vet our entire platform, which itself only changes yearly. They wa…

Completely agree, C++'s three year cadence is probably the fastest more conservative industries are willing to go.

And why should one invest time for such a low-level component in their toolkit every 6 months?! I want to build software and solve problems, not spend my time keeping up with programming languages and library updates.

Re: Rust vs C Pitfalls

#273

Post by psi-squared »

enygmata wrote: post #258
gravypod wrote: 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…

> * Great Libraries ( Everything and a kitchen sink ) This is a must for me. I often give up on compiled languages because libfoobar isn't yet available on the language and I have no interest in writing (and maintaining) language bindings for third party libraries I use. My dream is that one day I'll be able to do something like: Foobar = link_cimport({"headers": ["foobar.h"], "packages": [ "foobar" ], "prefix": "foo…

It looks like the first part of what you want is nearly there - see https://github.com/Yamakaky/rust-bindgen

It converts C headers to a Rust module containing the relevant type/function/etc. definitions. On stable you need to either pregenerate the module (not too bad if you're pinning particular versions of libraries anyway) or add a build script to autogenerate it. On nightly, there's also a compiler plugin that does all the work for you, and looks not-too-dissimilar to what you wanted. The only thing it lacks is the prefix removal stuff.

Re: Rust vs C Pitfalls

#274

Post by the_why_of_y »

cesarb wrote: post #249
EugeneOZ wrote: post #211

Earlier quoted context omitted.

Java has not so great reputation about safety.

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…

... and just to add to that, if you look at the other popular sandboxed client-side runtimes, i.e., Adobe Flash and various JavaScript-enabled browsers (all of them implemented in C++), you will find a similar number of critical vulnerabilities.

Re: Rust vs C Pitfalls

#275

Post by pas »

hueving wrote: post #234
lobster_johnson wrote: post #147

Earlier quoted context omitted.

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 man…

Kubernetes is opensource-by-Google. It's suprisingly open, and still alive, which is better than almost any of the other Google known projects. (Chrome and Android come to mind, but Android is write-only, and Chrome isn't that great at listening to users either. Not that Mozilla is better about Firefox stuff, but the Rust team is wonderful.)

Re: Rust vs C Pitfalls

#277

Post by burntsushi »

millstone wrote: post #262
Odin78 wrote: post #237

Earlier quoted context omitted.

> 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…

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 abstraction barrier.

In sum, I think "the borrow checker forces runtime overhead" is an incomplete picture. I think a better picture is, "if you completely ban explicit use of unsafe from your code, then you may miss out on some optimization opportunities." i.e., When the borrow checker fails you, you're given a choice: 1) accept safety and the possible performance loss or 2) accept the onus of proving safety and do the fastest thing possible.

I think the fact that those choices are available is an excellent thing. I choose (1) all the time because not every line of code is relevant to performance. But sometimes I get to choose (2), and I'm thankful that such a choice is always very explicit.

For good measure, here's the unsafe version without atomics: https://is.gd/V1K6nD

Re: Rust vs C Pitfalls

#278

Post by db48x »

sidlls wrote: post #26
db48x wrote: post #19

Earlier quoted context omitted.

If only these mythical experienced developers that never shoot themselves in the foot actually existed.

I'm terribly sorry you've never encountered an experienced developer who uses C or C++ before, or think we're non-existent, or that using extremes like "never" is a reasonable position instead of an incredibly terrible hasty generalization. If there were as many blown off feet as comments on HN suggested technology even as it currently is simply wouldn't function. Do you even understand how much mission and safety cr…

Sure, all things are possible. It is _possible_ to write perfect code, it's just not very likely. However, under commercial conditions it is so unlikely as to be implausible; you just won't have the time or budget for it. NASA can do it, most of the time, but the difference is that they take the time to find all of the bugs, not that they can write the code perfectly the first time through.

Re: Rust vs C Pitfalls

#279

Post by AsyncAwait »

lossolo wrote: post #187
mmstick wrote: post #175

Earlier quoted context omitted.

Your Rust example is kind of odd. Did you not see the linting errors in your editor or from the compiler? You can basically boil it down to just two lines of Rust. https://gist.github.com/mmstick/a8316ba0514f9d9ab33b18fa9b91... As for timing, I'm doubtful that Go is any faster than Rust. I don't have this www.js file so I can't test it on my laptop, but I'm pretty sure you didn't even attempt to do things like enabli…

I don't know if you noticed but we are discussing naive solutions which I've mentioned couple of times in previous posts. Code you linked is not naive solution. Things you proposed to do are not naive either.

Here's the thing; it is a naive solution. You may not want to accept it because that contradicts your claim of the Go solution being faster, but at that point it becomes a he-said/she-said kind of scenario because I can claim that your Go solution isn't naive as well and have exactly the same "validity" for such a claim as you do.

Re: Rust vs C Pitfalls

#280

Post by njs12345 »

_0w8t wrote: post #265
adrianN wrote: post #244

Earlier quoted context omitted.

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.

That sounds interesting - have you got any more details on exactly how they set this up?
Post reply on HN