7 ms·

Maybe I'm just old and moany, and I need to step aside for bigger and better things such as Rust. But. Now rather than needing to understand just C to work on

• GrayShade 1y ago
  > I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git. And they will keep working because the repository format isn't affected by the language git is written in.
  • account42 1y ago
    Believing that this will be the case forever is naive. At some point there will be extensions. Then those extensions will become all but mandatory for interacting with other git users.
• IshKebab 1y ago
  > I'm just old and moany, and I need to step aside for bigger and better things such as Rust. You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. In any case Rust is usually easier than C (excluding buggy C which is very easy to write), and certainly easier than actually learning the Git or Linux codebases.
  • hedgehog 1y ago
    I think it is often under appreciated by people who haven't worked in security how hard high quality C is in practice.
    • uecker 1y ago
      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.
      • hedgehog 1y ago
        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.
        • germandiago 1y ago
          Who says you do not? :)
          • hedgehog 1y ago
            Oh, I think it's a real problem, that's why I'm in favor of improved tools.
        • sunshowers 1y ago
          (There is a persistent idea that the lack of memory safety in C is good because it allows people to jailbreak their phones.)
          • rcxdude 1y ago
            It is a sad thing but I do root against secure boot initiatives because they almost entirely work to limit user's freedom instead of improving their security.
          • uecker 1y ago
            This is not what I said, but memory safety is certainly not anything which is a high priority for my own security. I still think memory safety is important and I also think Rust is an interesting language, but... the hype is exaggerated and driven by certain industry interests.
  • toast0 1y ago
    > You are. This is firm "I don't want to have to learn new things" territory, which isn't a viable attitude in this industry. It's viable, but limiting. Sometimes you have to do things you don't want to, which is why it's called work. But if you can choose what platforms you work on, you can orient towards things where things change less, and then you don't need to learn new things as often. Chances are, if you get into the weeds in a lot of C programs, Rust is in your future, but it's viable to not want that, and to moan about it while doing it when you need to.
    • altairprime 1y ago
      No one’s laying off COBOL programmers. Specialization has its upsides once the market isn’t saturated!
      • IshKebab 1y ago
        Well only because 99% of the world's COBOL developers were laid off decades ago (or switched to another language).
        • altairprime 1y ago
          The more things change,
      • Tadpole9181 1y ago
        As someone with experience in this specific niche, yes they absolutely are. There are no longer ten thousand retail chains asking for COBOL-based counterpoint PoS mods on a yearly basis. The COBOL market is basically tenured experts in existing systems or polyglots helping migrate the systems to VB or C# at this point. The market has plummeted and now it's in the final deflationary shrink before death.
        • altairprime 1y ago
          Ah, damn, I’m sad to hear that. Always respected the language. :/
  • oreally 1y ago
    [flagged]
    • pornel 1y ago
      Rust is over 10 years old now. It has a track record of delivering what it promises, and a very satisfied growing userbase. OTOH static analyzers for C have been around for longer than Rust, and we're still waiting for them to disprove Rice's theorem. AI tools so far are famous for generating low-quality code, and generating bogus vulnerability reports. They may eventually get better and end up being used to make C code secure - see DARPA's TRACTOR program.
      • nanolith 1y ago
        The applicability of Rice's theorem with respect to static analysis or abstract interpretation is more complex than you implied. First, static analysis tools are largely pattern-oriented. Pattern matching is how they sidestep undecidability. These tools have their place, but they aren't trying to be the tooling you or the parent claim. Instead, they are more useful to enforce coding style. This can be used to help with secure software development practices, but only by enforcing idiomatic style. Bounded model checkers, on the other hand, are this tooling. They don't have to disprove Rice's theorem to work. In fact, they work directly with this theorem. They transform code into state equations that are run through an SMT solver. They are looking for logic errors, use-after-free, buffer overruns, etc. But, they also fail code for unterminated execution within the constraints of the simulation. If abstract interpretation through SMT states does not complete in a certain number of steps, then this is also considered a failure. The function or subset of the program only passes if the SMT solver can't find a satisfactory state that triggers one of these issues, through any possible input or external state. These model checkers also provide the ability for user-defined assertions, making it possible to build and verify function contracts. This allows proof engineers to tie in proofs about higher level properties of code without having to build constructive proofs of all of this code. Rust has its own issues. For instance, its core library is unsafe, because it has to use unsafe operations to interface with the OS, or to build containers or memory management models that simply can't be described with the borrow checker. This has led to its own CVEs. To strengthen the core library, core Rust developers have started using Kani -- a bounded model checker like those available for C or other languages. Bounded model checking works. This tooling can be used to make either C or Rust safer. It can be used to augment proofs of theorems built in a proof assistant to extend this to implementation. The overhead of model checking is about that of unit testing, once you understand how to use it. It is significantly less expensive to teach C developers how to model check their software using CBMC than it is to teach them Rust and then have them port code to Rust. Using CBMC properly, one can get better security guarantees than using vanilla Rust. Overall, an Ada + Spark, CBMC + C, Kani + Rust strategy coupled with constructive theory and proofs regarding overall architectural guarantees will yield equivalent safety and security. I'd trust such pairings of process and tooling -- regardless of language choice -- over any LLM derived solutions.
  • ajsnigrutin 1y ago
    It's not "having to learn something new", but "having to be good at two things, both of which are full languages with their own specifics, problems and ways to solve them, two sets of compilers and some duct tape to hold them together. It's like putting steak on a pizza... pizza is good, steak is good, pizza on a steak might be good too, but to actually do that in production, you now need two prep stations and you can't mess up either one.
  • hoppp 1y ago
    Technical debt is real tho and the rust-c interop is not the best ever. Why not rewrite the entire git in rust and have two compatible versions?
