Just because we can, doesn't mean we have to. I'd prefer to have some more brain-cache free to concentrate on the problem I'm trying to debug rather than doing type resolution in my head.

Please. I’m sorry, but you kind of can’t avoid needing to think about types unless you use a language like JavaScript which is super loose with its type conversions, and you especially can’t avoid in a language like Go. With generics in Go you don’t even need to prefill the types like you go with a lot of other cases, so I’m dubious about the cognitive overhead.

No need to insult JavaScript. In two out of three times the "JavaScript" written will be something like:

    interface Box<T> { value: T }

    function map<T, U>(input: Box<T>, func: (value: T) => U): Box<U> {
        return { value: func(input.value) }
    }

People should stop using these simplified high level programming languages with low cognitive weight, like Go. I only write assembly. ;)

(b Box[T]) Map[U any](f func(T) U) Box[U] _is_ for the Arts and Humanities.

Unless you're writing assembler in vim you're not STEM.

Why should I, as fallible human of limited short and long term memory, bear that cognitive weight when I have a perfectly good compiler on a computer to offload that particular cognitive weight to?

In terms of tooling, Go is one of the few languages which remembers that we are in STEM.

I’m not sure if you are complementing or denigrating golang’s tooling. Most “STEM software” packages are horrendous in terms of user/developer experience, to the point of hampering their utility. For instance, MPI really reminds HPC users that we are in “STEM”, but not for a good reason.

Golang has good “implementation level” tooling, but that is still nothing when compared to tooling available to Java and C#. Even if GoLand is closing the gap on the IDE front (idk, I haven’t tried it), golang simply doesn’t offer the features found in OpenJDK or Dotnet (GC parameters/implementations, profiling/introspection data, interoperability/ffi, etc.). It just feels like golang’s tooling looks good when it’s competing against python, ruby, or JS/TS.

Native compilation which is fast enough, green threads, AST and analysis framework, in-built testing and profiling, call graphs, rewrite tooling (go fix), go.work and modules which are far better than maven / gradle mess. There's a good amount of rigour applied to Go tooling that it "just works", even as horrendous the language is.

I agree java is good too, except spring boot manages to undo all the engineering that has gone to Java.

I wish it was arts & humanities.. those are some actually clever folks.

Programming language evolution has always been the pursuit of abstractions that enable expressiveness and simplicity.

Your comment boils down to "I'm smart", which in the end, isn't terribly smart.

Having simplicity and expressiveness as a goal, and a general direction of achieving things through lazy means is at the heart of mathematics and engineering.

Celebrate laziness and a want for simplicity. True simplicity is hard, but worth going after even where it threatens the notion that you're the smartest person in the room.

>Your comment boils down to "I'm smart", which in the end, isn't terribly smart.

They are saying that a programmer should be able to cope with the cognitive dissonance of not immediately understanding something.

>Celebrate laziness and a want for simplicity.

Concepts like generics might be intellectually more challenging, but they are clearly the “lazy” approach for actually writing code. Writing and maintaining multiple versions of the same function, or using code generation, is intellectual lazy but manually intensive.

I don't think that comment was necessary. What do you gain by denigrating the Arts?