4 ms·
> 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
by 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 agoAgreed. 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 agoRust 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 agoInterestingly 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 1y 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 1y agoExcept 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 1y agoI'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 1y agoIt'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.