hckrnws

A lot of people misunderstanding Rust's appeal for this kind of thing:

Git is about data integrity. Improved correctness is extremely valuable here.

Rust can be injected into native projects because it has no runtime requirements. So here it's ideal and makes a true rewrite unnecessary unlike other languages.

Rust is creeping into system software as a wholistic replacement. It's very rare that a language can actually entirely replace C/C++. However it's discovering that the process is incredibly slow.

There are things Rust isn't as good for, but it's only a matter of time before those gaps close (mainly around specialised environments and targets).

I don't know if Rust will actually succeed in replacing C/C++ before something better comes along but the writing is on the wall. If you want to get in early on Rust, now is a good time.

It seems strange to call now early on rust given how long it has been around.

I personally believe that rust has some intractable problems that make it quite unlikely that it ever reaches even half of c/c++ level ubiquity. The problems begin with the incredible complexity of the language which manifests in cryptic error messages, puzzling syntax and brutal compile times. The latter especially is a complete non starter for me. I would have to be at risk of going homeless with slinging rust as my only employment option before I would voluntarily subject myself to rust compile times every day.

My hunch is that we are going to see smaller, more specialized languages take off in the next decade. Compared to past eras, it is now so much easier to build quality language tooling that we can have the best of both worlds: small targeted languages, optimized for the relevant problem domain, _and_ professional quality tooling.

You forgot the 10's of GB files the compiler generates for debug builds.

Cryptic error messages? maybe in comp time type level code

Puzzling syntax, I simply disagree, it’s not that bad, can you give an example?

Brutal compile times? Idk, for me it’s usually instant, and if there’s a problem I know right away instead of needing to wait for runtime crashes

Rust has been hella worth it for me. Only time I didn’t like it was when I tried to “impl Future for T” instead of writing “async fn”

> It seems strange to call now early on rust given how long it has been around.

The first stable release of Rust was almost ten years ago at this point so I agree that this isn't particularly "early" in technological timeframes, but I suppose it could be considered young compared to C++ (first stable release ~40 years ago) or C (~50 years ago).

Rust errors occasionally are difficult to comprehend, but in general I have found it to have the best error messages of any language bar none.

Can you exemplify what kind of specialized languages you think we will see? Is Zig an example?

I honestly cannot take a comment criticizing rust compared to c++ for brutal compile times

And I'm a c++ programmer

Or any c++ programmer using templates, as far as cryptic compiler messages.

Yeah. Do MLIR for my dayjob, and I'm waiting several minutes in between dev cycles.

does Rust even support incremental compilation correctly yet? after how many years now?

Rust has had incremental compilation on by default in debug builds since February 2018.

Data integrity in Git isn't that hard. It hashes things. And compresses things. It's not a file system. The kinds of bugs that would cause data integrity issues in Git wouldn't be improved by Rust, because they're regular old bugs, like adding or multiplying the wrong numbers.

In fact, Git is probably one of the types of programs that least benefit from Rust. As a one shot program, you technically don't even need any memory management. You can just malloc stuff and let the kernel collect it when the process exits.

if anything, memory management makes it slower...

In terms of the discussion detailed in the article let’s wait and see. It has to be a vastly superior alternative to make adding it worthwhile.

On the more fun side, when I read the headline I instantly thought of making a side project that lets you watch a bunch of language models in a chat room, infinitely bikeshedding among themselves about the merits of this decision.

Kind of like https://degenerative-sitcom.online/ but for bikeshedding :)

> making it easier for more people to contribute to Git

How far does that scale? How easy is it to contribute to any area of a project that is written in 17 different languages?

I actually co-maintain a project which has exactly 17 different languages* (though 3 of which are since removed, and 6 languages cover 99% of everything), and noone has ever complained when I add a new language for something throwaway... I think the real issue isn't using multiple languages, it's using a language as intimidating as Rust. Adding some C or C++ or JS to a project usually isn't nearly as problematic (although admittedly it certainly is for the sorts of inexperienced programmers who'd like to contribute to my project).

