Musl: List of alternative libs that are lightweight, not bloated and efficient
wiki.musl-libc.org
wiki.musl-libc.org
I'd like to see the smug suckless crowd write anything resembling a modern 3D multiplayer video game today, from scratch, using OpenGL (oh, because Vulkan is 'bloat'—extremely ironic take, given Vulkan is closer to the metal than OGL), C, and their various collections of UNIXisms.
I'll bet they'll just dismiss video games as 'bloat' and mindless time-wasters, and 'you shouldn't play video games, just write code.'
I dislike this sort of dogmatic thinking. Use what works, use what is practical, use what is easy, use what is reasonably efficient and fast without being extremely complex. For me, oddly enough, this sits squarely in the 'sucks a lot' group of things.
I write my code in VS Code and Visual Studio on Windows, using CMake. I use C++ if I need native performance; otherwise, I use C#. I use LaTeX only if I am writing a complex paper or report which needs detailed typesetting, nice graphics, long bibliographies. Otherwise, I reach for Word.
I think XML is a great markup and serialisation tool, especially if one has a fully-conforming schema and code generator. JSON, YAML, TOML, etc. are all generally inferior to XML, by virtue of missing features that XML has. Proof by example: large, complex APIs (OpenGL, Vulkan, WinRT) are usually released in XML, upon which code generators may be built for different languages to generate projections in said languages. If these languages have reflection, one could even write the generators in the languages themselves.
I use the technology stack I do as a means to an end, and that end is not because I couldn't make a computer do something without the tower of shit I've got living on my desk. It's because I have to make money to live, and that means selling software to other people, so it should probably run on their computers. Most of the thinking that goes into my job isn't mathematics or theory. It's wrangling the absolute clusterfuck of a technology stack that consumers buy up by the millions and trying to hammer some kind of reason into it, ensuring that all the hundreds of moving parts of this massively complicated product run well on not just the computers of spoiled first worlders who think a 2060 is "low end", but on the tens of thousands of computers that run our games which are around 10 years old.
I would much rather live in an ivory tower and do everything from scratch and not have to think about making sure Ivan from Vladivostok isn't going to be shitting up the Steam forum because MSVC decided /O2 means "please reinterpret this code to run 10x slower than it did in your last minor version senpai" or the dozens of esoteric GPU issues I've had to solve over the years. Please. I would much rather be hand-rolling 3D rotation matrices than this shit.
And they wouldn't. That's the point. I don't think it's a matter of "just don't play games" either. Games don't have to look like <insert pretty "modern" game here> in order to be fun. Look at Battlebit for a recent example of this. It's not a minimalist game, but it surely ain't maximalist.
> Use what works, use what is practical, use what is easy, use what is reasonably efficient and fast without being extremely complex.
All of these are either subjective or based on personal needs. I agree, you should use what works for you. As should the people who like minimalist software.
UNIX was cool for a while, being stuck in the past, trying to pretend modern computing is all about reviving the experience of using UNIX V6, alongside twm, not so much.
The game development example is quite good one, as to this day, most people on those communities don't really grasp the demoscene and game development culture.
It's cool that we have an alternative to glibc, and it's cool that the popularity of Alpine Docker base images has caused developers to put the effort into expanding compilation support to a wide range of binaries. But personally, I got sick of how many hours I spent debugging a seemingly endless train of binaries that would fail in strange ways when running under Alpine, or that just didn't run at all because they were compiled with glibc. So I gave up and switched to using Ubuntu as a base image and never looked back.
I've never even understood the obsession with minimizing base image size, because it's not like it gets loaded into memory, and the fact that it's a base image means you share it with multiple images anyway, so you rarely even need to download or upload the layer over the network.
In theory image size shouldn't matter because of Docker's caching. In practice, however, many of the things we use around Docker (CI/CD, testing, orchestration and deployment tools...) don't take advantage of that cache.
A GitLab CI stage to build my container will still pull the base image and build up from layer 1 every time. The subsequent testing stages will do the same with the final image. The deployment stage will also need to pull it first, just to push it to the registry again, but with a tag this time.
The difference between the base image being a few dozen vs a few hundred megabytes translates directly into not just how much strain I'm putting on the network, but how long the pipeline takes. If I can reduce that by essentially just swapping the base image and search-replacing apt-get with apk, why not? Of course it isn't always that simple, but for most things where you're just something like Node or Python with minimal native extensions, it's definitely worth it.
Isn’t it also the case that less “bloat” can mean less code that potentially leads to fewer bugs? Reducing bloat can have other benefits sometimes.
https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
Also, the link to uSTL is dead.
At some point you’re going to run into virtual tables among other overhead.
Example: Callbacks in C are always virtual, whereas in C++ you can take the callback as a template parameter.
Not distinguishing between "virtual" or "function pointer" or any other names for the same concept (dynamic call address).
You might get a failure to inline and get direct calls to fixed function addresses in the latter case, but never virtual calls (unless the member functions themselves are virtual, of course). The former case relies on the compiler seeing through the entire call chain and being able to prove that the function pointers don't change.
The idea that virtual calls can bite you in C++ but not in C is clearly nonsense, as in any situation where you'd need a virtual function in C++, you'd need a function pointer in C, and virtual functions don't happen accidentally as you have to explicitly write "virtual."
C++ templates provide the mechanism to really inline complex code, run it at compile time and just place the result into the binary, instead of clunky preprocessor macros.
A quick glance at Moe, I see inheritance in something as fundamental as buffers.