Because it is a interesting excercise to reimplement something great in a new interesting language you wanna test drive?

Why are people writing new programming languages? After all we already have some. Sometimes you do it for fun and frivolity, sometimes because you think you can do better, sometimes because you are addressing real tangible issues with the old way of doing things and often a combination of the three.

Honestly I used to find the "rust evgangelism strike force" obnoxious and naive, but man, after reading this thread and seeing all these brand new accounts that seemingly have nothing to do but complain because someone used Rust in a neat project, I'm honestly starting to think their attitude is 10x more obnoxious.

As we used to say, "haters gonna hate". It used to annoy me but now I mostly ignore it. If other people don't see the value in technical novelty that isn't directly in service of making money or having enormous impact otherwise, that's their loss - I'd rather spend my time hacking on something cool than defending the practice to someone who starts the conversation on the defensive.

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++ replacement at this time is just a wishful thinking given Rust cannot work without C/C++ today, most useful crates will break if underlying C/C++ code is not maintained or updated.

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

Doesn't sound like they are relying on unsafe C/C++ code at all – and sounds like they are just doing it out of curiosity. Unless you mean that parts of the git infrastructure (beyond this project) use C/C++ and therefore as long as you don't rewrite everything at once, their effort remains meaningless, which would be quite a dire world view, so I am assuming you mean something different which I don't get atm.

This wasn't about Rust – it was about you making quite vague claims about somebody's project. I don't know you, but I do write software myself and know how easy unfounded claims can go haywire. So before critiquing the work of someone else I'd rather make sure the points I make are true, actually something the person I critique could have avoided and adequate to the level of the project (e.g. a hobbyist should receive milder criticism than a big organization).

So if you are claiming there is C/C++ in the dependencies – therefore the project must not be a true scottsman and should not have been written – so if you put the burden of proof on the other side, maybe it is time for you to look into the mirror, and ask yourself whether your opposition to a simple programming language is not a bit... irrational..?

If a innocent project like this one makes you use that kind of rhetorical moves consider the possibility that this says more about you than about the thing you are commenting on.

There's valid criticism of Rust and then there's what you are doing, which feels distinctly like flat-earthism of computer science. You pick arbitrary goal posts (like, pretending that "unsafe" isn't a keyword in "real rust") and try use that to discredit a language that a lot of people have found super useful and superior in their work.

Replacing the underlying C/C++ code (including the kernel) is a work in progress. Not everything happens all at once.

I'm not talking about this project in particular. More about what will happen to the general C ecosystem.

I imagine there are different motivations for different people.

Some people may just want to use rust to re-implement something that exists in order to hone their skills or just for fun. Having a reference implementation makes that more productive.

Other people may think that it would simply be better if the project were implemented in rust. This is the case for some C projects, where a lot of control is still necessary but the project would benefit from the safety and productivity gains of rust. See the example of QEMU yesterday. It is an absolute pain in the ass to do things well in C. Correct programs end up being heaps of boilerplate and tests. I'd love to escape C but haven't been able to until Rust.

Maybe some people just want to showcase that Rust can do the thing. I think that's fine. It might help in adoption. It might cause better libraries to be created that are actually used.

For me, rust is the first real competitor in the systems programming market. There are hundreds of languages for application programming. I prefer Haskell, Java and JS for those but I've never found a replacement for C in the low-level domain. C++ just never cut it for me and the alternatives never really caught on. For me, Rust brings a lot of what we learned from Haskell and ML to C without sacrificing the low-level control. If I wanted to get better at Rust, I'd probably also implement something that exists just so I could check my work. If I was to re-implement some of the low-level projects that I've worked on, I'd also probably do that in Rust.

I'm getting really tired of comments like this though. Why does it bother you so much? Are you trying to communicate that you'd prefer this person be doing something else with their time? What does that even mean?

>For me, rust is the first real competitor in the systems programming market. There are hundreds of languages for application programming. I prefer Haskell, Java and JS for those but I've never found a replacement for C in the low-level domain

There is Pascal

I have used Pascal as safe C alternative for twenty years

It has solved all the C problems. Strings/Arrays know their length, you can enable range/overflow checking, reference counting ...

> or me, rust is the first real competitor in the systems programming market.

What about julia or go?

I don't know enough about Julia, but the definition of "systems" is different in Go vs. C/C++/Rust. Go is more of a Python, Ruby or Node competitor while Rust is more of a C, C++ or D competitor.

Doesn't mean that there is no overlap, but when you wish to go closer to the metal, picking Rust makes lots of sense.

Julia is positioned well to be a powerful high performance language in a niche market, that of scientific simulation, due to is reliance on long running. It also doesn't consistently match C benchmarks last I checked, "only" getting within a factor of 2 or 3. For a pythonlike language its very impressive and powerful, but its main competitive power is as a higher performance replacement for Matlab or mathy python.

Go is a competitor to Java, not C/C++.

> Julia is dynamically typed

Its gradually typed, and compiles down to typed code with LLVM on first run. So after a warmup (which can be cached) its effectively static for purposes of performance.

I was quoting the developers. I'll take their word for it. Whether something is compiled or not is orthogonal. I need strong static typing, preferably with algebraic data types. Julia doesn't provide any of that, Rust provides all of that.

If you do it for fun, or to learn, that is more than fine.

But seeing almost every day a new tech "implemented in Rust because X sucks and is not secure" is becoming annoying.

Keep in mind that the person who posed this appears to have nothing to do with the project, they're just someone who's seen something that interests them and shared it here, the same as the people voting it up.

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.

Yea no exceptions in C

Neither in Rust ;)

