The user interface looks very similar to Niagara Launcher. I found it a really fresh and comfortable alternative to the default android launchers

It is Niagara Launcher. They say so in the demo video.

wow, can you elaborate how adding a string field can break some assumptions?

Not the OP, but note that adding a std::string to a POD type makes it non-POD. If you were doing something like using malloc() to make the struct (not recommended in C++!), then suddenly your std::string is uninitialized, and touching that object will be instant UB. Uninitialized primitives are benign unless read, but uninitialized objects are extremely dangerous.

That's not what was happening in this example though. It would be UB even if it was a POD.

> This is why other systems languages are taking off (besides the expressiveness or memory safety bandwagon) is because there are clear instructions in the docs on what this does with examples of how to use it properly.

I have never seen better documentation for programming languages than cppreference. Can you list such docs?

> sometimes that’s actually what you meant — you’re calling it only for its side effect. Back in 2022, Stephan T. Lavavej estimated of unique_ptr::release that “90% of discards are a bug, but 10% are maybe valid…

What are these 10% valid cases? Does someone have an example

Here's a made-up example, not from any particular codebase:

try { f(p.get()); (void)p.release(); } catch (...) { /* f threw; don't release p after all */ }

better add a button to *enable* AI

uninitialized values are not the source of bugs. This is a good way to find logic errors in code (e.g. using sanitizer)

"bug" can refer to many categories of problems, including logic errors. I've certainly seen uninitialized variables be a source of bugs. Stackoverflow for example is full of discussions about debugging problems caused by uninitialized variables, and the word "bug" is very often used in those contexts.

What do you mean it is not a source of bugs?

> What do you mean it is not a source of bugs?

I think what they mean, and what I also think is that the bug does not come from the existence of uninitialized variables. It comes from the USE of uninitialized variables. Making the variables initialized does not make the bug go away, at most it silences it. Making the program invalid instead (which is what UB fundamentally is) is way more helpful for making programs have less bugs. That the compiler still emits a program is a defect, although an unfixable one.

As to my knowledge C (and derivatives like C++) is the only common language where the question "Is this a program?" has false positives. It is certainly an interesting choice.

I mean that bug is *not in* uninitialized variable - bug in program logic. E.g. one of code pathes don't initialize variable.

So, I see uninitialized variables as a good way to find such logic errors. And, therefore, advice to always initialize variable - bad practice.

Of course if you already have a good value to initialize variable - do it. But if you have no - better leave it uninitialized.

Moreover - this will not cause safety issues in production builds because you can use `-ftrivial-auto-var-init` to initialize automatic variables to e.g. zeroes (`-fhardened` will do this too)

is it already in open source? I would like to see and test it. Share it here - on HN, when you will be ready

Yup! But not in any state to be linked, really. First impressions are a big deal. If you’re really curious, my GH handle is tspader and the repo is spn. The graph branch has been the main branch for a month or so, I need to merge badly.

Thanks, it looks promising! I built it and felt cargo-style - friendly and colorful. Look like you really know what you do and what C community wait from such tool. So, I leave my humble star on repo :). Good luck!

Thanks for the kind words! I really appreciate it.

isnt jj undo the equivalent of git reflog (+ reset/checkout)?

Mostly, yes. It also covers changes to the working copy (because jj automatically snapshots changes in the working copy). It's also much easier to use, especially when many refs were updated together. But, to be fair, it's kind of hard to update many refs at once with Git in the first place (there's `git rebase --update-refs` but not much else?), so undoing multiple ref-updates is not as relevant there.

Can you explain how to do same workflow in jj? It would be nice to compare bads and goodies of git/jj

This part:

> You rebase feature-1 onto main:

feature2 moves as well. Basically, the behavior here is just the default.

Google is definitely your friend here. Plenty of tutorials online.

I think rust has a lot of slippery points too. And this number will grow with years. So, yes - rust made a lot of good choices over C++, but this does not mean it has no its own problems. Therefore I can't say Rust is simple in this sense.. But, of course, this is a good evolution step.