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

61–70 of 73 posts

Re: Show HN: Algorithm Cookbook in Rust

#61

Post by geodel »

lgas wrote: post #42
kazagistar wrote: post #21

Earlier quoted context omitted.

Data structures and algorithms are possibly the hardest part of Rust to dive into unless you have a really good reason. The best advice for newbies is to learn with other stuff and use existing algorithms. Of course, if you are trying to implement stuff for a class or something similar then you might be out of luck, and might consider trying the Rust IRC and such to work through the errors as they come up.

> Data structures and algorithms are possibly the hardest part of Rust to dive into What else is there?

CRUD webapps. It can get venture funding too if one can design a login page.

Re: Show HN: Algorithm Cookbook in Rust

#62

Post by dsacco »

tormeh wrote: post #32
cyber1 wrote: post #12

"My other goal is to show developers that C++ and Java kinda suck" -- really?!

It's a worthy cause. At HN we might all be aware that Java and C++ suck, but others might not know. Assuming others know what you do is a common cognitive bias. To us, this might be a slightly childish thing to have as a goal, but it might be a revelation to some readers.

> At Hacker News we might all be aware that Java and C++ suck, but others might now know. Assuming others know what you know is a common cognitive bias.

The irony here is astonishing.

I am a frequent commenter on HN and I rather like C++. I acknowledge its shortcomings without resorting to the tribalism that is marring the reputation of the Rust community.

Please don't assume that all of Hacker News has a homogenous perspective on the utility (or lack thereof) of extremely common languages like C++ or Java. I've said this before in threads like this and I'll say it again: one language does not need to win.

Re: Show HN: Algorithm Cookbook in Rust

#63

Post by steveklabnik »

dsacco wrote: post #62
tormeh wrote: post #32

Earlier quoted context omitted.

It's a worthy cause. At HN we might all be aware that Java and C++ suck, but others might not know. Assuming others know what you do is a common cognitive bias. To us, this might be a slightly childish thing to have as a goal, but it might be a revelation to some readers.

> At Hacker News we might all be aware that Java and C++ suck, but others might now know. Assuming others know what you know is a common cognitive bias. The irony here is astonishing. I am a frequent commenter on HN and I rather like C++. I acknowledge its shortcomings without resorting to the tribalism that is marring the reputation of the Rust community. Please don't assume that all of Hacker News has a homogenous…

"One language does not need to win" is the majority position of the Rust community. Of course, it itself is not completely homogeneous either.

Re: Show HN: Algorithm Cookbook in Rust

#64

Post by dsacco »

steveklabnik wrote: post #63
dsacco wrote: post #62

Earlier quoted context omitted.

> At Hacker News we might all be aware that Java and C++ suck, but others might now know. Assuming others know what you know is a common cognitive bias. The irony here is astonishing. I am a frequent commenter on HN and I rather like C++. I acknowledge its shortcomings without resorting to the tribalism that is marring the reputation of the Rust community. Please don't assume that all of Hacker News has a homogenous…

"One language does not need to win" is the majority position of the Rust community. Of course, it itself is not completely homogeneous either.

Oh believe me, I know the Rust community does not itself endorse this behavior (or mindset). I do believe the vocal minority that pushes that agenda actively harms the community; however, I appreciate your effort for clarification.

Re: Show HN: Algorithm Cookbook in Rust

#65

Post by legulere »

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.

