I just wasn't able to get the similarity results to match redis. Probably my own error, but that's why I opted for it instead of SQLite. We'll revisit at some point.
Apart from legacy projects written in Kotlin, after Java 21/23, what's the argument for using Kotlin anymore, especially that it's a proprietary language?
In what sense is Kotlin a proprietary language? It's Apache 2.0 licensed AFAIK. And there are many projects that use Kotlin which are not legacy projects.
I love java and kotlin. The gap has certainly swayed way more in Java's favor over the last 5 years, but there are still a ton of great features that kotlin does first and if that gives java a target to run toward in a lagging way more legacy compatible rock solid way, isn't this just a win for both camps? Just consider kotlin (JVM) to be java-beta with slightly different flourishes, and you wouldn't be too far from the truth. Kotlin is also very big in pushing their other initiatives that aren't entirely directed at JVM at least for now, like cross compilation native targets, compile time serialization primitives, totally structured concurrency, etc
Aside from the often cited nullability issue, here is an (incomplete) list of important things that Kotlin still does better than Java:
- First class, fully functional closures.
- Non-abstract classes and methods are final by default.
- Named parameters.
- Easy to write iterators via sequence { ... }
- First class support for unsigned types.
Honestly, lack of the ability to write free-floating functions in Java.
Recent Java features like records, pattern matching, sum types via sealed interfaces have certainly made it a much more ergonomic and modern language.
But having to wrap everything in "class" feels ludicrous to me.
The other ones are lack of explicit null types (meant to be addressed by JEP "Null-Restricted and Nullable Types") and inability to write anonymous types for functions.
That also created the biggest singular transfer of wealth. So your argument is that the peasants are no longer starving and well fed. If that's the ambition level you're happy to live by then there's no further comment.
Some managers at my current consultancy job think that ChatGPT is a low code solution worth selling to the customers as a service. I wonder if it’s a 4d chess approach to sell traditional programmers once clients realise that ChatGPT slop of code now needs way more than LLM-powered developers to maintain it.
PowerApps would not catch me endorsing it for anything beyond a year of use, however. Either a replacement needs to be on its way, or it's for a project with a defined end date.
Otherwise, "there's nothing more permanent than a temporary solution".
Are you saying io_uring is basically IOCP for Linux? If that's true, then I'm not happy about it being in the kernel. IOCP only goes 2x faster in my experience (vs. threads and blocking i/o) and that isn't worth it for the ugly error prone code you have to write. System calls are also a lot faster on Linux than they are on Windows, so I'd be surprised if io_uring manages even that.
Exactly. Came here to say the same thing. I live in zone 2 and I'd say that majority of the households don't own a car because they don't need one. We only got a car after we had kids and used to Uber around when we needed a car, a lot cheaper than full time car ownership.
Can someone tell me what's the advantage of eBPF over a user mode driver? The article makes it look it eBPF is have your cake and eat it too solution which is too good to be true? Can you run graphics drivers in eBPF for example?
AFAIK, an ebpf function can only access memory it got handed as an argument or as result from a very limited number of kernel functions. Your function will not load if you don't have boundary checks. Fighting the ebpf validator is a bit like fighting Rust's borrow checker; annoying, at times it's too conservative and rejects perfectly correct code, but it will protect you from panics. Loops will only be accepted if the validator can prove they'll end in time; this means it can be a pain to make the validator to accept a loop. Also, ebpf is a processor-independent byte code, so vectorizing code is not possible (unless the byte code interpreter itself does it).
Given all its restrictions, I doubt something complex like a graphics driver would be possible. But then, I know nothing about graphics driver programming.
> Fighting the ebpf validator is a bit like fighting Rust's borrow checker
I think this undersells how annoying it is. There's a bit of an impedance mismatch. Typically you write code in C and compile it with clang to eBPF bytecode, which is then checked by the kernel's eBPF verifier. But in some cases clang is smart enough to optimize away bounds checks, but the eBPF verifier isn't smart enough to realize the bound checks aren't needed. This requires manual hacking to trick clang into not optimizing things in a way that will confuse the verifier, and sometimes you just can't get the C code to work and need to write things in eBPF bytecode by hand using inline assembly. All of these problems are massively compounded if you need to support several different kernel versions. At least with the Rust borrow checker there is a clearly defined set of rules you can follow.
This is the wiki. I haven't kept up, but this isn't a kernel module.
"eBPF is a technology that can run programs in a privileged context such as the operating system kernel. It is the successor to the Berkeley Packet Filter (BPF, with the "e" originally meaning "extended") filtering mechanism in Linux and is also used in non-networking parts of the Linux kernel as well."
No, you can't run arbitrary general-purpose programs in eBPF, and you cannot run graphics drivers in it. You generally can't run programs with unprovably bounded loops in eBPF, and your program can interact with the kernel only through a small series of explicitly enumerated "helpers" (for any given type of eBPF program, you probably have about 20 of these in total).
