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

351–360 of 379 posts

Re: Rust vs C Pitfalls

#351

Post by mmstick »

pvg wrote: post #340
eridius wrote: post #335

Earlier quoted context omitted.

Sure, but it's not a good benchmark. If you can demonstrate that you have blazing fast performance, but only for the exact input data that the benchmark uses , then you haven't demonstrated anything at all beyond an ability to tailor your code to a very specific input. But in the real world, we don't get to write our code for a very specific input (after all, if we knew what the input was ahead of time, we could just…

Well, here's the thing. I don't think it's for the exact input, it's for a type of inputs. Custom hash functions for specific types of data are a basic optimization technique and I find it odd you'd even suggest every hash function should be 'DoS-immune'. There's absolutely nothing 'real world' about this unless you think the world consists entirely of hostile inputs. In the real world, people absolutely optimize. Yo…

Rust's default hashmap algorithm is DoS-immune for any kind of input, which is a perfectly logical default algorithm for a language intended to be used in security-critical areas like operating systems, system libraries, web browsers, etc. and promotes memory safety.

Re: Rust vs C Pitfalls

#352

Post by pvg »

mmstick wrote: post #351
pvg wrote: post #340

Earlier quoted context omitted.

Well, here's the thing. I don't think it's for the exact input, it's for a type of inputs. Custom hash functions for specific types of data are a basic optimization technique and I find it odd you'd even suggest every hash function should be 'DoS-immune'. There's absolutely nothing 'real world' about this unless you think the world consists entirely of hostile inputs. In the real world, people absolutely optimize. Yo…

Rust's default hashmap algorithm is DoS-immune for any kind of input, which is a perfectly logical default algorithm for a language intended to be used in security-critical areas like operating systems, system libraries, web browsers, etc. and promotes memory safety.

That's really great but I don't see how it's related unless your argument is truly 'custom hash functions are bad', in which case I don't really know what else to tell you beside 'that's completely wrong'.

Re: Rust vs C Pitfalls

#353

Post by AsyncAwait »

lossolo wrote: post #329
AsyncAwait wrote: post #279

Earlier quoted context omitted.

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.

Anyway this really doesn't matter as his solution is the slowest of all which confirms what I wrote and contradicts what he wrote. For me it's not naive solution. Do you have any proof it is? Can you mathematically prove that it's naive solution? I know I can't. For everyone naive solution is something different, what I saw in burntsushi reply and what I wrote myself is the closest to what I think are naive solutions…

> For me it's not naive solution. Do you have any proof it is? Can you mathematically prove that it's naive solution?

You can't prove a negative.

Re: Rust vs C Pitfalls

#354

Post by ayosec »

Manishearth wrote: post #321
mmstick wrote: post #201

Earlier quoted context omitted.

> Rust had the chance to make strings feel as comfortable as integers, but instead they introduced their own dichotomy with String and &str. It makes perfect sense when you understand the differences and reasoning behind it. A `String` is a heap-allocated string that can grow in size. On the other hand, a `str` is basically a fixed-size string array, but you'll never interact directly with this type because there's n…

No, the default integer is u32. If type inference can't provide a better type, Rust will pick u32. If type inference can pick a better type it will use it. So if you create an unsuffixed int literal and use it for indexing, that literal will be a usize. Rust will type error if you try to use u32s with an array so it's all good though. Just means that you need to specifically `: usize` things. If you need an integer t…

> No, the default integer is u32

Maybe I'm missing something, but it seems to be i32: https://play.rust-lang.org/?gist=c79d4afef7fa20c81ba14de61f5...

Re: Rust vs C Pitfalls

#355

Post by [deleted] »

steveklabnik wrote: post #342
igouy wrote: post #334

Earlier quoted context omitted.

Where is it forbidden for programs written in C to use FNV? For example https://github.com/haipome/fnv/blob/master/fnv.c

I'm referring to my reply to you above about not being able to implement a different map, not the hash function itself.

