Agree. Modern C++, and discussions around it, become more esoteric with every revision. As software engineers we should spend our time understanding the esoterica of the problem domain, not the toolset.
I'm of the same opinion. Frankly, when Go first appeared, I felt we would finally get something almost as simple as Python and almost as fast as C. Unfortunately not everything was as nice as I had expected. Still, in that respect it's better than Rust as it makes it easier to focus on the problem rather than the language.
The complexity of C++0x is one reason Go was created.
"For me, the reason I was enthusiastic about Go was just about the same time we were starting on Go, I read (or tried to read) the C++0x proposed standard. And that was the convincer for me." - Ken Thompson
For reference of anybody too young to remember: C++0x is what you'd have called what became C++ 11 back when the committee thought it might happen in 2009 or, worst case 2010.
The fact that their "2009" standard shipped only in 2011, after ripping out features everybody agreed were good yet never seemed finished, is why they moved to their current "train" model where there's a new C++ every three years, like it or not. The train will leave, if your feature wasn't ready well there's another train in three years.
> Still, in that respect it's better than Rust as it makes it easier to focus on the problem rather than the language.
Quite the opposite. In Go/Java I find myself frequently thinking how to adapt my problem so it can be expressed in a very limited set of language features. I want to build a house but I only get a hammer and some nails. Works nice if I want a wooden house but not so much if I want to use bricks and concrete. In Rust I get a giant toolbox with almost everything and I just pick the right tool for the job. So although I had to learn more tools initially, later I can focus more on the job, not the language, because the language adapts to the problem. And the final result is typically also better in terms of quality, performance, etc.
Having used both professionally (several years each), Go is massively simpler than Java, at least for the problems we tackle. We sometimes will get a new dev on the team from Javaland, and the biggest thing for them is unlearning all of unnecessary complexity. YMMV.
I should have clarified I was one of early adopters and my main gripe then was mainly about its performance, not the syntax. I mean it was okay, but still not up to my expectations. But that was over a decade ago! Next time when I have the luxury of choosing the language for a new project I'll definitely take Go into consideration. It has its quirks but overall it's quite simple and manageable - you can easily understand code written by someone else which is a huge advantage.
> Frankly, when Go first appeared, I felt we would finally get something almost as simple as Python and almost as fast as C. Unfortunately not everything was as nice as I had expected.
Would you care to elaborate what exactly is not as nice as you had expected? I'm really into Go and to me it really does seem as good as expected. Just curious about what made it suck for your usecase.
Go's design always struck me as really hypocritical. At least it's initial design.
Go's designers get to use tuple for their favourite use case: returning from a function.
You as a user of the language don't get to use tuples for anything else.
(And using tuples to indicate failure is really, really silly. You'd want algebraic datatypes for that. Ie a beefed up enum, not an ad-hoc struct.)
Go's designers get to use generic functions and datastructures for their favourite use cases. Eg the infamous `make` is sort-of generic, and Go's arrays, maps and channels etc are generic.
> Go's designers get to use tuple for their favourite use case: returning from a function.
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.
> [...] like saying that passing multiple parameters to C functions is "a tuple".
You intended this as a reductio ad absurdum, but you are entirely right. That's how it's handled in eg Haskell.
> 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'm not sure that would be a good way to implement tuples. In fact, I suspect it's probably close to the worst way to implement them?
I'd image you'd want to take the machinery you have for structs, and adjust it so that it can deal with anonymous structs with anonymous fields identified by position. (But still preserve all the static typing, instead of throwing your hands up and going with 'variable-typed'.) The runtime overhead would be more or less exactly the same as for structs.
In general, I see tuples as a syntactic sugar over structs and expect them to be compiled like that (or better) in a statically typed language; instead of representing them as some kind of weird slice.
Theoretically, you could probably even implement tuples-via-structs as a preprocessor.
> I imagine that adding tuples would cause a whole lot of complexity that they'd have to deal with.
Yes, so instead of abstaining from tuples, because of these complications, they added a special case for their favourite use case.
Have a look at OCaml for a relatively simple language with less design hypocrisy, and fast compile times and fast runtimes. (Compared eg to the much more complex Haskell.)
Now that I've had more time to think about it, I think the problem of Python-like tuples in Go is that they require Pythonesque everything-is-a-reference paradigm in order to function the same way, otherwise they just act as heterogenous arrays in Go (which exist as arrays of empty interfaces, with a slight runtime cost). Go is mainly value-oriented language like C, with the exception of built-in container types and strings (and maybe a few others that slipped my mind).
I suppose that adding fixed-type pass-by-value tuples would essencially be reimplementing struct. Go doesn't like duplicating functionality.
I think this is more of a meme than reality. In the past, C++ needed manual memory management and writing ctors over and over with myriad footguns. Now someone can contribute to a C++ codebase barely knowing what a heap or reference is and the compiler will create decent code.