Not fixing an unchecked malloc failure in an ncurses alternative gets you struck out on the list, but having unpatched vulnerabilities in a crypto library doesn't.
Less "bloat" doesn't mean more performance. C++ libraries have soundly beaten their C counterparts in HPC, HFT, ML, etc. And in any case it is still possible to write a C-dialect in C++ if you so choose.
Again, you can write a C89 (even more with C++20) dialect in C++. There’s practically nothing C can do that C++ can’t. Also, the fact that the linked page recommends tinycc and pcc pretty much proves they don’t care about performance or memory usage.
Inline is an hit, doesn't mean it gets really expanded, that is why compilers have extensions for "I really mean it, inline no matter what".
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.
Inlining a struct of callbacks is a much more brittle optimization in C than inlining calls to member functions on a class accepted as a template argument in
C++, which I consider a fair comparison because the former is the closest approximation C has for the latter.
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."
What is the best piece of software the musl/suckless/cat-v crowd have to offer? They smugly moan about the state of modern software but only manage to write alternatives to relatively trivial programs. For instance, it's ridiculous to recommend tinycc or pcc as an alternative to GCC or Clang.
musl itself, busybox let’s you have a full unix set of tools for 700kb, which is awesome for embedded Linux. There’s also dropbear, and ssh/sshd implementation in about 110kb binary. So when talking about bloat in embedded, it something very measurable when the option is a 32MB NOR flash chip for the root file system
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'd like to see the smug suckless crowd write anything resembling a modern 3D multiplayer video game today
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.
I don't know why you think we would take OpenGL over Vulkan, the former is orders of magnitude worse than the latter in every respect except for hardware compatibility. I work in games, specifically doing engine development. For some metrics, our last game has sold ~400k copies on Steam + GOG over its 7 year lifetime. I am the only programmer currently in a codebase that has some hundreds of thousands of lines of highly idiosyncratic C++ code that uses OpenGL. I also am our only form of tech support with any ability to actually fix technical issues. "without being extremely complex" what an absurd statement.
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.
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.
I used Siemens NX daily and Mathematica at home. While such programs are certainly “bloated” they work well and provide an incredible amount of value. The communities around musl/suckless/cat-v have absolutely no answer to how they could possibly replicate such programs in their paradigm.
Slightly off-topic rant about musl in the context of Alpine Docker images:
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.
I really like Alpine for making vm images. It is extremely easy to make the VM only run in memory or in data disk mode where the code is in ram but the files are persisted to disk with snapshots
That sounds like an interesting use case and a valid time to be concerned with image size. It's the cargo-culting optimization of Docker base images that I'm complaining about.
> I've never even understood the obsession with minimizing base image size
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.
Also if your infrastructure is elastic, image size can cause significant delay to scale-up and instance startup. At large scales it adds up to wasted money on provisioned resources spending time downloading the images. Very noticable with some domains that have multi-GB images.
> 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.
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.
34 comments
[ 3.0 ms ] story [ 74.9 ms ] threadAlso, the link to uSTL is dead.
At some point you’re going to run into virtual tables among other overhead.
A quick glance at Moe, I see inheritance in something as fundamental as buffers.
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).
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.
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."
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.
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.
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.
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.
https://wiki.alpinelinux.org/wiki/Installation#Diskless_Mode
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.