boris

> For example, let's say that you have Postfix using a smarthost as a relay, and the new version of Postfix requires relays to have a shared secret for authentication with each of their trusted clients. That isn't something that can be handled by an automated config translator.

This would be roughly equivalent to adding a new column or a table in a relational database with some non-NULL/empty data in it, right? Somehow we deal with this in that case, or at least we are forced to deal with it or the transaction gets aborted rather than what we have currently, which is, "oops, new postfix has been installed, you didn't read the documentation carefully, and none of your servers can send mail anymore".

>It's possibly to state in a single command "show me the drift in my config files/data versus the ref I'm running" and/or "show me the diff between my running system and an update I may apply".

I can see how this can be usable for configuration. But I am having a hard time imagining how this would look for something like PostgreSQL's data files.

Most of these focus on running containers. What I would like is a distribution that focuses on the reliability of upgrades, both configuration and data. To give a concrete example, I have a Debian server running Apache (with auto-certificate renewal), PostgreSQL, and Postfix. When it's time to upgrade to the next release, it's basically the "it should work, but who really knows, depends on your specific setup you may have to tweak a few things" kind of guarantee. What I want is a rigorous guarantee like we have for relational database schema/data migration.

> [...] treated some of the code used for various feature checks invalid and the end result was checks failing even though they should have passed - often with barely any notification to the user (the user would see a "no" instead of a "yes" in some check)

This is a perfect illustration of conceptual bankruptcy of the autoconf approach. Using compile/link tests and basing a decision on whether they succeeded or failed without distinguishing the reasons for failure will inevitably lead to silent false negatives.

If you are wondering what to do and what are the alternatives, here is one approach: https://github.com/build2/libbuild2-autoconf

> Cmake is the de-facto option and is an ancient horrible mess that feels like a miracle if it works at all. What's left?

There is build2[1], which tries to approximate Cargo's experience for C/C++ projects while providing more depth, especially in the build system (unfortunately the "build by convention" ship has sailed for C/C++ so there needs to be some flexibility).

As some indication of the project's "seriousness" (there are a lot of toy build systems out there), it builds Boost and Qt (both 5 and 6 but only classic for now).

[1] https://build2.org

I wish we had a culture that expected every new C/C++ build system to handle a non-trivial project like Boost or Qt (and their dependencies, like ICU and OpenSSL) before it being pitched as the new best thing. It's trivial to make a build system that elegantly handles your own toy projects that follow your preferred style and structure. But the real world of C/C++ is a harsh place with a lot of variability.

> Mistake 1: Not using sdl2-config

> Mistake 2: Including SDL2/SDL.h

The overarching mistake here is not using a proper build toolchain (build system and package manager). I especially take issue with this assertion:

> The correct SDL2 include is the following:

> #include "SDL.h"

