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

Gitoxide: Pure Rust Implementation of Git

github.com

Post reply on HN
Print view View original

51–60 of 200 posts

Re: Gitoxide: Pure Rust Implementation of Git

#51

Post by roca »

amelius wrote: post #38
linkdd wrote: post #15

Earlier quoted context omitted.

I really don't understand the hate towards every language that is not Rust. Rust provide you tools to avoid many security issues. But that does not mean everything that hasn't been written in Rust is broken by default. You still have "unsafe" in Rust, so is it broken by default and design and we should throw away the language ? Obviously not!

I think garbage collected languages like Haskell actually provide better security than Rust, because the code is not littered with constructs dealing with memory management. The only reason to use Rust is if you need the performance. But often, that's only an issue in your "inner loops", so you could write the rest of your code in a more suitable language. Since in most cases these performance critical parts are only…

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.

Re: Gitoxide: Pure Rust Implementation of Git

#52

Post by roca »

foota wrote: post #27
ncmncm wrote: post #26

As I have understood it, the major coding flaws in Git involve failure to handle OS and file system errors responsibly. (The SQLite people are very persuasive on the topic.) Rust does not seem to bring anything new to this particular table. Any improvement in this area would need to inhere in library-level facilities constructed for the purpose. What are they?

Rusts good support for option and result types might help here.

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.

Re: Gitoxide: Pure Rust Implementation of Git

#53

Post by namKS »

phoe-krk wrote: post #4
linkdd wrote: post #2

Why do people feel the need to reimplement everything in Rust ? If it's not broken, don't fix it...

From the security perspective, if it is written in C, then it is broken by default and by design - no exceptions. See https://news.ycombinator.com/item?id=24133128 for a recent, very relevant discussion on that topic with multiple examples and a good rationale.

Ok, so CPython is broken by default and by design. Yes Sir, understood sir, no exceptions, sir!

Re: Gitoxide: Pure Rust Implementation of Git

#54

Post by amelius »

roca wrote: post #51
amelius wrote: post #38

Earlier quoted context omitted.

I think garbage collected languages like Haskell actually provide better security than Rust, because the code is not littered with constructs dealing with memory management. The only reason to use Rust is if you need the performance. But often, that's only an issue in your "inner loops", so you could write the rest of your code in a more suitable language. Since in most cases these performance critical parts are only…

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.

Re: Gitoxide: Pure Rust Implementation of Git

#55

Post by namKS »

phoe-krk wrote: post #21
linkdd wrote: post #15

Earlier quoted context omitted.

I really don't understand the hate towards every language that is not Rust. Rust provide you tools to avoid many security issues. But that does not mean everything that hasn't been written in Rust is broken by default. You still have "unsafe" in Rust, so is it broken by default and design and we should throw away the language ? Obviously not!

As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us countless pain via stack overflows, buffer overflows, memory corruption, and multiple other vulnerabilities that are literally baked into the language model. Dropping C for any sane alternative will be a massive boon.

Better do not use Lisp, since the interpreters have at least around 10% C.

Re: Gitoxide: Pure Rust Implementation of Git

#56

Post by phoe-krk »

namKS wrote: post #55
phoe-krk wrote: post #21

Earlier quoted context omitted.

As a Lisp programmer, I don't dunk on everything that is not Rust; I instead dunk on everything that is C. The extensive use of this language has brought us countless pain via stack overflows, buffer overflows, memory corruption, and multiple other vulnerabilities that are literally baked into the language model. Dropping C for any sane alternative will be a massive boon.

Better do not use Lisp, since the interpreters have at least around 10% C.

They're compilers, not interpreters - or at least SBCL, CCL, ABCL, ECL, Clasp, CLISP, ABCL, and LispWorks are. I'm not aware of any other alive contemporary Common Lisp implementations.

Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C. In addition, the Lisp compilers are written in Lisp itself, not in C, which further decreases the attack vector.

Also, the currently-in-progress SICL project intends to do away with C completely, even for its garbage collection and OS-interfacing parts.

Re: Gitoxide: Pure Rust Implementation of Git

#57

Post by phoe-krk »

namKS wrote: post #53
phoe-krk wrote: post #4

Earlier quoted context omitted.

From the security perspective, if it is written in C, then it is broken by default and by design - no exceptions. See https://news.ycombinator.com/item?id=24133128 for a recent, very relevant discussion on that topic with multiple examples and a good rationale.

