C++20 coroutines: “The bug is in the C++ standard, not GCC.” (2020)

Best part of latest improvements is that most common mortals don't have to deal with SFINAE, enable_if or tag dispatching.

There's some ways to keep multiple isolated Python environments around on the same OS (and Poetry can help with that, too). But I would suggest that you just stick every Python program in its own dedicated docker container, if you can get away with the overhead. (There are some ways to make rather slim containers.)

Of course, it doesn't have to be docker. Any other containerisation or VMs also work.

In general, I found it a good idea to keep the host operation system as small as possible, and stick everything into containers that you can upgrade separately.

I wouldn't call multiple return values a "tuple". I understand where you coming from, since Python multiple return values are implemented with tuples, but still that point sounds like saying that passing multiple parameters to C functions is "a tuple".

That being said, Go's "simplicity" in design is not only about interface simplicity - it's a lot about implementation simplicity. I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with. Since Go doesn't have a concept of immutable data types (except consts), tuples would effectively be just variable-typed constant-size slices, which are already implementable as arrays of empty interfaces, but have a runtime overhead...

I hope you see where I'm getting. Creating a language is complex and has a lot of tradeoffs. Then again, I see where you're coming from. I suppose it's a question of whether or not the tradeoffs (the "hypocritical design") is worth the good parts (simplicity of language, which leads to fast compile times, fast runtime, etc.). For me, personally, it is.

Thanks for the input.

This is one property of Go that I really like. Because of lack of constructors/destructors/magic functions and all that jazz, the only functions executed in a Go program are functions explicitly called through main().

And yes, lambdas and macros would probably have been a good replacement for that those two were originally meant to achieve.

I want to agree, but at least locally (as in geographically), these technologies seem to be heralded as fantastic. Maybe there's some kind of Spring Bubble around here, but on the main Maven site, Lombok shows up as the #16 most popular package (with primarily logging and language packages above it), and Spring isn't too far behind.

> Ruby and Python with their auto-magic method invocations

It's probably worth separating those two... as far as the functionality goes, Ruby and Python both have the capability of similar magic, but in my experience with popular frameworks, Ruby takes it to a whole other level while in Python it's generally discouraged.

I realize it's all anecdata here, but in my experience working with various companies and platforms, the Ruby magic generally just lives behind the scenes and Just Works. The Java magic would often turn into runtime exceptions, and the people who tried to do Ruby-like magic in Python would have similar difficulties. All of that revolved, primarily, around the ecosystems around the languages.

Have you ever heard of python?

...which, as shown by Rust, is actually not true, and is very much a go in the vast majority of cases.

> what do you propose to do instead?

It's easier and more natural to access the optional in an unsafe way (through the -> operator) than access it in the safe way (through `value()`); this is a wrong default which should have been made the other way around.

Potentially unsafe behavior should be opt-in, instead of opt-out. Yes, it's important that you have the option to disable this check for performance-sensitive code. But the majority of the code is not performance-sensitive to this degree that an extra branch is going to make any difference whatsoever.

In most scenarios there has to be a check somewhere. Where C++ got it wrong is allowing separation of the check from the use of the now-known-to-be-set value, so the necessity to have convenient zero-cost unchecked use is a problem C++ has created for itself.

Safe languages solved this by carrying the checked state over using the type system (e.g. pattern matching or flow typing), so further the uses after the check are free AND guaranteed safe.

There are some situations where the state of the optional being set is known from the context, but in a convoluted way too complex for the type system to follow. C++ focused on supporting this case — unwilling to compromise on either syntax or performance, and sacrificed safety for it.

Other languages in such muddy scenario either take the cost of a branch or have an unchecked-unsafe function for optimization, but importantly — that function doesn't get a syntax sugar. It is meant to stand out as a rare risky operation, and not be hidden behind super common innocent-looking syntax.

The reason they are UB is because the comments that it's similar to a null pointer are incorrect. std::optional doesn't store a pointer. It stores a value, and it's required that the value isn't constructed for a none optional. That way you don't have to have an empty no-args constructor nor ensure the constructor is side-effect free. And because the WG doesn't control your code, nor does the compiler, the resulting behavior can't be well defined other than by having operator-> have an extra if check & throw. Which if that's the behavior you want, that's what optional's value() gives you.

But at the end of the day, I guess my comment is also irrelevant, because we as developers should strive for correctness, not brevity, in code. If we can achieve both, the better. But alas, brevity and correctness are in an antagonistic tension in C++. So when we want correctness in C++, we should also be prepared to swallow a large portion of spaghetti Bolognese.

[1]: Or at least no more melodramatic than the phrase "aggressively wrong" lol

The fact that checked versions exist but are not used by default, have to be explicitly opted into, is consistent with C++'s designs and may be used to defend the current design, but at the same time also means it describing std::optional as memory-unsafe becomes a valid opinion based on facts, I think.