Including headers with the library prefix (#include <SDL2/SDL.h>) is our only hope to have an inter-operable ecosystem of C/C++ libraries. Let me illustrate this with a concrete example. What the article suggests is having the header search path (i.e., -I option from sdl2-config) pointing to the location of the SDL.h header (say, /usr/include/SDL2). But there are other headers[1]in there. Thankfully, most of them have the SDL_ prefix (by all means an exception rather than the rule, when it comes to C/C++ libraries), but not all. For example, there is the generically-named begin_code.h header.

Imagine now that your project is using another library with the same arrangement which also contains a bunch of generically-named headers and one of them happened to be called begin_code.h. Now which one gets picked up depends on the order of the -I options that are passed to the compiler.

[1] https://packages.debian.org/stable/amd64/libsdl2-dev/filelis...

You were fixing it the right way, details are here: https://news.ycombinator.com/item?id=34298159

> superbly coherent design [...] NT is pretty neat, and I would dare say, beautiful in some places

Practically, though, it's a shit show. My "favorite" is the inability to delete a file that is open by another process. Combine this with Windows Defender that scans every file that your application creates, and now you have no reliable way of deleting or moving your files.

As someone who works on a C/C++ build toolchain and has to deal with Windows design decisions every day, I can tell you without any hesitation there is nothing coherent or beautiful about it. I don't think even Microsoft believes this.

> The ctl file also lets you control other connection settings, such as keep alive.

Yes, though this could have been achieved with a bunch of sysfs-like entries under /net/tcp/127.0.0.1/80/<port>/ with the added benefit of being easily discoverable.

> It would also be unfortunate to run ls in /net/tcp and dump the entire IPv4/6 space into your terminal.

A reasonable semantics here would be to only list hosts to which there are active connections.

> you open /net/tcp/clone to reserve a connection, and read the connection ID from it. Then you open /net/tcp/n/ctl and write "connect 127.0.0.1!80"

This feels so ham fisted to me. Why not just open /net/tcp/127.0.0.1/80? I am sure there are reasons, but if the goal is to make everything a file, this feels like a more natural representation.

With kitesurfing you also have the lines in the mix. The biggest waves I personally surfed were 8m (what can I say, I was young and stupid). One guy dropped his kite and the next thing he was standing on the shore with every section of his kite ripped out. We were all feeling sorry for his ruined kite but he was happy to get out of there alive. Apparently he got tangled in his lines underwater and thought he was done but by some miracle managed to get out.

That's not shooting yourself in the foot, that's a compiler slapping you in the face for attempting to.

What do you do when some of these mentees (as you put it) get so used to having every question promptly answered that they stop reading the documentation or putting even a modest amount of effort into figuring out why things don't work as expected?

To be clear, I am not being facetious/sarcastic; I have this exact problem at the moment (in an open source project) and could use some tips. Surely you (or others) must have run into this. My best idea so far is to throttle my replies proportional to the offences.

I wonder how this is deployed to presumably a large number of hosts? Do you build a distribution package out of your Rust build and ship that? If so, what about the Rust standard library? Though I believe some distributions do provide a package for the Rust standard library, but that means one also has to use the packaged rustc/cargo, which tends to lag behind quite a bit.

CppCon is organized by the Standard C++ Foundation (and a ton of volunteers), which is a non-profit organization. When I was involved quite a few years ago, I believe they were making a modest "profit" on the conference which I am pretty sure was all wiped out during COVID due to the hotel commitments they enter into.

One thing that is unique about Estonia is its corporate tax system. Specifically, a business does not pay any tax on profit that it does not distribute as dividents. Meaning that any profit that you re-invest into the business (or just save for the rainy day) is not taxed. It's hard to appreciate what a game changer this is unless you've experienced the traditional system with capitalization of assets, depreciation, etc.

BTW, if anyone else knows of other countries with a similar tax system, please share (I did a bit of research but couldn't find any).

> You should use /c/... paths on Windows rather than C:/...

This is the start of the realization that building C/C++ on Windows is only the beginning of the pain. Once you are past that, there is a multitude of semantic differences like paths, CRLF, the fact that file move is not atomic, the fact that an opened file cannot be removed (e.g. because Windows Defender or some other BLODA is scanning it), etc, etc. It's a death by a thousand papercuts. My suggestion is to avoid supporting Windows at any cost.

Last year we were holidaying in Drakensberg (mountaneous area in South Africa) and for my birthday I've decided to run the "Big 5" hike which involves climbing five hills in the area (it's at Cavern). About 20k with ~2000m elevation gain. Took me 4 hours and I was pretty much dead at the end, but the best birthday gift I gave myself, ever!

The point of taking notes is not to preserve the information (or at least not primarily) but to load it into the brain where the connections can magically be made, as you put it. Rich Hickey has a nice talk on this called "Hammock Driven Development".

> Also, the community is toxic.

I think "somewhat dogmatic" would be a more accurate description of the Rust community, IMO.

For example, I recently had a discussion about `enum` being a poor choice for what Rust makes it to mean from a C/C++ developer's point of view (which are Rust's main "replacement target" languages). The closest I got someone to agreeing with me is a sentiment along these lines "well, `variant` would may have been a better choice but it's not very familiar to C/C++ developers and, besides, when this decision was made, Rust had a hard limit of 5 characters on keyword length".

> There are however valid questions, like if Rust slows down your development say, 5%, would you get more net safety from spending 5% more time testing/fuzzing c++ code instead? etc.

I think a similarly valid question is how often you resorted to dynamic allocations just to get the borrow checker off your back. If your Rust version uses 5% more dynamic memory (with the corresponding performance and memory footprint penalty), is it perhaps worth staying with C/C++ and spending more development time on testing/fuzzing?

You probably mean relinking: to compare old .o to new, you would need to recompile the source file to get the new .o.

> It is almost magical changing a linker flag in some bazel config and see it _only_ relink affected targets.

I think this should be expected from any modern build system. Now, if you make a whitespace change in your source file and the build system recognized this and skips recompiling it, that could pass for magic (build2 does this for C/C++ sources).

C++ burnt through a lot of good will in the C++98 era where it was admittedly a hot mess (and all the compilers where buggy dumpster fires). Now on one hand we have people who publicly and loudly swore off touching C++ ever again based on this experience (and even more people parroting the “C++ is a mess” statement without any experience) and on the other the excitement of Rust with all the hype making people invest a large amount of effort into learning it.

"The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt." Bertrand Russell

One tool (actually a build toolchain) that you may want to check then is build2: https://build2.org

I think this is the correct line of reasoning but I disagree with the conclusion: yes, MSVC is (unfortunately) most battle-tested where codegen is concerned. But next I believe is MinGW GCC, not Clang. Clang is used to build Chrome (and Firefox) but both of these codebases have C++ exceptions disabled. The result is you end up with bugs like this[1] which remains unfixed for years. IME, MinGW GCC`s achilles' heel is requiring pthread (via libwinpthreads) for C++11 threads support (see here[2] for details).

[1] https://bugs.llvm.org/show_bug.cgi?id=45021

[2] https://github.com/build2-packaging/libmingw-stdthread#backg...

I wonder what are your plans regarding the build system/package manager? Specifically, do you plan to roll your own language-specific tooling (with some support for building C dependencies)?

It you are looking for news on C++20 modules support, then, sadly, there is not much progress since GCC 11. I've re-tested my modules examples[1] a few days ago with the GCC 12 snapshot, and while a few bugs have been fixed, the majority remain unfixed[2].

[1] https://github.com/build2/cxx20-modules-examples

[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524