• matheusmoreira 1y ago
  I've also sent some patches git's way and I can't say I'm thrilled about being forced to (finally) learn Rust if I want to contribute again in the future. I guess I'm outdated...
  • IshKebab 1y ago
    I feel the same way about C code though. I don't think C gets the right to be the one true programming language that everyone must know forever.
    • account42 1y ago
      Once the C evangelism strike force pushed C code into rust projects you might have an argument.
  • saghm 1y ago
    They're proposing porting over one small piece that has no dependencies and exposing it to the rest of git via a C interface. Yes, they'll presumably port more over in the future if it goes well, but it's a gross exaggeration to characterize this as somehow making it impossible to contribute without knowing Rust.
    • bArray 1y ago
      I know that it is a "slippery slope" argument, but in the future, it will become more difficult to contribute without knowing Rust. That's the entire point of introducing it.
      • harshreality 1y ago
        And also, a lot of people who hate C, or who never learned it well, will be able to contribute to more and more areas of the Linux kernel.
        • deleted 1y ago
          [deleted]
• Luker88 1y ago
  AFAIK git already uses multiple languages, github says its 50% C, 38% shell, 4% perl, then 4% TCL python 1% So "another language" here probably does not weigh as much, especially considering perl/TCL are the weirder one there. But for big projects like linux and git, this could actually be a consolidation step: you spent decades growing, hacking things on top of each other. You have mostly figured out what this project is and where it is going, it's time to think about safety, performance and remove old hacks. Rust feels like a good fit, imho.
  • bArray 1y ago
    I did check this out. The shell, perl and python are likely for scripting and not used during runtime. TCL is likely some form of dynamic scripting. I think we also have to be honest about what the project here is too, it's not to have both C and Rust together, but to replace all C with Rust. In which case, it probably makes sense to just clone to repo and work on a fork like they did with SSH.
    • rascul 1y ago
      A number of the git commands were implemented in perl and shell. Now I see only git-svn is perl here for me and there's still a few shell scripts in /usr/libexec/git.
    • rbehrends 1y ago
      > The shell, perl and python are likely for scripting and not used during runtime. Some git subcommands are implemented in these. git filter-branch is a shell script, git cvsimport is a Perl script, and git p4 (perforce interop) is a Python script. There are not too many left these days (git add -p/-i also used to call a Perl script), but they exist.
      • tankenmate 1y ago
        I'm sure you are aware, reading between the lines of what you said, why, but for some others who aren't aware of the history of git; it was originally about 50% C and 50% Perl, the performance critical parts were written in C and then various git commands were written in Perl. Over time almost all the Perl was removed because there were less Perl monks than C devs. Now it would seem the logic is reversed; even though there are less Rust devs than C devs, Rust is going to replace C. Maybe now that git is large enough and entrenched enough such a move can be forced through.
• motorest 1y ago
  > Now rather than needing to understand just C to work on Git/kernel, you now need to also know Rust. I'm yet to know a single software engineer who isn't well versed on multiple programming languages. This is not a problem.
  • lucasoshiro 1y ago
    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...
    • yencabulator 1y ago
      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.
      • tredre3 1y ago
        > 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.
        • yencabulator 1y ago
          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.
• Borg3 1y ago
  Im on the same boat :) But no worries. You can always build and use older git without rust. Of course, it will work for a while until those kids will change the proto for the "better". And being old and grumpy also means, you can slowly care less and less about all that moot :) Kids: now downvote it into oblivion :) Like I give a shit...
  • 1718627440 1y ago
    These things often get presented as an age thing, but I think they aren't. It's very weird, I'm young but I feel like having the same stance in a lot of topics, in politics, but also here. I don't know how to deal with this. You guys have it easy (/s), you don't have to live with this for long, but I feel like I'm growing up into an increasingly hostile environment.
    • Borg3 1y ago
      Well, it is age thing, because young people start they experience in current tech and only those determined enough can take a look on past tech, how it was used and how it evolved. Thats always was minority.. There are just 2 kind of people there: Those who belive and those who research.. ;) Well, dunno what to say about it to you.. Its indeed sad.
      • 1718627440 1y ago
        Well the young people I meet know a mix of Python, C++ and C. And then they are those, who don't use C, because its too high-level and design their own processors instead. That's the current tech I experience directly.
        • Borg3 1y ago
          Hah.. C as too high level :) Thats weird.. Its cool to design sth from scratch, like its own CPU, but it only makes sense if you really enjoy it.. Except, its waste of time. I myself live in retro computing abit, but it have it limits. Like, I would not go back to prised 6502 CPU. Yeah, it was great, legendary CPU, but if we take a look at even cheap options we can buy and use for hobbie projects, there are plenty of pretty quick and capable 32bit CPUs. Its hard to go below 32bit really. Dont get me wrong, I pay big respect to demoscene, and what they can achieve on C64 for example :). Uber skilled guys, but this is an art :)
• jdiaz97 1y ago
  Removing Perl and adding Rust instead is probably reducing complexity rather than increasing it.
• thayne 1y ago
  Look at it from the other angle, there are many developers (myself included), especially younger developers who would much prefer developing rust to c, and for at least some of them, don't want to learn how to write c (including how to avoid undefined behavior). > I've written my own Git clients and have built a web server around Git repositories. I don't want to lose the hack-ability of Git. How does the git project using rust inhibit your ability to do any of that?