...have an upvote.

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!

The hate is not towards every language that is Rust, it's against C, at least in this thread.

I haven't seen anyone arguing against Python or Java in a Rust thread. Memory-managed languages are already at the memory safety levels comparable to Rust's borrow checker.

> 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 where C can do it and Rust can't, those jobs are generally "well there exists a C compiler for this architecture and not a rust/llvm backend". Rust is generally just as capable as C is at writing low level code. If you're willing to put up with translating macros by hand (or using wrapper functions), it's even capable of integrating with existing C code bases.

Lots of people still prefer C over Rust in various situations where you could use Rust, so I don't think it's a generally accepted fact that "it doesn't make sense to use C when Rust does the job".

Agreed. Very well put, thank you.

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.

I think ada can be good contender for C replacement

I think Ada's future is in safety-critical systems, where it makes sense to invest heavily in correctness, with the option of using SPARK and formal verification. Additionally, Ada has several mature compilers suitable for life-and-death applications.

For more ordinary software though, doesn't Rust make more sense? Its approach to memory management for instance, with a borrower-checker, seems much nicer than what Ada has to offer.

Disclaimer: I know neither language very well.

You need something with traction. How are you going to rally people to use ada? Where is the ada version of Gitoxide?

> You need something with traction

No language has traction, until it does.

It would be fair to point out though that Ada has had decades to catch on and replace C, but it hasn't done so, except in certain narrow areas of highly critical embedded software development in aviation and military applications. My understanding is that it's not easy to work with for 'general purpose' work (command-line applications on GNU/Linux), as it lacks mature bindings.

I think it's fair to say Ada failed to truly embrace Free and Open Source software. A pity, in my opinion.

Well they are trying to reach FOSS community. Recently they started survey asking community "Hello here, we (AdaCore) have some plan for the future of GNAT Community that we want to share and have your opinion on: https://forms.gle/Q34myTCQUXvrva5n7 " There is Ravenports very good port manager written in ada for FreeBSD so ada can be used for CLI apps and has good gtk binding too

A good sign, see also relevant discussion at [0]. I like the idea of a FORTH target that someone suggested.

Are the higher assurance-levels of SPARK going to remain unavailable to FOSS developers, as they apparently are now? [1]

[0] https://groups.google.com/forum/#!topic/comp.lang.ada/M3yS4S...

[1] https://www.adacore.com/sparkpro

Doesn't Ada have the same explicit deallocation and use-after-free problems C does?

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.

CCL:

Totals grouped by language (dominant language first):

  lisp:        336793 (84.60%)
  asm:          30410 (7.64%)
  ansic:        29862 (7.50%)
  sh:             718 (0.18%)
  objc:           299 (0.08%)
  java:             7 (0.00%)

> Lisp is a memory-safe language with automatic memory management, which removes all of the aforementioned classes of attacks that are available in C.

Yeah, right.

> Yeah, right.

In Lisp, the programmer never frees memory themselves, so use-after-free and double-free are not triggerable by the user. Bound checks for all array types are in effect, so overflows are impossible. Strong typing and a lack of casting prevent type confusion.

