sping

I wasn't trying to give you advice, I was describing the situation in general. 🤷

It's very hardware dependent with a few problem's like Nvidia. For Best results go established brands that support Linux like thinkpads.

I'm now 1 year in to working in Go having been mostly C++ and then mostly large-scale Python dev (with full type annotation).

Frankly, I bristle now at people giving Python a hard time, having worked with Go and I now hate Go and the de-facto ethos that surrounds it. Python may be slow, but for a lot of use cases not in any way that matters and modern computers are very fast. Many problem areas are not performance-limited, and many performance problems are algorithmic, not from raw statement execution. I even rewrote an entire system in Python and made it use 20% of the CPU the former C++ solution used, while having much more functionality.

The error returns drive me nuts. I looked around for explanations of the reasoning as I wasn't seeing it, and only found bald assertions that exceptions get out of control and somehow error returns don't. Meanwhile standard Go code is very awkward to read because almost every little trivial function calls becomes 4 lines of code, often to do nothing but propagate the error (and errors are just ignored if you forget...). With heavy use of context managers, my error and cancellation handling in Python was always clean, clear, and simple, with code that almost read like whiteboard pseudo-code.

The select statement can be cool in Go, but then you realize that literally 98% of the times it's used, it's simply boilerplate code to (verbosely) handle cancellation semantics via the context object you have to pass everywhere. Again, literally code you just don't need in exception-based languages with good structures to manage it like Python context managers.

And every time you think "this is stupidly awkward and verbose, surely there's a cleaner way to do this" you find people online advocating writing the same boilerplate code and passing it off as a virtue. e.g. get a value from a map and fall back to a default if it's not there? Nope, not offering that, so everyone must write their own if foo, ok := m[k]; !ok {...} crap. Over and over and over again the answer is "just copy this chunk of code" rather than "standard libraries should provide these commonly needed utilities". Of course we can do anything we want ourselves, it's Turing Complete, but why would we want to perpetually reinvent these wheels?

It's an unpopular language, becoming less popular (at least by Google trends) and for good reason. I can see it working well for a narrow set of low level activities with extreme concurrency performance needs, but it's not the only language that could handle that, and for everything else, I think it's the wrong choice.

Go code is always an abomination.

Dynamic typing is shit. But type annotation plus CI checkers can give you the same benefits in most cases.

Once you need performance

If you need more performance. Many things just don't.

That's ironic. Few countries have less readable plates.

Excellent description of the zeitgeist.

Your portrait of before generative AI is a bit hard to square with the ad driven internet, but fits ever better the further back you go.

Yeah, we're turning it all to shit in so many ways simultaneously, it's truly something awful to behold. Maybe there is a singularity coming after all, but it's not one like the credulous tech worshippers imagined.

Git’s unconventional and decentralized design—nowadays ubiquitous and seemingly obvious—was revolutionary at the time,

Of course, there's more innovation in git than being DVC but the decentralized nature wasn't revolutionary.

It was funny when I started using bzr and then git, I kept being told "it's a DVC, which is a different way to work that takes some getting used to", and I was puzzled as it felt very familiar to me. Then I looked up DVCs and found out that Sun's Teamware that I'd used for a decade was also a DVC. It was actually a return to familiar and comfortable workflows after a brief period using abominations like Perforce and Clearcase. I'm so glad they've been largely replaced. Git may not be perfect, but it's better than those in any use cases I have had.

When bzr, and then git, turned up and I started using them, I was told "this is DVC, which is a whole new model that takes getting used to", so I was surprised it seemed normal and straightforward to me.

Then I found out that Sun's Teamware, that I had been using for many years, was a DVC, hence it wasn't some new model. I'd had a few intervening years on other abominable systems and it was a relief to get back to DVC.

Regarding the original post, are there really people around now who think that before git there was no version control? I've never worked without using version control, and I started in the 80s.