I bet it has better dependency management / fewer ecosystem issues than C++, somehow

MIT is the “do whatever you want” software license, as long as you include the original copyright and license, and don’t hold the authors liable for damages.

That’s my understanding yeah. Another neat thing if I’m reading things right is that the equivalent of issues and reviews and PRs are stored as git objects in the repo itself, so distributing the repo also distributes the “metadata” surrounding it that is invisible to git when the repo is hosted on github, gitlab, forgejo, etc.

https://radicle.xyz/ seems interesting in this regard, though I haven’t found the time to look too deeply into it yet

deleted by creator

To expand on this: the better the collaboration between sales and programming, the better for everyone involved. I have no experience on starting businesses, but it feels to me that when starting or expanding a business, one often needs to sell products that don’t exist yet. Because building something in the hopes of selling it is very risky, as the product you develop might risk not being able to properly satisfy the needs of anyone and therefore could end up not selling.

Selling something that doesn’t exist yet instead guarantees a sale and therefore funding, but sales and programming need to be aligned on the difficulty of creating said product (or adapting an existing one) and the timeline to do so.

Few things cause a bigger sense of loss in programmers than being told “we sold this thing that needs to be ready in 2 months” when the programmer knows it needs 6 months to be built correctly. It’s a fantastic recipe to make programmers miserable, product managers miserable, clients miserable, and likely sales miserable too.

Well you’re in luck, you also will soon not own your own car either. No public transport though, that’s communist.

deleted by creator

we, the developers, invest money

The developers don’t invest money and they don’t decide shit. Software is not optimised because the managers and shareholders are only interested in more tracking and new “features” that only exist to deliver a payload of more tracking. More tracking means more data that can be sold.

Optimisation funding is under error margin levels in the vast majority of industries and for the vast majority of products.

Far too many developers are also terrible at their job and are unable to write decent code in the first place, but they get zero say either way.

Yeah I second this. I’ve been on wayland for a few years now and while my needs are pretty standard I also regularly need slightly-off-the-beaten-path features. Not everything used to always work, but in the last, I want to say 18 months, I never found my needs lacking.

Multiple monitors work, adaptive sync works, mic / webcam works, screen / window sharing works, remote desktop and wayland forwarding works, etc.

That’s not to say everything is guaranteed to work all the time, but I am surprised to see people saying that even today they always find something fundamental that is broken when they attempt to switch.

deleted by creator

I call it mario driven development, because oh no! The princess is in a different castle.

You end up with seemingly no code doing any actual work.

You think you found the function that does the thing you want to debug? Nope, it defers to a different function, which calls a a method of an injected interface, which creates a different process calling into a virtual function, which loads a dll whose code lives in a different repo, which runs an async operation deferring the result to some unspecified later point.

And some of these layers silently catch exceptions eating the useful errors and replacing them with vague and useless ones.

deleted by creator

Interesting. I once didn’t update the arch system on my laptop for several years, while it was sitting in a drawer. Had to manually update the keychain but besides that the update just worked

That’s why I included “do research”. I absolutely agree that reinventing everything is not the way forward, but I also think it’s important to get stuck on a problem before looking up what the possible solutions are, because that is when you are in the best position to understand them and how / why they work to solve the problems.

If you write nested if after nested if, hopefully at some point you go “hold on, is there a better way?” And then you do research and learn. That is not to say that learning for knowledge’s sake is bad. It isn’t. In fact it’s great. But it might also be a bit dull to just follow tutorials and such.

Quick guide on how to get better at X: do X a lot.

Programming is no different. Write programs and do research (aka google stuff) when you get stuck or when you want to further your knowledge. Repeat 100000 times and you’ll know lots.

To answer you: no, x += 1 cannot mutate my_var, because it’s a copy. If you wanted something else you would say auto& or auto*.

And if the type of x is such that even a copy can mutate the original (e.g. maybe it’s a wrapper around an index with an overloaded operator+=() that mutates the original entry in the storage), you are probably working with a specialized system of some kind, since that breaks the semantics of the language, and hopefully you would know from context that you have such cases.

And yes, in such an environment I would see “never use auto for this wrapper type” as a valid additional strategy to help ensure code correctness.

But by and large my direct experience is that using auto “almost always”, as Herb Sutter puts it, is beneficial and doesn’t harm readability or understandability.

auto doesn’t really hide all type information, but that is besides the point. The point is that in the vast majority of cases you don’t really care about the specific types your code is dealing with, you only care about the properties of the type.

If I write get_descriptors()[some_idx] what is the type returned by get_descriptors()? You can’t know, because nothing tells you, but you know it must be a type that supports random access indexing. If I put the result of the function call in a for loop, it must support iteration. If I return it by move, it must support being moved.

99% of code is like this. Then you have specialised code that might be doing bit wrangling and what not, in which case you must know that you are dealing exactly with, say, an uint32_t and not just something that supports left shift.

For the 99% of cases, auto makes the code simpler, more correct, more robust, more consistent, and shorter to write and read.

The post I replied to in particular got angry at documentation that uses auto. I have written documentation that looks like this

auto my_var = MyConcreteType { /* … */ };
auto const* x = my_var.get<uint32_t>();
auto const& y = my_var.get_or<uint32_t>(42);

How would such code benefit from not using auto?

MyConcreteType my_var = MyConcreteType {}; just repeats the type, adds zero useful info.

MyConcreteType my_var {}; is inconsistent. Where is the equal sign signifying that this is an assignment?

Similarly, what would you gain by saying uint32_t const* x = my_var.get<uint32_t>();? Nothing, you just doubled your maintenance when you need to change the type passed to the template parameter.

https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

deleted by creator