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

301–310 of 379 posts

Re: Rust vs C Pitfalls

#301

Post by colemickens »

faragon wrote: post #276

Author forgets some inconvenients of Rust: massive bloat, multi-platform issues, etc.

What are you talking about? I don't get people making these posts without any detail whatsoever as to what they're talking about.

I have a fully static binary that includes futures, nix, tokio, uuid, and more. Even statically compiled with Muslims it's less than three megs.

And if I didn't use the nix package for a setsockopt call, it would be perfectly capable of running on Windows (and I could easily make it cross platform if I wanted to invest the effort in adding Windows support). Further, there are an abundance of great resources out there for extremely painless cross compilation.

So far I've not heard of problems with multiplat or bloat so I'm hoping you'll elaborate.

Re: Rust vs C Pitfalls

#302

Post by voidlogic »

dalailambda wrote: post #129
richard_todd wrote: post #107

Earlier quoted context omitted.

I have wondered the same for a while now, and I hope someone familiar with Rust can explain it: in many of the benchmarks Go is faster and/or uses less memory despite the GC. Like you, I don't see much trickiness in the Go code.

In many cases a garbage collected language will be faster when it comes to allocations than using naive allocation strategies (e.g. reallocating a hashmap many times as it grows instead of reserving memory upfront). This is because the garbage collector tends to have preallocated memory lying around, while the RAII needs to call malloc and free every time a heap object is created. Another factor could also be that th…

Part of this is also that Go is really good at not allocating from the heap when it can allocate from the stack (escape analysis). Until Go 1.5 the Go garbage collector was pretty weak, but it didn't matter as much as it would have for a language with heavier heap allocation.

Re: Rust vs C Pitfalls

#303

Post by _0w8t »

njs12345 wrote: post #280
_0w8t wrote: post #265

Earlier quoted context omitted.

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?

A person on a conference has not mentioned details. The reason for Java is productivity and access to a bigger pool of developers.

Re: Rust vs C Pitfalls

#304

Post by erikpukinskis »

groovy2shoes wrote: post #90
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.

C has also been relatively stable for the last 25 years or so. Rust changes every 6 weeks. Yes, the language is supposedly not undergoing breaking changes without strict deprecation and feature-gating. However, as new features are added to the language, libraries are usually updated to leverage them, and suddenly you are also forced to keep up with that rapid release cadence to ensure your project still builds. Meanw…

This is my same problem with JavaScript. Yes it's wonderful that changes are backwards compatible. But if the entire community is updating libraries you rely on to use new language features then you have no choice but to use those features too.

Or stop using other peoples' code and just use core language features and build everything from scratch. Which is what I end up doing, and it has some benefits. But it definitely slows you down.

Re: Rust vs C Pitfalls

#305

Post by the8472 »

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

Rust has by far the best tooling and documentation support out of all languages I've seen. Library support is great too, at least in that Cargo is an amazing platform and it's too easy to import C libraries. What do you feel is actually missing from Rust? Nothing has stopped me from replacing C entirely on the low end, and even the high end for application software development.

> Rust has by far the best tooling and documentation support out of all languages I've seen.

IDE support is easily better for java. IDEs have total type knowledge since they directly integrate with the compiler, including in long chains of type-inferred code, usually even while you're in the middle of typing and your code is in a syntactically invalid intermediate state. They also automatically manage imports where needed.

Similarly, IDE-integrated debuggers can do a edit-code, recompile, hot patch into running application while you're stepping through the code.

CPU Profilers seem about en par, but memory profilers in java are again better because they offer a combination of taking heap dumps, allocation recording and diffing dumps at the same time. While also offering good GUIs for exploring object graphs.

Re: Rust vs C Pitfalls

#306

Post by faragon »

colemickens wrote: post #301
faragon wrote: post #276

Author forgets some inconvenients of Rust: massive bloat, multi-platform issues, etc.

What are you talking about? I don't get people making these posts without any detail whatsoever as to what they're talking about. I have a fully static binary that includes futures, nix, tokio, uuid, and more. Even statically compiled with Muslims it's less than three megs. And if I didn't use the nix package for a setsockopt call, it would be perfectly capable of running on Windows (and I could easily make it cross…

There are more systems than POSIX and Windows. Also, even in popular Linux systems Rust is not even installable in a straightforward way (e.g. Ubuntu 15.10, my system), so go figure. Regarding Rust bloat, I don't know if has got any better recently, but it was crazy bloated in comparison to C.

Re: Rust vs C Pitfalls

#307

Post by fungos »

steveklabnik wrote: post #161
fungos wrote: post #125

Earlier quoted context omitted.

If it compiles and run it is allowed. There is no rule to benchmark other than having the same end result with best performance. I still can't get all the moral over this. The best thing here for Rust would be to achieve the best performance on this game and nothing else. To me this game is important and winning on it is more yet. So, if Rust don't have better result by "morals" this is so wrong that hurts. But each…

The Benchmarks Game has more rules than that. It's not about "morals."

But people are criticizing C because the way it is implemented is not "realistic". Or that the "hash" is a hack that will never work in real life.

I don't know the background of these people, but they couldn't be more wrong. So that looks like "morals" or just they don't ever saw real C code out there.

Re: Rust vs C Pitfalls

#308

Post by fungos »

You're so wrong that is laughably.

That laughably hashing functions are highly specialized implementations for a proposed problem. There is NO MORAL there.

I code C for living and if we can use "laughably hashing functions" to gain performance we WILL DO.

Re: Rust vs C Pitfalls

#309

Post by fungos »

sanderjd wrote: post #155
fungos wrote: post #125

Earlier quoted context omitted.

If it compiles and run it is allowed. There is no rule to benchmark other than having the same end result with best performance. I still can't get all the moral over this. The best thing here for Rust would be to achieve the best performance on this game and nothing else. To me this game is important and winning on it is more yet. So, if Rust don't have better result by "morals" this is so wrong that hurts. But each…

It isn't a "moral" issue. It is about the usefulness of the benchmarks. If you're using them to make a recommendation about which programming language to choose, it is important to have a sense for how well the results generalize to the kind of programs you will be writing. Using unrealistic hacks targeted specifically to each benchmark is contra that goal. If, on the other hand, you're just treating the benchmarks a…

Benchmark GAME :)

Re: Rust vs C Pitfalls

#310

Post by steveklabnik »

fungos wrote: post #307
steveklabnik wrote: post #161

Earlier quoted context omitted.

The Benchmarks Game has more rules than that. It's not about "morals."

But people are criticizing C because the way it is implemented is not "realistic". Or that the "hash" is a hack that will never work in real life. I don't know the background of these people, but they couldn't be more wrong. So that looks like "morals" or just they don't ever saw real C code out there.

You're making an assumption that the C code is allowed to have the same algorithm as the Rust code. This is not actually exactly true, based on the rules of the game.
Post reply on HN