That’s not a good argument. Most of these additional languages are used for separate things, like build scripts and stuff. They don’t affect actual kernel code which is C and assembler language.

It is hard when you mix them in one codebase and need bindings and wrappers for interoperability. This always introduces additional work and maintenance burden. It’s always a tradeoff and for most projects not worth the effort. Tech corporations that do this regularly have dedicated teams to deal with boilerplate bullshit and tooling issues, so that regular devs can just code with minimal friction. Rust-in-Linux community decided to take it upon themselves, but I’m not sure if they can keep it up for years and decades in the future.

Though gradually getting of C is still a good idea. Millions of lines of C code is a nightmare codebase.

AFAIK kernel itself doesn’t send any signals to processes on shutdown/reboot, it just stops executing them. This is a job service manager (e.g. systemd) that terminates processes using SIGTERM before asking kernel to shutdown.

That’s why you launch them through systemd.

Some differences I see: Shepherd does some firewall management with ports, and I don’t see the services it depends on.

That looks like it sets up sshd to start when someone connect to its port, not on boot. You can do the same with systemd, but you need additional .socket unit that will configure how .service unit is activated.

Why this kind of files should be written in a programming language at all? I guess it’s a remnant from the old times, but I like when tools abstract away the programming parts, and users shouldn’t have to deal with that

Systemd invents its own configuration language (it looks like ini but there no standard for that and systemd’s flavor is its own) so you still need to learn it.

That’s the problem of most general-use languages out there, including “safe” ones like Java or Go. They all require manual synchronization for shared mutable state.

Variable names shouldn’t need comments, period. You don’t want to look it up every time this variable is used in code, just to understand what it holds. Of course there are always exceptions, but generally names should be descriptive enough to not need additional explanation.

And context can also come from names of other things, e.g. name of a class / namespace that holds this variable. For example AccessibilitySettings.HighContrast, where AccessibilitySettings holds all options related to accessibility.

It looks mostly the same as XML views but some components look and behave wildly different for no apparent reason (tooltips are one of those).

I have given up on the fight a long time ago. On the desktop the only line I draw is that the app must respect system font configuration and use system-provided file dialogs.

JS by itself is very fast (it’s one of the fastest dynamic languages). It’s interop with platforms APIs that is slow, at the fact that each React app spins up its own instance of Chromium also doesn’t help.

Same with Compose even though it’s ironically considered native in the Android dev community.

The easiest way to tell that the app is not native is tooltips (those that appear when you long press on a button in a toolbar). For some reason UI frameworks just can’t agree to display them in the same way, even if they use material design. Compose’s ones are especially bad (some apps like Play store actually have different kinds of tooltips on different screens, meaning they use multiple UI frameworks in the same app).

That can be true for self-contained command line tools, but not for complex programs with actively development dependencies (especially anything dealing with networking or encryption). For example hexchat uses GTK2 which is likely to be removed from mainstream distro repos in the coming years because it has been obsolete for a long time. Also openssl which is known to change its API occasionally which means that anything that uses it needs to be updated to stay compatible.