LinXitoW

The EU has the advantage that their politicians don't all own gigantic shares in any social media companies (because the EU doesn't have any), so they are afforded the rare luxury of actually voting for the good of the people. That's why the EU has decent data privacy laws.

The TikTok ban would've been far less problematic if they had created legislation for all companies that curtailed data trading and increased user privacy. But that was never the goal.

I've heard this reasoning multiple times, but that doesn't make it right. Like you said, you ARE presuming something: That scripting and a (useless) base case are the most common usage.

How many people script Git? More importantly, how often do you change that script? Rarely, and rarely. That means it's FAR FAR less work for the scripter to look up the weird incantations to remove the "human" parts (like a quiet flag).

Conversely, the human is far more likely to write git commands impromptu, and I dare say, this is the FAR FAR more common use case.

That means Git (and a lot of these kinds of commands) optimize for the RARE choice that happens infrequently over the common case that happens often. That's horrible design.

TL;DR: Just because there's a consistent design philosophy behind obtuse linux commands does not make a good, helpful, useful, modern, or simple philosophy. If a library author wrote code this way, we'd all realize how horrible that design is.

Yes, but at least in the USA, I constantly have to hear shouting about how "free" everything is whenever I ask for sane regulations (guns), or something like universal healthcare.

If USA was actually so free, that would at least be consistent. But now I don't get TikTok, AND kids have to run around with bullet proof vests? I get all the bad, none of the good.

Every voting citizen should remember that this TikTok ban was bipartisan. That means they all cared more about this than ANY other sensible legislation. Banning child marriage? Nah! Protecting the childrens physical bodies in school was not as important as a hypothetical "mind attack" from TikTok.

They've literally said "Better a dead kid than a red kid"

My cynical take is that a lot of the people for whom the tiktok algorithm "didn't work" simply weren't pleased by what the algorithm (correctly) thought of them. It's like the 40 year old truck driver that complains it's just hot girls dancing. No, my dude, you just ALWAYS stay to watch the girls dance, you just don't want to admit it.

In general, it "just works" after a short period of maybe searching for specific terms just to "seed" the algorithm.

The difference is, of course, that only one of those countries CONSTANTLY bangs on about being the "free" world, about "free" markets, about how not saying the n-word is censorship etc.

In short, it's only hypocritical for one of those countries.

In both cases though, for normal citizens your own country and it's companies are far more dangerous than some random country halfway across the globe.

My biggest pet peeve with Kotlin is that they got rid of checked exceptions and replaced them with nothing at all. All error code flow is now just invisible unchecked exceptions, the single worst kind of error handling imaginable.

I know they added the Result type later on, but there's zero convenience to it, so you have to manually handle every error, even if you just want to bubble it.

Checked Exceptions were better, though Rust still has the best error handling in any non-functional language.

Checked Exceptions are nothing but errors as values with some syntactic sugar for the most common use case (bubbling up the error).

Gos version of value errors is just micrometers ahead of C style error codes. In both cases you get told "there could be an error", the error is a value of one single type (error/int), and you have to manually find out which different errors this value could represent.

If you want to know what you're missing, check out Rusts error handling.

Go has insanely good tooling and very fast single binary compiling.

While all these languages (afaik) can reach similar levels of functionality (GraalVM e.g.), it's more work. As much as I hate the language Go, I can't deny how braindead simple it is to just make a tool with it. I don't need to choose a build tool, or a runtime version, there's a library for everything and most developers with more than a room temp IQ can immediately start working on it.

The only other language that currently comes close is Rust. If only they had stuck to using a GC, I'd be in heaven.

My slightly snarky take is that liking Go is simply a defensive reaction to one too many AbstractFactoryBeanFactory. Too many abstractions overloaded their "abstraction-insulin", so now they can only handle minute amounts of abstraction.

Maybe I'm too pessimistic, but Rust style error handling feels like the global optimum under the constraint that the average developer understand it.

Go is a language that exists purely because people saw Monads in the horizon and, in their panic, went back to monke, programming wise. Rust error handling is something that even many Go fans have said is a good abstraction.

But so would every single other method to react to different types of errors, no?

In something like go, you're even required to create the separate code path for EVERY SINGLE erroring line, even if your intention is simply to bubble it up.

The biggest issue with checked exceptions in modern Java is that even the Java makers themselves have abandoned them. They don't work well with any of the fancy features, like Streams.

Checked Exceptions are nothing but errors as return values plus some syntactic sugar to support the most common response to errors, bubbling.

Which Go doesn't fix either, because their errors are all just "error", aka you can also forget to catch the right type of error.

If only there was a way to combine optimizing the default path (bubbling), and still provide information on what errors exactly could happen. Something like a "?" operator and a Result monad...

I mean, I agree that Khan is the best possible option, but I disagree that pro-market isn't ideological.

Where the free market fans see child slavery and sexual slavery and rejoice (free to make any contract you want to after all), the pro market people believe that if you just put enough guard rails on it, greed will magically turn into a force for good.

Obviously I also have an ideology, but at least I'm honest enough to not pretend that capitalism (or communism/anarchy) are naturally occuring, instead of simply a choice we make.

I unironically like the YAML format. It's very readable, imho, and most people (at least in the web space) already know it. It's better than the way just does attributes and descriptions.

On the other hand, what irks me is how parameters are fiddly to pass along. You have to define environment variables, instead of jusst passing them directly in the call.

It's a fully fledged, horrible language. Anything beyond basic queries is unreadable, ESPECIALLY when it's done in plain strings in another language. There's not even a way to not have to repeat values EVERY SINGLE TIME (think variables or constants in every other language).

