Hacker News

> 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 2 days 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 2 days 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 a day 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 a day 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.

yencabulator a day ago [ - ]

  #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.

oreally 2 days ago [ - ]

Except now these software engineers have to code switch between languages.

Could you software engineers stop making things harder for yourselves and playing this meaningless flex of a status game, and you know, focus on something tangible, meaningful, instead of adding more bureaucracy?

IshKebab 2 days ago [ - ]

I'm guessing you aren't a software engineer based on this comment, but the difference between programming languages is tangible and meaningful. It isn't like human languages where they're mostly basically the same and achieve the same thing.

And code switching between languages is not hard at all.

oreally 2 days ago [ - ]

It's hilarious that you can assume such a thing just by a couple of words on the internet. Or maybe I'm not a 'software engineer' by your standards because unlike your closed group of SWEs I'm a lot less focused on resume padding and keeping my codebase sane and not exploding in complexity.

I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.

Say you've not worked on this secondary language for a long time, which absolutely happens, and have spend hours of effort to recall it. This takes time that you need not spend on, it's how your memory works.

testdelacc1 2 days ago [ - ]

I didn’t make the assumption but it sounded like a reasonable assumption based on the pronouns you used. You said “could you software engineers stop making things harder for yourselves.” A reasonable interpretation of this is that you aren’t a software engineer.

Reinforced softly by the rest of your comment not being technically sound. Adding a second language that is meaningfully different in its strengths and weaknesses isn’t “bureaucracy”. Bureaucracy is more like “sign a CLA before you can contribute”.

oreally 2 days ago [ - ]

Okay then how about another interpretation: I'm a software engineer questioning the boarder group of SWEs on what they're trying. (Somehow I have to show you another interpretation I can't believe how tunneled people can be).

Also bureaucracy is added friction, usually done by humans. It can be found everywhere where you're working with humans, from leetcode interviews and code styles and practices. It's not just a bunch of signed papers.

Sure you can add the second language if adds value, but let's not pretend that the added friction isn't there. If you could solve your problems without the friction of second language it would be better.

motorest 2 days ago [ - ]

> I should specify - it's hard in that it's troublesome to have to code switch and do a bunch of recall before working on the thing.

You don't sound like you have any experience working on software projects. I can tell you it's not hard to switch between programming languages. If anything, the difficulty level is placed on onboarding onto projects you are not familiar with, but the programming language in use is far from being a relevant factor if you already are familiar with it.

oreally 2 days ago [ - ]

you're completely missing the point.

Even if it's 'not hard' your brain has to compensate for switching to another realm/space and that takes energy and time especially if you haven't used that particular space for a long time.

This is backed by science. Go read up on short-term working memory and crystallized memory.

All this will add up the maintenance costs, so it had better be a good trade off.

IshKebab 2 days ago [ - ]

Dude you said "Could you software engineers stop..."

In normal English that means you aren't a software engineer.

oreally 2 days ago [ - ]

[flagged]

hu3 2 days ago [ - ]

[flagged]