kaba0

> It's so bad that there are companies promising JDK8

Come on, that's absolutely not the reason behind. That just means that there are banks and such that still run goddamn windows XP completely firewalled off from the internet just because. Similarly, for some companies not touching that ancient codebase and just having it safely run worth the hassle and the money.

Java is the most backwards compatible language and it is not even a close competition.

It's only on Go, leave Rust out of it. Rust's safe part is entirely memory safe. Unsafe is the escape hatch, which pretty much every language has in the form of FFI.

Logic bugs != memory safety bugs.

E.g. in java you can mess up your logic with data races, but the racing itself is safe and can never cause the VM to enter an invalid state.

That would mean it, yes. And yeah there is a bug in rust's borrow checker which can trigger something like that for some very special, "no human will ever write code like that" case. But this is an implementation detail for a semantically memory safe language, while in go's case having UB is a language primitive here.

How is it not material? You only need to accidentally write and read a map at the same time in language that is supposedly for concurrency (which is why not the same as parallelism, in its case it does largely correlate).

This is a ridiculous design issue with big ramifications.

The old way has literally no way to differentiate between a frozen process and one that just simply wants to keep on running after the session's end, e.g. tmux, screen.

It's trivial to run these as a user service, which can linger afterwards. Also, systemd has a configurable wait time before it kills a process (the "dreaded" 2 mins timer is usually something similar)

There is no other way - most error conditions can't be dealt with at the place where the error happened. A parseInt failing is meaningless at the local scope, the error handling depends on who is the caller.

No, go has GOd awful error handling, it is C's errno wrapped in a slightly different syntax.

Yeah, it's a routinely mistaken term in CS, I have met plenty interviewer who I had to correct on it (most languages, but java is also pass-by-value. It just passes objects by pointer value. C is also always pass-by-value. C++ is one of the few exceptions, it does have pass-by-reference semantics)

The key point may be (summarizing from memory): a function signature can be backwards compatibly changed by either making a parameter it accepts nullable from a non-nullable type, and/or by making the return type non-nullable from a nullable. With union types of T | Null, this is a type safe refactor that requires no code change. The Maybe<T> variant on the other hand requires code changes no matter what.

I saw a big uproar in certain strongly typed FP communities around it, but I think it's more like different problem domains having different experiences. Many software operates in a closed world where they control everything, while other software has to communicate with other software that may change with a different schedule, owned by a different team, etc.

I wrote a bit more about it here: https://news.ycombinator.com/context?id=42020509

It mandates strict session termination, unlike the unsustainable wild west approach of older Unix systems. Proper resource deallocation is crucial for modern service management. When a user exits without approval of "lingering user processes," all their processes should be signaled to quit and subsequently killed.

Arch changed to systemd in 2012, at which point systemd was 2 years old. It surely had quite a few growing pains, but I don't think that's representative of the project. In general it was the first init system that could properly parallelize, and as I mentioned, it is significantly faster on most desktop systems than anything.

I see you, but win XP was literally end of life 10 years ago.

That RAM is unified though, not a good comparison.

Also, just because something holds true at large numbers doesn't mean it scales all the way down. Either due to economies of scale, or the negligibly different architecture/components at that size.

> It increases boot times

Is it really the case? On desktops it is significantly faster than all the other alternatives. Of course if you do know your hardware there is no need for discovering stuff and the like, but I don't know. Would be interested in real-life experiences because to me systemd's boot time was always way faster than supposedly simpler alternatives.

Well, if it doesn't handle a notoriously hard area basically at all, then frankly it's a pretty bad data point to bring up.

Is it a 6 years old take or what? Because it certainly is very smooth on even low-end machines nowadays.

I mean, that's just a register. The memory region itself is not special in any way, a random "heap" region that would be similarly frequently accessed would be just as fast.

Historically they do, and currently they don't because their biggest market is server machines where Linux is the de facto choice. It's a life or death question for them to properly support the Linux kernel.

Do you know of a language that supports interface versioning? I often wished for one (as I like writing programs by "iterative refining", where I basically copy the good parts into a completely new project), but have never heard of a language that does something like that.

Does it?

I mean, most people don't buy a new phone each year, let alone something as expensive as a laptop. They are probably still targeting Intel Mac, or M1 users for the most part.

It's optimizing as in previously it had far less attention.

Except for the M-line where they went out of their way to make it possible in a secure way..

> If you think you want to run Linux, don't buy hardware from a company that views it as a threat to their business model, simple as that.

Show me any hardware that is 100% "libre"? Even the pinephone itself has plenty of closed source blobs running as firmware.

How is that apple's fault, nor any form of "deliberate attack"? Like, come on, neither of the parties are malicious, especially not for the sake of it.

Even though, there are no lack of issues that are simply not cared about. E.g. thermal throttling for ThinkPads is a very annoying problem the best solution to is simply a python script that just periodically overwrites a memory location.

Are we living in the same world? Nvidia only recently started caring about Linux (due to profit obviously, it turns out servers don't run anything else nowadays).

May I remind you of the famous `--my-next-gpu-wont-be-nvidia` flag in Linux compositor? Meanwhile, apple literally went out of their way to make secure boot for third-party OSs possible.

Is it really a far comparison? Apple has a proper bootloader capable of secure booting 3rd party OSs. What part of the open-source ecosystem was built differently?

It just so happened that after possibly even more painstaking reverse engineering, the responsible hardware vendor later realized that server machines are de facto linux, and they better support it properly. Like, that Intel chip working that good was not achieved differently, we just like to wear rose-tinted glasses.

I am going on a bit of a tangent here, but I always wondered, are those of you who use absolutely huge event-driven architectures, have you ever got yourself into a loop? I can't help but worry about such, as event systems are fundamentally Turing-complete, and with a complex enough system it doesn't seem too hard to accidentally send an event because A, which will eventually, multiple other events later again cases A.

Is it a common occurence' and if it happens is it hard to debug/fix? Does Kafka and other popular event systems have something to defend against it?