i'm not fond of languages that use :: at all, at all. structural typing, not object/inheritance. composition not inheritance.

and it has needlessly verbose and specific repetition in the iterators, where `for _,_ := range X` but also `for init(); check(); iterate()' C style if you need to use that for whatever reason, and can even do a forever loop with nothing but for {} which is a construct that doesn't make much sense without callbacks or channel selectors

nah, i'll stick with Go :) V and zig are another two languages that go in this general direction, V is very fast compiling but personally i can't stand the whole mutable/immutable variable declaration, i think all variables should be mutable because the MMU annotations against the memory map cost more processing and context switching time when there is a ROM flag on a block of memory. Rust dwells on this shit irritatingly and probably the most common line beginning in Rust is "mut", when you consider variable declarations. should be the other way around - implicitly mutable, and explicitly immutable. you don't have to write much Rust code no figure that out.

that's at least a few hundred milliseconds of time spent ignoring noise in the text. this general principle towards clean, unambiguous semantics by avoiding stutter and boilerplate fluff. you can't really take anything away from Go's syntax and still have somehting usable. you could completely *gut* C++ and Rust and Java and still be able to implement the same software. it would just be a lot faster, cost less in complexity, be cheaper to vibe code, and easier to read.

after 8 years working with Go i would not pick a single other language that i would prefer to write code in. sure there is a few quirks especially involving maps and slices but you get used to remembering that not all values are values. it also makes some constructions of structural typing difficult, it's best to do structural types always wrapped in struct. struct is just the same as a tuple except with typing, the data is squashed together and there is no overhead, just a map of symbol-name correspondences as offsets from byte zero.

people who love these "expressive" constructs like map/reduce and try/catch think their code is clever but it's just unecessary. in Go there doesn't have to be exceptions, any exception is fatal, and instead errors are considered to be intrinsic to almost all cases of a return value tuple - leaving open more flexible ways to deal with unexpected states such as "the best i can do is" style "this is the answer i got but i encountered errors getting this value and it may therefore be useless to you".

languages that don't have interfaces promote bad habits of interface design in general, and languages that don't have CSP style concurrency with first class select/channel and coroutines are a pain to write dynamic, server type code with. when you are used to thinking about implied satisfaction of an interface instead of explicit, wordy declarations that state that something implements an interface, means a lot less crap - but it's probably the one place in Go's design where maybe explicit would have been better, but for some time now most static analysis tools can trace interfaces to their concrete implementation easily enough.

anyhow. i'm sure that OpenAI and Google are loving it that most of their LLM customers are vibe coders working with the absolute worst shit... typescript/react and rust/C++. it's been patently obvious to me watching the LLM work that it's doing maybe as much as 2x as much thinking for react as svelte.

AI credits are a much too big part of my costs to not pay attention to how to mitigate this cost when i can.