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

281–290 of 379 posts

Re: Rust vs C Pitfalls

#281

Post by pvg »

eridius wrote: post #214
pvg wrote: post #84

Earlier quoted context omitted.

If that's the one it's a custom hash function which is then inlined as a macro. That still seems like a pretty vanilla C optimization that one might write in real C code.

The problem isn't that it's a macro. It's that it's a horrifically bad hash function. It's blazing fast, but completely unsuitable for use in any real code.

If it's a hash function that only works for this exact data set, I can see the argument. If it's a hash function that works for this kind of data (these particularly formatted, particularly constrained strings), it's fair play. Which one is it? 'It's not a good general purpose hash function' alone doesn't seem like a valid criticism, especially along with 'the Rust version uses a general purpose hash function'. Nobody said you had to use a general purpose hash function.

Imagine you got a million strings of variable length such that the last 4 bytes are guaranteed to be unique value between 0 and 999999. Lopping off the last four bytes is a perfectly good hash function for that kind of data.

Re: Rust vs C Pitfalls

#282

Post by tigershark »

_callcc wrote: post #238
Ericson2314 wrote: post #143

Earlier quoted context omitted.

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.

A modern programming language without any whatsoever support for generics from my point of view is just extremely bad, for someone else can very well be proof of anti-intellectualism.

Re: Rust vs C Pitfalls

#283

Post by EugeneOZ »

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…

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

Re: Rust vs C Pitfalls

#284

Post by jerf »

ainar-g wrote: post #223
jerf wrote: post #150

Earlier quoted context omitted.

The problem isn't that communication is hard, it's that semantics matter, we want different semantics between languages, and there is always difficulty bridging those gaps. As a simple example, consider the JSON string {"a": 36893488147419103232} That's 2 to the power of 65. Let's decode that in Python. What do I get? >>> import json >>> >>> json.loads('{"a": 36893488147419103232}') {'a': 36893488147419103232} >>> js…

Just as a nit, you can deserialize this number in Go just fine with big.Int: https://play.golang.org/p/s1EFgyXxl5 .

As I said, all the problems can be solved on a case-by-case basis. But you can't just replace all numbers in JSON with big.Int, because you'll miss floats. You can't just use big.Float for all JSON decoding, because you'll trash performance, something that Go users care about more than Python users (because in Python you've already accepted that your code is going to be slow relative to C). You can solve each problem on a case-by-case basis, but to provide a general solution that makes everybody happy is impossible, which is what you want for this big ol' happy "let's just let everybody call any function they want" plan to work.

Re: Rust vs C Pitfalls

#285

Post by gravypod »

tines wrote: post #151
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…

>> 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. I think he's trying to quote Dan Saks' "extern c: Talking to C Programmers about C++" when he said "If you're arguing , you've lost." Saks, at least, meant that if you're striving with someone, you've already lost because your partner is already in a "frame" of mind se…

I would have linked the video had I remembered the talk but exactly. This is what I meant.

Re: Rust vs C Pitfalls

#286

Post by gravypod »

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?

You can also use the Java Unsafe class to squeeze performance (every last bit) by recycling objects. I'm sad to say that I've had to do that at least once to make some vector math work.

Edit: Check out https://dzone.com/articles/understanding-sunmiscunsafe

Re: Rust vs C Pitfalls

#287

Post by gravypod »

EugeneOZ wrote: post #233
copperx wrote: post #217

Earlier quoted context omitted.

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

You can't say NPEs are an example that Java is unsafe. The propegation is Nulls isn't Java's fault and Java's evolving currently to make use of Optionals as we speak to attempt to avoid this.

Re: Rust vs C Pitfalls

#288

Post by EugeneOZ »

chungy wrote: post #240
duneroadrunner wrote: post #227

Earlier quoted context omitted.

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.

As a safe language from race conditions or memory leaks?

Re: Rust vs C Pitfalls

#289

Post by EugeneOZ »

gravypod wrote: post #287
EugeneOZ wrote: post #233

Earlier quoted context omitted.

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

You can't say NPEs are an example that Java is unsafe. The propegation is Nulls isn't Java's fault and Java's evolving currently to make use of Optionals as we speak to attempt to avoid this.

I can say it.

Re: Rust vs C Pitfalls

#290

Post by keldaris »

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.

I certainly didn't mean to offend through my choice of words (many people seem to like the term "evangelist" nowadays), but it's not particularly realistic in an age of so many new languages to expect everyone to spend a few months on every single language just to form a basic opinion (that alone would be more than a full time job). Even the most polyglottic programmer has to pick and choose at least to some extent, and that's where the public perception of the language comes into play. I'm just pointing out that as long as Rust is all about memory/thread safety in the public mind, it will be ignored by large swathes of developers for whom that argument is simply orthogonal to their interests and everyday concerns.
Post reply on HN