Oh, but what about <feature>? Well, is that SQL, or a frankensteined version of SQL, aka a "dialect"?

SQL is the JavaScript of databases, and we'll be better for it once we admit this.

It literally had generics from the very first day. They were just gate kept from the "smelly, lowest common denominator code monkey morons", because noone could match the genius of their creators, or ever have the same issues to solve as the creators (because their little brains are too tiny).

It's lists, and maps.

I guess this is a semantics argument, but I assume they mean to express the same thing with same (or reasonably same) security guarantees. After all, the security and "bug freeness" is part of what they are expressing. If you attempt to create something reasonably similar to Rust, you do suddenly need a lot of complex checking code and maybe tests for things that were trivial in Rust (because the compiler does the tests for you).

I think the sticking point is what people mean when they say simple. To me, and likely to many saying Go isn't simple, simple is not a synonym for easy.

Go is easy, but it is not simple. For example, solving the problem of generics in a generic way from the start so the same problem can be addressed in the same way everywhere, would be simple, but maybe not (as) easy. Contrast that to giving the runtime/standard library a special exception with maps and lists. That's easy, but not simple. People used to literally use code generators or weird UTF-8 characters to fake generics, that's not remotely simple.

Go is not simple, it's easy.

The difference, for example is: Go invents an abstraction just for one use case, and just for the standard library/runtime itself, instead of taking the time to create a universal version of that abstraction. Generics for maps and lists, and tuples for error handling.

Imho, most features of Rust that people would like to see in Go would still fit into the "concept" of Go. Just like they added generics, they could add just three things: A generic container for errors (Result), one for saner Nil handling (Optional) and a small sprinkling of syntax sugar to make these comfortable to work with (something like an elvis operator equivalent).

Go has the one big advantage that is almost solely responsible for it's success: It was created and directly used by a giant company that could afford to create amazing tooling around it and develop great opensource libraries for it. Already being in use and having libraries feel like the biggest determinants of a languages success.

One very subjective, very irrational factor for my borderline hate for Go is that for years the Go zealots gaslighted everyone about every single part of Go.

Anything that Go did, no matter if it was the most basic implementation or if other languages already did it (better), was essential, the best and only way to solve that issue.

Anything Go did not do was superfluous and downright a conspiracy by Big Complexity to keep us unenlightened Non-Goers addicted to the Syntax Sugar: Things like sane null handling, sane error handling, less boilerplate, generics, or not creating special cases for everything (generics and tuples) instead of developing one cohesive solution.

Even now, in this thread, the strawmanning continues: Error handling is brought up, and instead of admitting the unmistakable truth that Gos error handling could be much better (s. Rust), people bring up things like JavaScript. As if anyone criticizing Go that JavaScript was the pinnacle of error handling.

I'd argue that at least checked exceptions also require a conscious decision from you. You either need to add the Exception type to your throws clause, or your catch clause.

Compared to Go, this is actually better because the type system can tell you what kind of errors to expect, instead of just "error".

I don't think a language where for every 1 line of functionality, you need 3 lines of error handling boilerplate gets to be called readable.

Heck, Go went out of it's way to "subvert expectations" more than the last season of Game of Thrones.

99% of decent C-ish languages either do "String thing" or "thing: String", but Go is so fancy and quirky, it does "thing String" for no freaking reason. Don't get me started on the nightmare that is map types.

Any ORM worth it's salt has an escape hatch that allows you to do all those fancy raw SQL queries.

But the amount of queries that aren't fancy, and that an ORM is perfectly capable of abstracting away is (imho) 90% of all queries run.

Why make 90% or queries more tedious and error prone, just to make 10% slightly easier?

It might be nit picking, but that's more the ecosystem or tooling that's great. The language is mediocre, but it's what everyone gushes about.

I still remember people gaslighting everyone that any feature Go had was ESSENTIAL, and every feature Go didn't have was USELESS or too complicated for mere mortals "delivering value".

And the fast compiles at least are in big parts because the language is so horrendously basic. Can't get hung up on checking type constraints if you barely have any.

An interface, esp. when returned from a method, is the best way the define a limited contract. If you return the concrete class, you have the following potential issues:

- Very broad, unspecific contract that may even obscure the methods purpose

- You cannot modify the contract without modifying the class AND vice versa

- Shrinking a contract (taking away elements) is far harder and more likely to cause breakages in other code than growing a contract

- Mocks become more cumbersome because the contract is so broad

- Changes to the concrete class cause ripple effects in code that doesn't care about the change

Thank god I'm not the only one. I can still remember when the Go zealots were everywhere (it's cooled down now). Every feature Go didn't have was "too complicated and useless", while the few features it did have were "essential and perfect".

I've really tried giving Go a go, but it's truly the only language I find physically revolting. For a language that's supposed to be easy to learn, it made sooooo many weird decisions, seemingly just to be quirky. Every single other C-ish language declares types either as "String thing" or "thing: String". For no sane reason at all, Go went with "thing String". etc. etc.

I GENUINELY believe that 80% of Gos success has nothing to do with the language itself, and everything to do with it being bankrolled and used by a huge company like Google.

> There are always contract. You simply chose to be ignorant of that fact and fail to interpret breaking those contracts as the root cause of all your problems.

This reminds me a lot of the dynamic vs. static typing discussion. Even at a function level, there's always a contract, no other option. The only decision you can make is whether it should be well documented, compiler verifiable and explicit, or not.

I have about 1500 hours in OW and OW2. I can't recall ever playing with/against a cheater.