* If you're curious, in roughly decreasing order of use: FreeBasic/ReloadBasic, HamsterSpeak, Euphoria, C++, Python, C, Bash, Batch, XSLT, JS, Objective C, Emacs Lisp, Squirrel, GDB script. Removed languages: QuickBasic, x86 assembly, Makefile

When I saw "HamsterSpeak" I laughed out loud. Then I researched and found this gem: "HamsterSpeak is the scripting language used by the OHRRPGCE." This caused a second laugh.

Kudos to all HamsterSpeak programmers!

Rust is like systemd, it brings the crazies out.

... How have I never heard of so many of those?

Out of curiosity, why would you choose to add a new language for throwaway tasks? Is the project niche enough in various areas that these languages are truly orders of magnitude better than a common alternative for the specific task? Or is it more of a "I'd like to learn this new language, might as well see how it works in production" sort of thing?

Well for example I decided to use Emacs Lisp to search through the FreeBasic code for certain constructs so that I could use some elisp functions I'd already written to help edit FB in Emacs. It's throwaway, noone else will ever want to edit (or probably even use) it. FB is niche enough that there isn't much tooling available for it.

I did indeed add Squirrel just to try it out (I'm considering using it as a scripting language), though I wouldn't be surprised if Euphoria and XSLT were also originally used for that reason. XSLT is there for generating .html documentation. C because I needed speed but didn't want to use C++, C++ because a C++ programmer contributed, Obj-C for the Mac port, JS for the web port, x86 assembly for the original DOS version, Bash, Batch and Python for scripts... any project can quickly reach 10 languages this way.

Which project is this?

OHRRPGCE

Git is already a large binary in size. Hopefully if rust is added it doesn't make the binary size grow significantly larger, otherwise git may be harder to use in embedded Linux applications.

I didn't realize git was used in embedded. Is it for pushing... configuration changes? Code?

Not microcontrollers, but single board computers running off emmcs that are not too big. And yes, both code and configuration.

Honestly I'd have a lot more sympathy for hobbyists asking to hold off on using Rust because it'd break support for, I dunno, OS/2 or AmigaOS or Mac OS 9. If you're going to be flaunting the riches of the industry you represent maybe you can get them to chip in more to open source development.

I use cygwin as my daily driver for many things. This is why I started to hate languages like rust or go because they easily become a nightmare for me.

Rust was fine in cygwin for me. The only issues I had were where the build system choked on non-rust dependencies.

Who knows, Rust may even become a universal systems programming language within three or four decades.

"making it easier for more people to contribute to Git" doesn't seem like a good reason to introduce Rust. It is a constant refrain that Rust empowers unskilled people to write correct code, but I haven't seen evidence of this. I have seen a lot of intelligent people complaining about how difficult it is, and even after using it for quite some time, I still find it significantly more difficult than C++.

oxide exists... why inflict the issues of a "split brain" repo on a perfectly functional one?

rust and cargo are both such a nightmare to use, I really hope the RIIR meme dies out soon... I actually like that I can compile code without an internet connection.

What makes Rust and Cargo a nightmare?

Rust is just an aggravating language to use. Might just be a personal inability, but I lack the ability to tolerate arguing with the compiler when I know the code is correct just because the compiler can't prove it.

My issues with cargo, are less about the tool in isolation, but more how it's used. IMO Dependencies should be avoided by default, cargo encourages bad habits. If cargo as a tool behaved more like pip, where you'd call `cargo install dependency` and then completely unconnected `rustc build`. I'd have no issues with cargo. (Also note, pip has many more problems than cargo, but at least you don't use your package manager to run your python code)

It's possible I've still jaded because the first time I had to actually use cargo, it was setting it up for my team to work on it, and have it function, from within an air gapped network... never again!