Ok, so CPython is broken by default and by design. Yes Sir, understood sir, no exceptions, sir!

Sure. Do you have any arguments why it isn't broken and go against the arguments linked in the related HN discussion? Is CPython in some way immune to overflows, use-after-free, double freeing, and so on? How much of CPython is actually implemented in C, and how much in itself and/or in Python?

Re: Gitoxide: Pure Rust Implementation of Git

#58

Post by dragonsh »

oblio wrote: post #35
dragonsh wrote: post #28

Earlier quoted context omitted.

Not sure what is meant by pure, probably another way of marketing to Rust aficionados. It uses crates which still rely on unsafe ‘C’ code to interact with operating system for interacting with files and file related OS calls. It will be nice instead of proclaiming Rust as “C” replacement it should have positioned as “A language complementing C/C++ to write safe code”. Recently Servo project is abandoned by Mozilla fo…

> Not sure what is meant by pure, probably another way of marketing to Rust aficionados. "Pure" is not some Rust marketing ploy :-) It's a pretty established term meaning "written only with". I've seen pure Python, pure PHP, pure JavaScript, etc libraries and apps. It generally means you don't need another compiler to build or you don't need to know another language to contribute or fix things for yourself.

Rust market itself as replacement for C/C++ and proclaims as if all code written in C/C++ is garbage and only Rust can solve it, when majority of it's own useful crates heavily rely on unsafe "C/C++" code.

So "Pure Rust" is also marketing when you look at the crates used by this software are not Pure Rust, but rely on unsafe code of C underneath.

Python, PHP do not claim as C/C++ replacement, indeed Python is synonymous with CPython written in C.

In Rust community so far what I noticed is that they try to down-vote anything which shows them that Go language or Swift are more important systems programming language and Rust needs another 10 years to reach to write enough useful software like Go or Swift.

Also in Python look at the example of pure python HTTP server Cheroot [1] and check how many PyPI packages it relies on. Also it can run in CPython, PyPy or Jython or any implementation of Python. Rust does not have anything like this yet so using Pure is misleading given it only has one compiler dependent on LLVM (written in C++) to generate target binary.

[1] https://github.com/cherrypy/cheroot

Re: Gitoxide: Pure Rust Implementation of Git

#59

Post by nindalf »

MaxBarraclough wrote: post #43
est31 wrote: post #41

Earlier quoted context omitted.

rg "unsafe " | wc -l tells me there are 19 occurences, for about 13.7k lines of Rust in total. So it's not a lot.

Good to hear. It's important to ask though. There was an HN discussion a few months back on a Rust program that overused the unsafe features, to the point it may as well have been written in C. Sure enough, it turned out to be full of nasty bugs.

> to the point it may as well have been written in C

Mildly disagree. Even if half the code base is unsafe, that's better than a code base where everything is unsafe. Now I only have to audit half the code base for crazy shit, which is about half the effort. A stronger type system means that even in unsafe land, we can still encode some invariants better.

I disagree with this notion that "if you're going to have bugs anyway, what's the point of Rust". Our goal isn't to eliminate every bug in the world, it's to have fewer bugs today than we did yesterday. Rust, even Rust with several unsafes thrown in, helps us achieve that goal.

Re: Gitoxide: Pure Rust Implementation of Git

#60

Post by dragonsh »

atoav wrote: post #34
dragonsh wrote: post #32

Earlier quoted context omitted.

Reimplementation relying on unsafe ‘C/C++’ code (as most of the core infrastructure is written in them) is done more for marketing especially among language aficionados. Hope someone from Rust community can write something which can match some of the core software written in Go language, which has already proven its usefulness and quality in writing systems programs in networking and system infrastructure areas. C/C+…

> Reimplementation relying on unsafe ‘C/C++’ code (as most of the core infrastructure is written in them) is done more for marketing especially among language aficionados. Let's read the page we are talking about to check your judgment: " Project Goals: a pure-rust implementation of git including transport, object database, references, cli and tui " and " Non-Goals: replicate git command functionality perfectly " Doe…

It rely on other crates, have they been verified not to use C/C++ (i.e. all are written from scratch without interacting with C/C++)?

This software is as good as the crates it depends on to do those work. If those crates are not maintained this software will not work either.

Also I am expecting down-vote of this comments as well given the way Rust community works. :-)

Post reply on HN