Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Algorithm Cookbook in Rust

github.com

Post reply on HN
Print view View original

51–60 of 73 posts

Re: Show HN: Algorithm Cookbook in Rust

#51

Post by wuch »

tomjakubowski wrote: post #29
freeordead wrote: post #24

Earlier quoted context omitted.

So what is the point of a language in which things are hard to implement?

It's not any harder to correctly implement a data structure, even an "advanced" one, in Rust-with-unsafe than it is in C++-with-exceptions. I don't know where this meme comes from.

I don't think this claim is completely unfounded from perspective of people coming to Rust from other languages. Consider for example:

* Poor ergonomics of raw pointers. Lack of arrow syntax, verbose pointer arithmetic (at least now there is an experimental offset_to).

* Once you have pointers in data structures, properly specifying lifetimes is now your job. Compiler is no longer your friend, but an whisperer of evil (Compiler: Of course it safe. It has 'static lifetime, it must be safe. How do I know, you ask? I saw you dereferencing a pointer).

* Cyclic data structures (without additional layer of indirection) require unsafe, or reference counting and dynamic borrow checking.

* Need to account for zero-sized types when doing pointer arithmetic.

* Need to uphold Rust invariants in unsafe regions of code - forming non-unique mutable references to the same memory is hardly unusual when working with cyclic data structures, or in general (consider for example a swap without checking if memory locations are identical).

It seems to me that Rust moves part of required work from users of data structure to the designer / developer of data structure. You need to invest more work upfront, but once done users don't need to be on constant lookout for accidental API misuse that results in undefined behaviour.

Re: Show HN: Algorithm Cookbook in Rust

#52

Post by int_19h »

gerty wrote: post #39
daniel_rh wrote: post #28

Earlier quoted context omitted.

GPL3 means it's not very reusable in any projects that aren't GPL3. Have you considered a BSD or MIT license? or CC0 if you want to get code reuse? Or at the very least LGPL2

Thanks, that's a fair point. I do value user freedom and also come from the R language where GPL rules among packages. It's true though that Rust crate culture leans much more to MIT. I think GPL3/MIT as a dual license should be a decent compromise.

What would be the point of dual licensing GPL3 and MIT? So far as I can tell, MIT is a strict subset of GPL3, and any GPL3 project can use it anyway.

Re: Show HN: Algorithm Cookbook in Rust

#53

Post by baq »

wuch wrote: post #51
tomjakubowski wrote: post #29

Earlier quoted context omitted.

It's not any harder to correctly implement a data structure, even an "advanced" one, in Rust-with-unsafe than it is in C++-with-exceptions. I don't know where this meme comes from.

I don't think this claim is completely unfounded from perspective of people coming to Rust from other languages. Consider for example: * Poor ergonomics of raw pointers. Lack of arrow syntax, verbose pointer arithmetic (at least now there is an experimental offset_to). * Once you have pointers in data structures, properly specifying lifetimes is now your job. Compiler is no longer your friend, but an whisperer of evi…

Agreed but don't you have to do all this in C/C++ too if you want your data structure to be really safe? Except perhaps zero sized types.

Re: Show HN: Algorithm Cookbook in Rust

#54

Post by wuch »

baq wrote: post #53
wuch wrote: post #51

Earlier quoted context omitted.

I don't think this claim is completely unfounded from perspective of people coming to Rust from other languages. Consider for example: * Poor ergonomics of raw pointers. Lack of arrow syntax, verbose pointer arithmetic (at least now there is an experimental offset_to). * Once you have pointers in data structures, properly specifying lifetimes is now your job. Compiler is no longer your friend, but an whisperer of evi…

Agreed but don't you have to do all this in C/C++ too if you want your data structure to be really safe? Except perhaps zero sized types.

No, those are Rust specific things. For example, aliasing mutable references in C++ is potentially dangerous, but not undefined behaviour per se.

Regarding making a "really safe" data structure, this is quite tricky question. Safety means quite different things in those communities. Moreover those different concepts of safety are not readily transferable between languages, at least not in useful sense.

In Rust you would say that data structure is safe if it doesn't cause undefined behaviour when used without any unsafe user-code. Essentially once you write a safe data structure the safety is enforced by a compiler, even in a presence of malicious user-code (as long as it avoids unsafe blocks of code). In C++ on the other hand, a user would have only themselves to blame if they broke a precondition expressed somewhere in a documentation and caused undefined-behaviour.

This is exactly why I would postulate that writing correct data structure in Rust, as opposed to say C++, may require more effort. For similar reasons using dependent types doesn't make programming any easier. Of course, this may turn out to be a worthy investment in the long run.

Re: Show HN: Algorithm Cookbook in Rust

#55

Post by cyphar »

gerty wrote: post #39
daniel_rh wrote: post #28

Earlier quoted context omitted.

GPL3 means it's not very reusable in any projects that aren't GPL3. Have you considered a BSD or MIT license? or CC0 if you want to get code reuse? Or at the very least LGPL2

Thanks, that's a fair point. I do value user freedom and also come from the R language where GPL rules among packages. It's true though that Rust crate culture leans much more to MIT. I think GPL3/MIT as a dual license should be a decent compromise.

> It's true though that Rust crate culture leans much more to MIT.

This is a fairly worrying trend I've noticed in new languages. In general it seems that they are systematically creating ecosystems where copyleft is much less modularised than in other (older) languages.

For example, in Go and Rust, LGPL is effectively as strong as GPL because it's non-trivial to make packages/crates replaceable for an end-user with a binary. This results in a general distaste towards LGPL even though it's objectively _the language's fault_ that LGPL isn't as friendly as it is in C. This causes everyone to license things as Apache or MIT (or _maybe_ MPLv2) and as a result the ecosystem of copylefted software is reduced.

Re: Show HN: Algorithm Cookbook in Rust

#56

Post by lmm »

Groxx wrote: post #30
amelius wrote: post #19

Offtopic/meta. I'm wondering about a technology that allows us to NOT re-implement an algorithm cookbook every time a new language shows up.

yea, I'm convinced it's possible to at least save a ton of work there. Probably not for optimized libs, but something is much better than nothing. Rust though might be an example where such a thing wouldn't work (had it already existed), since the type system is legitimately different. But some things might work, and even a test suite you could develop against would be wonderful.

An ABI that could express sum types would be a huge step forwards for the computing world.

.net and the JVM sort of achieve this, but at the cost of going managed for everything. That's mostly fine (and possibly entirely fine, to be honest; very few people who think they need non-GC actually do), but there are still a few diehards who insist on non-GC, and Rust is pretty much the first good language to have that option in a comprehensive way.

Re: Show HN: Algorithm Cookbook in Rust

#57

Post by burntsushi »

cyphar wrote: post #55
gerty wrote: post #39

Earlier quoted context omitted.

Thanks, that's a fair point. I do value user freedom and also come from the R language where GPL rules among packages. It's true though that Rust crate culture leans much more to MIT. I think GPL3/MIT as a dual license should be a decent compromise.

> It's true though that Rust crate culture leans much more to MIT. This is a fairly worrying trend I've noticed in new languages. In general it seems that they are systematically creating ecosystems where copyleft is much less modularised than in other (older) languages. For example, in Go and Rust, LGPL is effectively as strong as GPL because it's non-trivial to make packages/crates replaceable for an end-user with…

> and as a result the ecosystem of copylefted software is reduced

You might be worried, but I'm not. In fact, I'd say that it's a magnificent trend. The less copyleft software, the better.

Re: Show HN: Algorithm Cookbook in Rust

#58

Post by Santosh83 »

int_19h wrote: post #52
gerty wrote: post #39

Earlier quoted context omitted.

Thanks, that's a fair point. I do value user freedom and also come from the R language where GPL rules among packages. It's true though that Rust crate culture leans much more to MIT. I think GPL3/MIT as a dual license should be a decent compromise.

What would be the point of dual licensing GPL3 and MIT? So far as I can tell, MIT is a strict subset of GPL3, and any GPL3 project can use it anyway.

Releasing it under MIT too would allow it to be used in closed source software projects. GPL does not allow that use case.

Re: Show HN: Algorithm Cookbook in Rust

#59

Post by adrianN »

cyphar wrote: post #36
daniel_rh wrote: post #28

Earlier quoted context omitted.

GPL3 means it's not very reusable in any projects that aren't GPL3. Have you considered a BSD or MIT license? or CC0 if you want to get code reuse? Or at the very least LGPL2

Maybe that's what they want. Personally I use GPLv3 for any project I can, because my priority is user freedom and not code reuse.

Consider using AGPL for anything that might be run on a server somewhere.
Post reply on HN