> If cargo as a tool behaved more like pip, where you'd call `cargo install dependency` and then completely unconnected `rustc build`

This has the problem that your deps can get out of sync with your lockfile... which is why most/all the newer python package managers have a run command that works more like cargo e.g. https://python-poetry.org/docs/basic-usage/#using-poetry-run

If you tried it a while ago things likely improved since then. `cargo fetch` and `cargo vendor` are both single-command solutions for airgapped networks.

> arguing with the compiler when I know the code is correct just because the compiler can't prove it

I don't want to assume too much about your specific use case, but in a lot of situations that people describe this way, the truth is that the code would've been correct if it was C but -- because it violates the no-mutable-aliasing rule -- it's genuinely broken under the Rust memory model and will trigger UB if you use unsafe code to work around the compiler errors. https://youtu.be/DG-VLezRkYQ

I write Rust on an airplane with no Internet using Panamax. It’s pretty easy to setup if you have large disk https://wiki.roshangeorge.dev/index.php/Blog/2024-02-28/Rust...

If you find it aggravating to use, then it’s not likely this will make you happy but just in case it helps, you can just bake it into your image and be completely airgapped and the only real factor is storage because the actual functionality is easy.

Nice tool to know about. How much storage do you need to use it?

This is on my M1 Max Macbook Pro though it's probably the same on all platforms since the `dist` dir contains all platform distributions

   local du -h -d 1 .
 214G ./crates
  33G ./dist
 830M ./rustup
 2.7G ./crates.io-index
 250G

>> It's possible I've still jaded because the first time I had to actually use cargo, it was setting it up for my team to work on it, and have it function, from within an air gapped network... never again!

You can use the 'cargo vendor' command to download all of a project's dependencies and then transfer them to an air-gapped environment.

https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

This allows for the project's dependencies to be checked before they are introduced in the air-gapped environment and also placed in version control for a full snapshot of the project.

At $WORK we have been using Rust this way for a few years now and it has been great. Cargo is much easier to use than cmake, make, and other custom build scripts we were using before. After a few trials, we have been migrating projects from C/C++ to Rust and management has been impressed with the results. The code is equally fast, errors are down, and our velocity is improving since we find and correct more problems earlier in our processes.

Fair enough.

Cargo does have an `offline` mode for `cargo build` which won't hit the network, and you can vendor dependencies. You can also invoke `rustc` directly outside of Cargo. In general though I think the Cargo team is optimizing usability for the 90%ile who can and do use the internet while developing (which is also unavoidable with other language ecosystems). But getting stuck if you're in that 10% is always hard.

Rust is just an aggravating language to use. Might just be a personal inability, but I lack the ability to tolerate arguing with the compiler when I know the code is correct just because the compiler can't prove it.

That's what unsafe is for. From the rust book:

"Unsafe Rust exists because, by nature, static analysis is conservative. When the compiler tries to determine whether or not code upholds the guarantees, it’s better for it to reject some valid programs than to accept some invalid programs. Although the code might be okay, if the Rust compiler doesn’t have enough information to be confident, it will reject the code. In these cases, you can use unsafe code to tell the compiler, “Trust me, I know what I’m doing.” Be warned, however, that you use unsafe Rust at your own risk: if you use unsafe code incorrectly, problems can occur due to memory unsafety, such as null pointer dereferencing."

Is the proprietary operating system that HP Nonstop uses just HP-UX? If so it doesn’t seem that different from other operating systems that rust can use?

NonStop Kernel (NSK) is the OS for the Tandem hardware which had fault tolerant hardware (dual everything) and software (process pair with checkpoints) https://en.m.wikipedia.org/wiki/Tandem_Computers. The OS is not posix compliant, very different from HP-UX. It is used now mainly in financial systems, competes with IBM mainframes. I used to work on NonStop SQL databases.

I’m the one who posted the article. This is the first time I’ve ever even heard of NonStop.

