I want off Mr. Golang’s Wild Ride (2020)

My impression is that Go as a language tries to make things simple, but things aren't always simple. Time and date operations are hard and simplification leads to I correctness.

If you just want to show a nicely formatted number, you don't want to care about wall time, you want to show a number that's good enough. Go gives you something that's probably good enough. It's not correct, but who cares? For the purposes of the people who made Go you don't need correctness.

Same with the permissions. Permissions are hard, especially on flexible systems like Windows. Unix pretends these problems don't exist and Go as a languages tries to pretend Windows is just a weird flavour of Unix. For most use cases, this is fine; read only is normally the only flag you care about as a developer and read only is something the API will give you. If you want something correct, go get a library or something.

Then the path issue. Paths are hard. Path separator APIs are hard, especially if your standard library doesn't like using the operating system's standard methods for dealing with paths. Most paths are UTF8-compatible strings. Sure, Windows is UTF-16 and plenty of real-world file systems don't even have UTF support at all, but most file systems used by most users are compatible enough. If your file system shows you weird bytes, that's either a mistake or you're using some kind of complex, incompatible encoding (some Asian languages have these still in use). Go is simple, you're either the common use case or you're wrong.

This all makes Go quite simple to work with for many use cases. It simplifies your computer and makes some of the decisions for you. That's not even a bad thing if you're using it as a replacement for hacky shell scripts and messy Python tools, because people usually ignore the real life complexities of computers in there too.

For a system that's supposed to be correct, I wouldn't even think about using Go, because it chooses simplicity over correctness. For something that I kind of, sort of, probably want to just work most of the time, the language works fine. Sure, the code looks like drunk Python combined wirh endless checks to see if err is nil, but it works. It's very easy to get productive with Go if you can get over the language itself. Just go in with the right assumptions.

Similarly, don't go into C or Rust if you want a simple programming language. Rust is trying to be correct, or even pedantic, more than it's trying to be simple. Writing correct code is verbose and annoying and dense languages like Rust will easily allow you to write an unreadable mess. C, on the other hand, will let you do your own thing: whenever there's any kind of complexity, the language shrugs and says "you probably should check this but if you don't, well, let's just call it undefined behaviour and move on". It could be correct, or it could not be and you'll probably never know for sure.

There are tons of simple programming languages, even ones that do the correctness deal better than Go. Take a look at C# and Java (or if you want to feel like you're writing modern code, maybe Kotlin), with platforms made to work on Windows and Linux with their crazy quirks. Go isn't a universal solution because no universal solution exists.

In theory, this is a big deal.

In practice, it doesn't seem to be a problem. I've neither hit this very often myself, nor have I seen even newbies have much problem with it.

A lot of error handling procedures are based on reacting to C, which was awful. You could call a function, and then have to call another function, deliberately, to see if it failed. This is a nightmare, absolutely. A "Result" type does indeed solve the problem, but the fact that it solves the problem doesn't mean it is the only solution to the problem. The Go solution seems to be about 99.99% effective. It isn't a 100% solution, no, but by 99.9% or 99.99% or so, it takes it below the level of problem that I care about.

The issue with "bubbling" is a bigger problem in practice, certainly.

As for C++, the standard library has create_directory (https://en.cppreference.com/w/cpp/filesystem/create_director...) in the std::filesystem namespace, taking a std::filesystem::path.

C++17 may not be as widespread as its older companions, but if you're using the language in a modern context there's a perfectly usable set of standard APIs for this stuff that works with a whole bunch of char types (or the std::u8string if you're on modern C++ and want to forego the whole UTF issue as much as possible).

The problem is that you have to deal with edge cases. File system corruption happens and iterating over JSON files in a directory can show random character sequences at any point in time. You can choose to ignore it, or fail on error, or let the language decide what to do in the case of Go, but you always need to be mindful of the failures that can happen. Ignoring the problem won't make it go away and eventually it'll bite you in the ass of you keep doing it.

This is a false dichotomy - there's a third option, which is not squinting (because, presumably, you're doing so because you decreased your font size), and being able to see more on the screen at the same time.

Moreover, scrolling is bad for cognition. It's pretty well-known that the human brain likes to use spatial maps - that's the reason why memory palaces are so effective. Scrolling decreases the ability of the brain to make spatial maps compared to, well, not scrolling.

> The point is that context matters, and the more frequently you have to scroll to find it is more cognitive burden.

This is not something you can "disagree" on - divorcing information from context always leads to more cognitive burden.