Okay, it is some reasonable if the operator is viewed as a behavior operator. But it is not, it is a type set operator.

I broadly agree with you, so this isn't to disprove you or anything, but in case you hadn't seen it before: you can do type checks inside generic functions. You just have to trick the compiler / do pointless boxing because the compiler is overly simple.

This fails: https://go.dev/play/p/3J4urjOU6lc

    v, ok := thing.(target)

    v, ok := ((any)(thing)).(target)

Yeah. I'm not claiming they didn't back themselves into a corner here.

There's no theoretical reason not to have it, the reason is because of a random intersection of other design decisions... unless you're saying they made those choices fully expecting to have these restrictions on generics later?

Functions in Go can be generic, just not methods.

And unless you're also using interfaces, methods are no different from functions aside from call syntax.

I frequently hear that Go is simple, and I generally take that to mean that it doesn't have a whole lot of features. But doesn't this then force the complexity on the programmer? There is a set amount of complexity in the world, and either your language models it or you model it, but something has to model it for your program to be a faithful representation of the problem in question. It seems that Go has shunted much of that complexity onto the programmer. This article does a good job of summarizing (and indeed helped to shape) my thoughts on the matter: https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...

I'm in a similar boat to sbrother (GP) and some of the other sibling commenters: like GP, I don't love the language (honestly, "patronizing" is the word that feels most accurate to describe working in Go for me, if a programming language can even be patronizing); like others, I have been impressed with how well it works when programming in its niche (high-performance network proxies).

I'd add what I think is perhaps its most significant benefit to the list: Go fully solved the function coloring I/O problem in a way few other languages (Erlang/Elixir and ... Bend? Others?) have.

That's adjacent to the concurrency benefits in the parent comment, but a little different: allowing procedural, non-colored code to be efficiently concurrent over I/O without introducing function coloring or requiring people to code specifically to an event loop/IO multiplexer in some other way requires good concurrency support in the language, to be sure. However, getting rid of function coloring while providing efficient concurrent IO also requires: a solid stdlib of IO capabilities; a very very good runtime that can coalesce goroutine-concurrent IO into multiplexing OS primitives in the same way a function-colored event loop would (while pre-empting/scheduling in a reasonable way that mitigates unexpected blocking); a strong "critical mass" of libraries to talk to common IO-ful systems; a strong community convention of "we will generally prefer reimplementing IO drivers in Go rather than binding/Cgo-ing in foreign code".

It's when you combine all of those that Go shines as a platform for concurrent (usually network) IO.

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.

Yeah that's fair. In terms of "things with good perf" I'd rather be writing C++ or Rust, but there are significant issues with using either of those on a large team.

I'm more comparing it against languages like Kotlin and Swift, or even Scala.

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.

What you're doing right now is called "coping".

I mostly agree, hence the

> end up copy pasting code instead

bit of my original comment

What I mean is reducing boilerplate is not something one should strive to achieve. It is not bad in the sense that one should introduce more boilerplate for the sake of it. But reducing boilerplate for the sake of it is not good thing either.

If you need to make code more complex just to reduce boilerplate, it's a bad thing. If you managed go make code simpler and reduced boilerplate at the same time, it's a good thing.

And boilerplate might be a good thing when you need to type something twice and if you would make error once, the whole thing wouldn't work, so basically you'll reduce the possibility of typo. It might look counter intuitive. Just unrelated example: recently I wrote C code where I need to type the same signature in the header file and in the source file. I made mistake in the source file, but I didn't make the same mistake in the header file and the whole program didn't link. I figured out the mistake and corrected it. Without this boilerplate it's possible that I wouldn't notice the mistake and "helpful" autocomplete would keep the mistake forever. That's how HTTP Referer header made it into standards, I guess.

Not the person you’re replying to. The orm sucks because as soon as you go out of the beaten path of your average select/insert/update/delete, you are inevitably going to end up writing raw sql strings. Two cases in point: postgres cte and jsonb queries, there are no facilities in gorm for those, you will be just shoving raw sql into gorm. You might as well stop pretending. There’s a difference between having something writing the sql and mapping results into structs. The latter one can be done with the stdlib sql package and doesn’t require an „orm”.

There are two things an sql lib must do to be very useful: prepared statements and mapping results. That’s enough.

ORM is for object-relation mapping. Go is not object-oriented language and OOP-patterns are not idiomatic Go, so using ORM for Go cannot be idiomatic. That's generic answer. As for more concrete points:

1. Mapping SQL response to maps/structs or mapping maps/structs to SQL parameters might be useful, but that's rather trivial functionality and probably doesn't qualify as ORM. Things get harder when we're talking about complex joins and structs with relationships, but still manageable.

2. Introducing intermediate language which is converted to SQL is bad. Inevitably it will have less features. It will stay in the way for query optimisations. It'll make things much less obvious, as you would need to understand not only SQL, but also the process of translating intermediate language to SQL.

3. Automatic caching is bad. Database has its own caching and if that's not enough, application can implement custom caching where it makes sense.

In my opinion the only worthy database integration could be implemented with full language support. So far I only saw it with C# LINQ or with database-first languages (PL/SQL, etc). C# and Go are like on opposite spectrum of language design, so those who use Go probably should keep its approach by writing simple, verbose and obvious code.