Do you have any arguments other than the unsubstantial "yeah, right"?

Lisp implementations using C means that the implementations may have C-related vulnerabilities, not Lisp programs themselves. You're not facing the risk of creating new C-related vulnerabilities by writing new application code in Lisp, even if the Lisp you're using has substantial amounts of the run-time written in C.

As others have said, the issue is with C style memory issues.

Rust not only gives you safety and correctness, but gives you often speed as a bonus over C. There is a real benefit towards rewriting everything written in C in a language/tool system like Rust.

There is still a place for other languages, especially ones that use a garbage collector. Rust would make that garbage collector a lot safer.

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 small in terms of lines of code, and hence easily verifiable by hand, you could even write them in C and still not have security issues.

Therefore, I think Rust serves only a very specific need, and isn't nearly as universally "the right tool" as everyone seems to believe.

They do have a nice packaging system, though.

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.

I think the same would be true of LibreOffice for example.

Since the top subthread comment has been predictably flagged by the clique:

Rewriting is easier than doing original work. If you manage to get people to use "your" new Rust project, you get a huge payoff for comparatively little work with lots of plagiarizing.

Someone should have told Linus to stop plagiarizing. Heck, someone should have told Stallman and GNU, too.

Your argument is quite flawed.

I just think there is more crucial project to rewrite than git, vim, etc...

At this point, it's just falling for the hype.

The same thing happenned with go, es6, etc...

"X is better than Y because it is written in Z" is not a valid argument.

A kernel in Rust? Yes please. A browser in rust? Can't wait. A fork of openssl in rust? Yes yes yes. A cli tool? Why? Is it really necessary?

And yes it is a genuine question, not some random rant.

I don't think every project has to be a crucial endeavor or a new thing. Let people do things for fun.

> A fork of openssl in rust? Yes yes yes.

https://github.com/ctz/rustls

I never implied you can't do stuff for fun.

Projects done for fun are not "marketed" as "a replacement for X"

I don't see this being marketed as a replacement for Git anywhere.

A git repo is often received from untrusted source in internet and there were associated bugs in git.

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?

is any rust code some way immune to unsafe blocks?

That's a little different. If you're running a C linter that statically guarantees safety, then it's comparable; otherwise, you're comparing mostly Safe Rust (with some Unsafe Rust in it) to Unsafe C.

Safe Rust is automatically immune to lots of these issues. Unsafe Rust isn't, but all of C is unsafe (unless you're using a safety-enforcing linter that only gives you access to a subset of the language).

Why should we care about arguments in a random HN discussion? We should care about arguments from people who have done substantial work.

Totals grouped by language (dominant language first):

  python:      578880 (54.33%)
  ansic:       475310 (44.61%)
  sh:            4073 (0.38%)
  cpp:           3847 (0.36%)
  asm:           1486 (0.14%)
  objc:           761 (0.07%)
  lisp:           502 (0.05%)
  pascal:         353 (0.03%)
  xml:            308 (0.03%)
  csh:             21 (0.00%)

Most of pure Python is in the stdlib.

> We should care about arguments from people who have done substantial work.

OK, we can drop the HN comments. Since Stefan Hajnoczi is a substantial QEMU contributor, how would you respond to the arguments linked in http://blog.vmsplice.net/2020/08/why-qemu-should-move-from-c...?

I don't think the author thinks git is broken, most likely the opposite. I often reimplement things I admire or want to learn how they work. I would guess that is one of the motivations of this project.

One reason is to avoid the nasty include C libs, that don't work everywhere.

Second reason, for fun.

Third reason, didn't you note all the parallelization gains?

Perhaps because it brings them pleasure. That hardly seems a sin. And then they share it with others, for whom seeing the work is a pleasure and perhaps an inspiration. That seems just as little of a crime.

I quote the README, in the goal section:

> become the foundation for a free distributed alternative to github.

> be the best performing implementation

This seems ambitious, and not something done for fun

Surely ambition and pleasure do not preclude each other.

I tried to interact with Git from rust code once. The only option for any language is libgit2 or its bindings, and let me tell you, it's terrible.

I was this close to just calling git from the shell when i eventually just gave up.

I used libgit2 a lot, the only thing I disliked about it was the lack of documentation (well, the source code is the ultimate documentation?).

Safety & performance.