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

Git: Introduce Rust and announce it will become mandatory in the build system

lore.kernel.org

Post reply on HN
Print view View original

371–380 of 433 posts

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#371

Post by tredre3 »

yencabulator wrote: post #287
lucasoshiro wrote: post #134

Earlier quoted context omitted.

Agreed. And if someone is interested in contributing to the Linux kernel, a new programming language is far from the hardest thing that they need to learn...

Rust will, in fact, make it significantly easier to contribute. In C, you have to remember lots of rules of when what is safe and what locks to hold when. In Rust, APIs are structured to make unsafe use impossible without explicitly saying `unsafe`. Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.

> Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.

This is how it works in the kernel on the C side, too. Usually by using guard/scoped_guard which wrap the generic mutexes with some RAII.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#372

Post by bitwize »

hoppp wrote: post #365
bitwize wrote: post #361

Earlier quoted context omitted.

There's also the fact that if you want to recruit systems programmers for a project like git, the 19-year-old catgirls who are likely to be interested in that sort of work all work in Rust. Ask one to hack a legacy C code base and she might nyao at you angrily >:3

Why not zig tho.. keep the C, compile with zigcc and write new code in zig. Best of both worlds.

uwu but zig doesn't give you memory and concurrency safety guarantees, oniichan!

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#373

Post by forrestthewoods »

saltcured wrote: post #352
forrestthewoods wrote: post #240

Earlier quoted context omitted.

> Is this a bit of chickens coming home to roost as far as developer culture forgetting how to work with cross-compiling toolchains? I don't understand your comment. Completely ignorning Rust the modern state of cross-compilation is an unmitigated disaster. Linux is especially bad because glibc is badly architected pile of garbage stuck in the 80s. It should be trivially possible to target any minimum glibc version f…

You mostly understand my comment, but not my graybeard perspective. The modern disaster is exactly that developer culture has forgotten how to do this for the most part. But, you're focusing on Rust compiling when I don't think it is relevant. If those weird financial platform developers were aware of cross-compiling, they wouldn't think that a developer tool like Git has to be built to run on the target financial se…

Definitely agree the world has utterly lost the principle of cross-compiling. Support for cross-compile really should be a first-class and sacrosanct principle.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#374

Post by yencabulator »

tredre3 wrote: post #371
yencabulator wrote: post #287

Earlier quoted context omitted.

Rust will, in fact, make it significantly easier to contribute. In C, you have to remember lots of rules of when what is safe and what locks to hold when. In Rust, APIs are structured to make unsafe use impossible without explicitly saying `unsafe`. Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped.

> Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped. This is how it works in the kernel on the C side, too. Usually by using guard/scoped_guard which wrap the generic mutexes with some RAII.

Interestingly enough, this is the only mention of scoped_guard in Documentation/. I will definitely argue that (that part of) Rust is way more approachable.

  Using device-managed and cleanup.h constructs
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  Netdev remains skeptical about promises of all "auto-cleanup" APIs,
  including even ``devm_`` helpers, historically. They are not the preferred
  style of implementation, merely an acceptable one.
  
  Use of ``guard()`` is discouraged within any function longer than 20 lines,
  ``scoped_guard()`` is considered more readable. Using normal lock/unlock is
  still (weakly) preferred.
  
  Low level cleanup constructs (such as ``__free()``) can be used when building
  APIs and helpers, especially scoped iterators. However, direct use of
  ``__free()`` within networking core and drivers is discouraged.
  Similar guidance applies to declaring variables mid-function.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#375

Post by yencabulator »

yencabulator wrote: post #374
tredre3 wrote: post #371

Earlier quoted context omitted.

> Concrete example: in Rust, locking a mutex returns a handle that lets you access the data protected by the mutex, and the mutex is unlocked when the handle is dropped. This is how it works in the kernel on the C side, too. Usually by using guard/scoped_guard which wrap the generic mutexes with some RAII.

Interestingly enough, this is the only mention of scoped_guard in Documentation/. I will definitely argue that (that part of) Rust is way more approachable. Using device-managed and cleanup.h constructs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Netdev remains skeptical about promises of all "auto-cleanup" APIs, including even ``devm_`` helpers, historically. They are not the preferred style of implementation, mer…

  #define guard(_name) \
          CLASS(_name, __UNIQUE_ID(guard))

  #define CLASS(_name, var)                                               \
          class_##_name##_t var __cleanup(class_##_name##_destructor) =   \
                  class_##_name##_constructor

  #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
Yeah Rust wins this one hands down, without breaking a sweat, and without really even noticing there was a competition.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#376

Post by sunshowers »

egorfine wrote: post #349
sunshowers wrote: post #173

Earlier quoted context omitted.

?? I build Jujutsu and many other Rust programs from source on Windows. Rust has a much better Windows story than C and bash do, due to its heritage as a language built by Mozilla for Firefox.

> Rust has a much better Windows story than C This is an extremely strong statement. Which is so obviously factually incorrect that I tend to think you might have meant something else.

I meant exactly what I said.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#377

Post by AlexeyBelov »

bitwize wrote: post #360
sebtron wrote: post #98

I am curious, what is the reason behind introducing Rust in Git? I am not familiar with Git development, I am just a user. But my impression is that it is already a complete tool that won't require much new code to be written. Fixes and improvements here and there, sure, but that does not seem like a good reason to start using a new language. In contrast, I understand why adding it to e.g. Linux development makes sen…

The whole point of Rust is that C, and all the code written therein (or as much as is feasible), be eventually replaced and abandoned. The potential costs of continuing to use C, and all the memory and concurrency bugs that come with it, runs in the billions worldwide if not more. Besides which, in 2025 all the real ones are using jj, which is 100% Rust, not git—so if git wishes to remain competitive it needs to catc…

I don't know even one developer who uses Jujutsu.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#378

Post by AlexeyBelov »

johnisgood wrote: post #180
cschep wrote: post #85

Earlier quoted context omitted.

Ok, I'll bite. While we are on Hacker News, this is still an enormously obtuse way to communicate. Are you saying that as users of git we will be negatively affected by deps being added and build times going up? Do you have evidence of that from past projects adding rust? Why not just say that??

No need to bite. :P We will see!

See what? Why are you vague-posting?

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#379

Post by johnisgood »

AlexeyBelov wrote: post #378
johnisgood wrote: post #180

Earlier quoted context omitted.

No need to bite. :P We will see!

See what? Why are you vague-posting?

We will see how larger the binary will become, we will see how many more (if any) shared libraries it will depend on, and we will see how long it will take to compile.

Clear enough for you? It is a note to myself, and for others who care. You might not care, I do, and some other people do, too.

Re: Git: Introduce Rust and announce it will become mandatory in the build system

#380

Post by account42 »

hedgehog wrote: post #159
uecker wrote: post #91

Earlier quoted context omitted.

We might also have different priorities. I do not care too much that google and apple want to lock down their smartphone spyware and sales platforms. The supply chain risks and maintenance burden imposed onto me by the Rust ecosystem are much more of an concern.

I don't know what this has to do with locking down phones, but I do appreciate not getting compromised just for cloning a repo or opening my laptop at a coffee shop.

How often do you clone a repo and don't immediately run build commands that execute scripts provided by the repo.
Post reply on HN