191–200 of 200 posts
Earlier quoted context omitted.
Trust me its way easier than you think and there are tons of free resource available you dont need a $36 book to build git.
You probably misunderstood: they're not talking about building from source (which is easy), but rather about recreating Git from scratch in another programming language (which is hard).
Earlier quoted context omitted.
You probably misunderstood: they're not talking about building from source (which is easy), but rather about recreating Git from scratch in another programming language (which is hard).
No I understood, and it is still easy. https://news.ycombinator.com/item?id=19386141 https://youtu.be/MYP56QJpDr4
Earlier quoted context omitted.
No I understood, and it is still easy. https://news.ycombinator.com/item?id=19386141 https://youtu.be/MYP56QJpDr4
I didn't watch the video but I've gone through that guide you linked, it's excellent but I don't think it's a great comparison. It only implements a handful of commands and doesn't go into the same amount detail. The Building Git book goes way more into the interesting bits.
Earlier quoted context omitted.
In principle I agree, but note that such projects are not created in a vacuum. Someone who goes out of their way to put that much unsafe into the codebase is more likely to commit mistakes that lead to ub than someone who just writes C stuff.
> Someone who goes out of their way to put that much unsafe into the codebase is more likely to commit mistakes that lead to ub than someone who just writes C stuff. [citation needed]. And it would be hard to find a citation because most Rust codebases don't have much unsafe. The repo you're thinking of was an anomaly and has since improved a lot.
Well, this can be related to an actual real-world concept, that is "programming in a certain language with the syntax/runtime of another".
In my experience, all the times I've seen this happening, the project was just terribly written.
I program in Rust, and if I happened to put an excessive¹ amount of unsafe code in Rust, it means that simply, I'm not programming in Rust. In my opinion, in real world this phenomenon happens for beginners, lazy programmers, or bad programmers, especially for Rust, because it has a steep learning curve, and it requires an effort, when designing a project, that other languages don't require.
So there is a point, although theoretical, that a good programmer in an unsafe language, can produce a more stable project than a bad programmer in a safe language.
With that in mind, I still wish as others to see unsafe languages disappear :-)
¹="excessive" is of course subjective.
Earlier quoted context omitted.
For applications like Web browsers the "inner loops" approach to optimization isn't nearly enough. Execution of important benchmarks smears out over huge amounts of code. If executing straight-line code in your favourite language is just a bit slower than C++, or touches more memory than C++, it's a losing proposition.
Yeah, but Web browsers are very much like OSes, and can be considered a special domain where Rust indeed can be useful.
Earlier quoted context omitted.
Yes! Rust's error handling story is excellent. You can still swallow errors if you want to but you have to manually write unwrap() so it's much more visible.
Not to be overly pedantic but calling .unwrap() is about as far from swallowing an error as you can get. That's gonna panic right away if it's an error case.
Earlier quoted context omitted.
I didn't watch the video but I've gone through that guide you linked, it's excellent but I don't think it's a great comparison. It only implements a handful of commands and doesn't go into the same amount detail. The Building Git book goes way more into the interesting bits.
My whole point was it is way easier than one thinks and there are good free resources available. Once you do the basic of git filesystem , object storage and sha basics implementing the rest of the API is trivial in comparison.
Earlier quoted context omitted.
> it's against C More specifically, I hope, C++. I like to think of asm, C, and Rust as a trio. C isn't "better" than asm; it just doesn't make sense to use asm when C does the job. And it doesn't make sense to use C when Rust does the job. C++ is where, in almost all scenarios, I draw the line and say, this would be probably be better if new code is written in Rust.
It's generally against both C and C++, because the reason applies to both of them. That reason being that using these languages expose users and the world to huge negative externalities in the form of security vulnerabilities, or alternatively (but resulting in the same conclusion) that the speaker just likes writing correct code. > And it doesn't make sense to use C when Rust does the job. There are few jobs left wh…
All: Rust has clearly reached the now-it's-a-flamewar-trigger stage of the hype cycle. Nobody wants that. If you're posting to HN, please stick to interesting specific things, not boring generic ones. Programming language flamewar is not interesting, so please don't do it here. https://news.ycombinator.com/newsguidelines.html
I am one of the devs who got attracted to Rust's advantages over C/C++ (no double free or use after free, guaranteed memory ownership, relatively fearless concurrency) and have been using it increasingly to the point of now professionally working with it.
But I never felt the need to degrade others for not using it. I do have my strong opinions about when and where it should be used but I almost never escalate them to flaming (sadly it occasionally happens even to the best humans).
I'd hate it if such an excellent technology's well-deserved adoption is held back because its core user base is viewed as zealots.
:(
Earlier quoted context omitted.
Only if you have no dependencies and interact in no way with any platform-specified services. Now certainly there are platform-specific things with Rust as well, but the defaults are structured in such a way that exposed APIs are more likely than not to be platform independent--you have to go out of your way to break compatibility, rather than it being the default. And once you get your binary to compile, the static…
Static linking means that if a security flaw is found in a dependent component, you're responsible for shipping a whole new application binary to the end users; they can't just pick up some new shared libs from upstream of you.
Both sides are fair points and it depends on a plethora of other factors which should be chosen for any given project.