> 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.
I'm yet to know a single software engineer who isn't well versed on multiple programming languages. This is not a problem.
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.
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.
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. #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__)
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?
And code switching between languages is not hard at all.
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.
In normal English that means 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”.
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.
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.
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.