This is why the aforementioned ABI (of the latter language in the title of this post) won't die for a long time. The name of the game is compatibility, not performance/security. Bell Labs was first.
That is not true on Linux, where you can just make syscalls yourself. They don't even use the C ABI, even if it's pretty similar (For syscalls, the fourth argument is passed in R10 instead of RCX, since that holds the return address for sysret).
You can call a syscall with assembly, but the result it gives you follows C's formats. Maybe your language does integers in a different way so you still have to abide to it's standard to adapt what the OS gives you
I'd argue that it follows the CPU's native integer representation, which C also does. Yes, if your language uses tagged integers or something, you'll have to marshal the syscall arguments/results from/to your own representation, but the same is true if you want to use those integers for arithmetic (beyond trivial additions or multiplying/dividing by a power of two, for which you can use lea).
Mine was not a critique. Of course every OS needs to be programmed with a language and its syscalls will be formatted accordingly. And if you want to program using an OS's features, other than the compilation to assembly, you also have to worry about inter-operating with what the OS provides. I'm simply noting that for the foreseeable future, C's way of doing things will always have to be kept in mind when writing dev tools
Sure, that makes sense. Out of curiosity, do you know of any way to design a syscall ABI that's not C-like that was either used in the past or would have some advantages if a new OS adopted it? I imagine that lisp machines did things differently, but a) I don't know whether they had syscalls as such or simply offered kernel services as regular functions and b) they did have microcode support for tagged integers and objects.
I'm asking since I want to get into (hobbyist) OS development at some point and would love to know if there's a better way to do syscalls.
Yes, I think rust made a big mistake for not going for a stable (or at least mostly stable like C++) ABI (other than the C one). The "staticly link everything" is fine for desktops and servers, but not for e.g. embedded Linux applications with limited storage. It's too bad because things like routers are some of the most security sensitive devices.
The C++ ABI doesn't solve generics (templates); C++ templates live in header files, as source code, and get monomorphized into code that's embedded in the binary that includes that header. The resulting monomorphized code is effectively statically linked, and any upgraded version of a shared library has to deal with old versions of template code from header files, or risk weird breakage.
Swift has a more realistic solution to this problem: polymorphic interfaces (the equivalent of Rust "dyn"). That's something we're taking inspiration from in the design of future Rust stable ABIs.
> but not for e.g. embedded Linux applications with limited storage
Storage is often not the limiting factor for anything running embedded Linux (as opposed to something much smaller).
The primary point in favor of shared libraries is to aid in the logistics of upgrading dependencies for security. It's possible to solve that in other ways, though.
That's great, but the video goes on to say that he hired a trained manager (an MBA) with zero experience in manufacturing to manage the Macintosh manufacturing team...
That clip lacks context. Before that clip he was talking about engineers/designers. I think that documentary is just poorly edited, they interspersed Steve's monologue with something that was only loosely related to what he was saying. Manufacturing is labor, it doesn't require much brains. Whoever manages a team like that probably doesn't need to have much experience being on the ground floor.
Are you really surprised though? Like you alluded, people use Kubernetes and Bazel just because it has the big ol' G stamp on it. GraphQL is no different
(Well... slightly different. It's the FB stamp, not the G stamp)
I just picked java up again recently and it's really OK now. I'd have used it for my project but spring boot doesn't have an auto-generated admin like django so I binned it.
This is a great idea and I am glad it is BSD licensed. Unfortunately the execution is somewhat lacking. SQLite is best suited for embedded / clientside applications with minimal dependencies. The author of this project decided to use Go and make it a service.
> SQLite is best suited for embedded / clientside applications with minimal dependencies.
Often repeated and certainly rooted in truth but there was a healthy discussion on here the other day[0] where tptacek shared a link in a comment[1] to a related blog post about getting more scale out of using SQLite serverside.
You want to use an in-mem database like SQLite or DuckDB or even replicate the data structures in-code that redis uses. Redis doesn't really add a whole lot to the table over a general programming language with a good standard library other than being shared over a network.