From the entitle I assumed it had something to do with discussions that had been going on for a long time or kept coming up and it was just a typo or something.

Interesting to find out there was a an OS I never heard. Unfortunately the Wikipedia page isn’t very comprehensive.

I'd not heard of NonStop but I've definitely heard of Tandem. I think one is the other after going through a few decades of marketing spin.

The original company was called Tandem Computers. They called their systems NonStop. The OS was originally called Guardian, then it was Guardian 90, then NonStop Kernel, which had both Guardian and POSIX "personalities". Tandem got purchased by Compaq, then Compaq got purchased by HP.

Even their coffee mugs were fault tolerant.

https://www.computerhistory.org/collections/catalog/10262869...

I don't know how complete it is, but NonStop has had POSIX support since the mid-1990s. It's called Open System Services. It's got ksh, and various unix/posix apis/utilities, and a hierarchical filesystem.

I don’t want to be _that_ guy but I want this for zig instead of rust.

What I don't get is are people doing software development on these NonStop computers? Why? Or are they managing financial transactions using git?

probably configuration control?

It looks like NonStop supports Java. Is there a reason they can't just use JGit or something?

if its not broke ....

gitoxide is written in rust. why would they want copy paste code from it?

also, why they hate cpp? cpp without exceptions and late binding virtual inheritance is nice, and gpt said nonstop has full 17 and partial 20 cpp standard support.

Ah yes, Git not running on a niche, highly proprietary system will surely kill it. Delusional response from Randall.

Edit: lol I have a feeling some of you didn't, you know, read the article.

[flagged]

This isn't "Rust Evangelists" pushing Rust on Git, it's Git developers wanting to use Rust.

Also, there's already a separate from-scratch re-implementation of git in Rust (gitoxide).

> it's Git developers wanting to use Rust.

They're full time developers exclusively for git? How long have they been doing this? What is the set of their contributions to date? Of the total set of developers how many of them want this?

Is their set of desires anything more than "lets use Rust?" Is there a specific set of new functionality that would depend on it? New use cases that could be served with it? Is there even a long term plan for "new new C code" at some date?

I sense disaster fomented by poorly articulated goals.

> Also, there's already a separate from-scratch re-implementation of git in Rust (gitoxide).

Sounds perfect. Then each project can maintain the focus on their core language and not potentially take several steps backwards by hacking two incompatible pieces together with no roadmap.

  > They're full time developers exclusively for git?

By whom?

GitHub

The people who are trying to commercialize the product? It's interesting that with all this money all they do is send "their developers" into the mailing list to push the product and everyone else in their own direction.

Who owns github again?

You asked who is pushing this. The answer is people who are paid full time to work on Git. These are Git developers. Their names are mentioned in the article, it is not hard to look up what these people have done, what they are doing now, and who they work for.

What are you trying to get at? It's not a conspiracy theory, it's people who just want to be able to be more effective at getting things done.

There isn't a cabal of people in some Discord somewhere thinking things like "now how do we get Rust into a BSD". A lot of these suggestions are coming from people who have significant experience with unsafe languages and are sick of having to keep dealing with them.

> There isn't a cabal of people

There are people who take "Rust evangelism" to a level that few other languages have witnessed. In the old days you could find serious arguments that not using Rust was akin to violating human rights by a series of absurd extensions. It is unusual and it is remarkable.

> A lot of these suggestions are coming from people who have significant experience with unsafe languages and are sick of having to keep dealing with them.

And my commentary is coming from experience in codebases that try to "modernize" themselves incrementally, particularly, open source code bases. I would love a 100% Rust git replacement. The idea of slowly subsuming Rust into C git feels like a distracting and misplaced effort.

[flagged]

Who are the Rust maximizers? These are the Git developers themselves wanting to use it, not some random outsiders.

You don't need that unattainable level of confidence (a few years won't change it, there are too many variables at play and boo scientific tests) just like you didn't have it when choosing the original language