Which of the four freedoms (ignoring that only freedom #0 and #2 apply to users) is violated by using more liberal licenses like MIT or CC0? Freedom #0 is clearly violated by GPL projects: GCC for years tried to be prevent to be run as a library or in combination with other programs. Running ZFS or the better proprietary graphics drivers on Linux is a bit questionable legally. GPL being incompatible with app store rules kind of breaks freedom #2 and #3.

Re: Show HN: Algorithm Cookbook in Rust

#66

Post by legulere »

Santosh83 wrote: post #58
int_19h wrote: post #52

Earlier quoted context omitted.

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.

I think the point int_19h meant is that you don't need to additionally license software under GPL when you already license it under MIT

Re: Show HN: Algorithm Cookbook in Rust

#67

Post by cyphar »

burntsushi wrote: post #57
cyphar wrote: post #55

Earlier quoted context omitted.

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

> The less copyleft software, the better.

All technical discussions will end in license arguments. Put simply, I don't agree (obviously). What I don't understand is this viceral hatred of copyleft to the point where you will make even weak forms of copyleft unfriendly in a language ecosystem. Aren't languages meant to be agnostic to license arguments...

At the end of the day, I don't care either way. I make all of my standalone Go and Rust code GPLv3. It's just a shame that people are willing to stunt their own languages just to make a point about licensing.

Re: Show HN: Algorithm Cookbook in Rust

#68

Post by cyphar »

legulere wrote: post #65
cyphar wrote: post #36

Earlier quoted context omitted.

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.

Which of the four freedoms (ignoring that only freedom #0 and #2 apply to users) is violated by using more liberal licenses like MIT or CC0? Freedom #0 is clearly violated by GPL projects: GCC for years tried to be prevent to be run as a library or in combination with other programs. Running ZFS or the better proprietary graphics drivers on Linux is a bit questionable legally. GPL being incompatible with app store ru…

> Which of the four freedoms [...] is violated by using more liberal licenses [...]?

None of them [which, as you probably know, goes without saying because they're both free software licenses]. The problem is that a project using a lax/pushover license is that the project can be used as a tool for violating user freedom. For examples of this, see the PlayStation and other such products which were developed thanks to the existence of free software under lax/pushover licenses.

As an aside, the thing that personally made me care about the prolonged effects of copyleft is that I realised that if I wanted to contribute to a world without proprietary software, every non-copylefted program that I wrote was potentially acting against my intentions. You might not see it that way (and I didn't see it that way for a long time), but that's why I made my decision.

> Freedom #0 is clearly violated by GPL projects: GCC for years tried to be prevent to be run as a library or in combination with other programs.

That is simply not true, and is a non-sequitur to boot. It _is_ true that the GNU project decided to make it hard to create proprietary modules [or otherwise external modules] for GCC, but nothing stopped a user [in principle] from doing either of those things. The GPL doesn't require a project to make themselves usable as a library.

> GPL being incompatible with app store rules kind of breaks freedom #2 and #3.

But "app stores" are acting against user freedoms, which is why you can't distribute GPLv3 software [without additional permissions] in most "app stores".

In fact, I would argue the GPL is doing its job well here. It's preventing the re-distribution of free software in a way that harms user freedoms. That's sort of the whole point. Just because you don't care about how "app stores" treat users doesn't justify claiming that copyleft is acting against users here...

Re: Show HN: Algorithm Cookbook in Rust

#69

Post by whyever »

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…

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

Doesn't this apply to any language?

Re: Show HN: Algorithm Cookbook in Rust

#70

Post by tormeh »

dsacco wrote: post #62
tormeh wrote: post #32

Earlier quoted context omitted.

It's a worthy cause. At HN we might all be aware that Java and C++ suck, but others might not know. Assuming others know what you do is a common cognitive bias. To us, this might be a slightly childish thing to have as a goal, but it might be a revelation to some readers.

> At Hacker News we might all be aware that Java and C++ suck, but others might now know. Assuming others know what you know is a common cognitive bias. The irony here is astonishing. I am a frequent commenter on HN and I rather like C++. I acknowledge its shortcomings without resorting to the tribalism that is marring the reputation of the Rust community. Please don't assume that all of Hacker News has a homogenous…

I'm not saying that Java or C++ are useless per se, just that they suck compared to many other options we have available.

Of course they both have tremendous utility, but so too does a 15 sqm house. Doesn't mean it doesn't suck.

Post reply on HN