[deleted]

Re: Rust vs C Pitfalls

#356

Post by igouy »

steveklabnik wrote: post #346
igouy wrote: post #344

Earlier quoted context omitted.

Just like everyone else Rust advocates can contribute programs that use a custom Hash function with a library Hash map. In fact, the current Rust k-nucleotide DOES use a custom Hash function with a library Hash map. No one is allowed to -- in your words -- "write an entirely custom [hashmap] just for the benchmark". (This was all discussed to death, in early December on https://www.reddit.com/r/rust/ ).

You didn't answer my question. Does "library" here mean that you are able to use a hashmap other than the one in std::collections, or not?

When someone fully re-implements khash in Rust and publishes the library, that will become a question which merits consideration.

Meanwhile, from the task description: Please don't implement your own custom "hash table" - it will not be accepted.

Re: Rust vs C Pitfalls

#357

Post by hueving »

sjellis wrote: post #256
hueving wrote: post #228

Earlier quoted context omitted.

>Right now, the Rust community is filled with the smartest and friendliest devs I know of among open source communities, and I kinda like it to stay that way. I have yet to find a community that has gotten popular and hasn't turned into a sewage plant. I think it's just a reflection on what the general population is like... :(

The Rust community is as great as it is because of very deliberate decisions and investment in engineering structures to maintain a positive community at scale, so I'm pretty optimistic that it will stay really good. Arguably this work is as innovative as the language itself. Emily Dunham of Mozilla has a talk about this Community Automation: https://www.youtube.com/watch?v=dIageYT0Vgg

The rust community is very small so it's easy to 'engineer it' at this phase. Once it gets so large that you have an eternal September it's effectively a complex system that will be very difficult to reason about with any changes resulting in lots of gnarly side effects.

Name a large programming community that is pleasant to interact with for newcomers and insiders alike.

Re: Rust vs C Pitfalls

#358

Post by steveklabnik »

igouy wrote: post #356
steveklabnik wrote: post #346

Earlier quoted context omitted.

You didn't answer my question. Does "library" here mean that you are able to use a hashmap other than the one in std::collections, or not?

When someone fully re-implements khash in Rust and publishes the library, that will become a question which merits consideration. Meanwhile, from the task description: Please don't implement your own custom "hash table" - it will not be accepted.

So, the answer is "no, you are not allowed." But you're open to changing that. Got it.

Re: Rust vs C Pitfalls

#359

Post by FreeFull »

merb wrote: post #33
dispose13432 wrote: post #22

Earlier quoted context omitted.

>On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but…

yeah of course, doing simple programs and checking their time is a good benchmark... oh wait.. also real world performance in bigger programs is mostly different, especially when you deal with big heaps. Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.

Rust doesn't have any significant runtime startup cost, but it certainly is an issue for Java (and presumably Go as well).

Re: Rust vs C Pitfalls

#360

Post by zerofan »

duneroadrunner wrote: post #264
zerofan wrote: post #32

Earlier quoted context omitted.

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

I looked briefly at your code. I don't believe it is possible to be compatible with the STL and safe in the way the Rust guys intend.

I might be wrong though. What happens with your vector in this code?

    using namespace mse::mstd;
    vector data(10);
    double& dangling = data[0];
    data.resize(100000);
    double crashing = dangling;
You use a lot of typedefs, so I couldn't tell for sure, but I think your operator[] returns a C++ reference right?

The problem here is there is only one operator[] for both reading and writing. This is a simple contrived example, and taking a reference like that looks artificial, but there are a lot of other ways in real programs to stumble on to this. (I don't think it's as bad as the Rusties do, but I stumble into this bug once or twice a year...)

The Rust folks seem to believe you need a borrow checker to solve this problem, but I think that a different container library in C++ could do the trick. For instance, favoring value copies instead of references, and returning a proxy object from operator[] instead of a reference.

Post reply on HN