Go is bad

Why does Go so religiously strive to stay behing the times? And no, generics are not ``bloat''. Neither is operator overloading.

I dunno

Is it because it was developed as an internal language for one company for a specific goal and then was released to the public as an afterthought?

Go is a language that can't decide if it wants to be minimalist or practical. it doesn't even do a good job of finding a middle-ground (e.g. small base language + macro support + big stdlib, like with Racket).

it's a passing fad. a year ago people were saying that there's no reason to use FIOC and Lua when you have Go, because Go is as easy to read and write while being faster. but that's simply not true - writing anything bigger in Go is a pain in the ass because of how limited its metaprogramming is: no generics, no macros, no metatables, shit reflection, dynamic modification of types is a void*-tier hack based on unsafe. they recently added AST modification functions which is promising though.

If Go came out in 1995, it would make Java look good. Think about that.

go: bad
systemd: worse

its not bad

its not bad

you cretin dont copy my post

Go isn't bad. Certainly there's room for improvement, but that's the case with any programming language.

>>6
systemd is not a programming language, you're comparing apples to oranges there.

>>11
digits confirm

The biggest problems come from the authors' fetishes for UNIX and standards. They clearly put a lot of thought into appealing to the "everything is a file"/"a bunch of independent tools that do one thing right"/cat-v types. It's a really dated attitude tbh.

As for generics, the Go authors say you don't need generics, and it's true. If you get creative, you can do what you want with interfaces. Generics would still be useful though, and you can see even in the standard library how many times functions are unnecessarily duplicated because there are no templates/generics. See the "flag" package for an atrocious example of this.

>>11
true
systemd is still bad tho

>>13

The biggest problems come from the authors' fetishes for UNIX and standards. They clearly put a lot of thought into appealing to the "everything is a file"/"a bunch of independent tools that do one thing right"/cat-v types.

That's a good thing. What you consider a ``problem,'' I consider a breath of fresh air.

It's a really dated attitude tbh.

Striving for simplicity is a good thing. Fallacious arguments as

CURRENT YEAR

don't change that.