Show HN: Algorithm Cookbook in Rust
github.com
github.com
That makes it easier for sample code to achieve the ends of maximum code reuse and popularization of the underlying technology.
Clean IP history is especially important for "universal donor" sample code intended to be copy/pasted. If there turns out to be an IP violation in library code, with luck it may be possible to excise it from the library -- and hopefully not too many downstream will have forked it. But when code is copy/pasted, the linkage is severed and the damage becomes increasingly difficult to repair.
For those reasons, I'd prefer to see something like a contributor list of public identities for collections of sample code, so that it is transparent who is making the licensing promises.
For example, if a project under the Apache License 2.0 were to accept a contribution of CC-BY-SA code, the complete product could no longer be available under the Apache License (and other licenses with similar terms) -- causing problems for downstream consumers.
[1]:http://cglab.ca/~abeinges/blah/too-many-lists/book/README.ht...
What else is there?
Rust tries to guarantee that you've implemented things correctly and safely, and therefore makes all the formal verification of such into a requirement.
Other low-overhead-bare-metal languages, meanwhile, trust you to have done the formal verification yourself using non-compiler-toolchain tools like linters and static analyzers.
The people who use these other languages who do ensure correctness+safety, will have done all the same work they do in Rust—just using third-party tools instead.
The people who use these other languages but who do not ensure correctness+safety, might seem to have an "easier time", but they will almost always end up with algorithms/data structures that—while seeming to work in most cases—have fatal flaws or vulnerabilities.
To use Rust is simply to sign up for "doing the work" of formally verifying your code up-front, rather than brushing it off as something to think about in some vague, undefined "later."
* 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.
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.
Doesn't this apply to any language?
That said, my biggest Rust-gripe has been writing recursive / self-referential data structures. Borrow system is just not very convenient for that and you end up restructing the code to be a bit more Rust-friendly.
Also I think they sort of show the value of Java's simpler approach with everything being a reference in terms of writing code quickly. The alternative approach that C++ competitors use relies on a very specific style unlike what production code at say Google uses, with pointers used as sparingly as possible. With everything being a reference it is much easier to work with graphs for instance.
To me Rust goes even further into the C++ direction where it becomes more and more difficult to quickly write code that compiles. With Java I have no issue writing 100 lines and having everything compile the first time around, particularly with an editor like Intellij. With C++ even Clion struggles significantly with producing helpful info, simply due to the complexity of C++.
Anyway don’t have enough time to really eloquently think through all aspects of this. Also I was just kidding about CF rating, you are far better than me obviously.
To put context around my provocative comment earlier: I write C++ professionally. C++ is the right choice for my organization, though for purely historical reasons. In the long run, I think we'd all be better off if Rust or similar languages replaced their predecessors. So my comment came from a place of personal frustration, the same that led me to find Rust in the first place.
The old wording was too negative; I'm just excited to show that contest programming, which one might imagine to be hard to translate, is not only practical but indeed arguably nicer in Rust.
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.
Of course they both have tremendous utility, but so too does a 15 sqm house. Doesn't mean it doesn't suck.
Especially since the ownership model of rust makes the classic graph representation of edges owning nodes impossible.
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...
I think GPL3/MIT as a dual license should be a decent compromise.
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.
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.
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.
Right. That's reasonable. The point of my comment was to express disagreement with something that seems obviously true to you. I'm happy about the decrease in copyleft for its own sake. I dislike copyleft because I dislike intellectual property, on which, copyleft relies upon. (There's no need to debate this further. I've done it many times already.)
> It's just a shame that people are willing to stunt their own languages just to make a point about licensing.
You say "stunt," I say "free." Mischaracterizing this into a group of people indulging in some trivial holy war is absurd.
Others are more practical than me. Languages are permissively licensed to drive adoption. Regardless of the theory of copyleft, and regardless of rationality, people are afraid of it and stay away from it.
I promise I won't debate this further, I just wanted to say that I also dislike the concept of intellectual property. The reason I like copyleft is because it takes the draconian machinery of copyright and puts it to work protecting users.
Yes, it inconveniences developers, but I think users are more important. You wouldn't prioritise the "right to jerry-rig" of bridge architects over the people who use their bridges.
> You say "stunt," I say "free."
I'm not sure how making it harder to change out parts of a compiled program makes the language "more free". It's a feature that's missing.
> Languages are permissively licensed to drive adoption.
I don't disagree with that (though I think compiler _implementations_ should be copylefted). But that's not the point, my point was that if you can't replace parts of a compiled program then LGPL loses its appeal.
Right. I understand the "copyleft fights against IP" argument. :-)
> I'm not sure how making it harder to change out parts of a compiled program makes the language "more free". It's a feature that's missing.
Really? Are we really not above misappropriating words? My point wasn't to lay claim to the word "freedom." My point was to say how silly it is to bake our biases into our descriptions of the world around us. The various perspectives on freedom are well covered by the Internet at large, and extend far beyond the realm of IP.
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.
.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.