Just curious, why do you say that (about Go)?
back
1 comments
It feels much too pragmatic for my taste. Exactly the kind of thing to come out of Google, to solve their type of problem (scalability, deployment are much more important than the code itself). Personally I don't have googles problems (few of us do!) and I really like a good type system, with algebraic types/pattern matching/generics
It feels much too pragmatic for my taste.
C was unprincipled and pragmatic too, it was created with the goal of making UNIX portable. Still, C became one of the most popular and influential languages.
While I prefer ADTs/generics too, let's not forget that many people are less principled and pragmatic factors influence language choice as much (toolchain, ecosystem, popularity, familiarity).
> Still, C became one of the most popular and influential languages.
That was a side effect of successful startups (Sun, SGI...) adopting UNIX as their OS.
The success of UNIX is inseparable from C and vice versa. C made UNIX one of the first portable operating systems and, by virtue of being low-level, provided performance.
The same could be said of OSes using Algol and Mesa. They just hadn't successful startups using them.
There are good reasons that these startups weren't using OSes using Algol and Mesa. You seem to imply that the success of C and Unix is some historical accident as a result of two startups picking Unix randomly, and their choice was bit a function of the technical properties of UNIX and C. Which, is of course, nonsense.
Sun used Unix because Sun was co-founded by Bill Joy. By that time, Joy was already deeply involved in Unix (per BSD). If he didn't find Unix and C likeable and up to the task, they would have made different choices.
SGI and Sun were just one of many catalyzers, like a lot of programming languages have catalyzers.
You just confirmed what I said.
The startups that have chosen UNIX, did so because the owners were part of the American UNIX university culture.
A different background would have mean a very different history in mainstream OSes and their respective system programming languages.
In Europe C had very little meaning until most enterprises started to replace their mainframes by UNIX servers from those companies.
Having had exposure to both C and Pascal at around the sane time, I vastly preferred working in C.
I do think there's something intrinsically good about it compared to other contemporary systems languages - I don't think it's just that it tagged along with Unix.
I use Go a lot for backend stuff, and I agree with you. There is a lot of stuff you can do with interfaces to ameliorate the lack of generics--but you still end up missing generics and algebraic types.
> It feels much too pragmatic for my taste
It doesn't feels pragmatic at all. It relies on users to do the compiler's job(type assertions) , because "You dont need that with Go"TM ...
It feels "pragmatic" in that Go follows "YAGNI" almost to a fault. It makes the argument that repeating yourself can sometimes be a better choice than more abstraction to increase code clarity. Some disagree with that, which is why it's nice to see other languages taking on similar areas that Go tackles but with differing choices in that area.
If you write Go code, you will realize you will actually not hit that problem often at all.
Right now the annoyance I hit more often is the inability to map a []Foo on an attribute .Name (string) to get a []string. I do that in ruby all the time, and with Golang it really sucks to do a for loop to collect stuff appending to a new array.
people.map(&:name) => ["Joe", "John"]
a := make([]string, 0)
for _, p := range people {
a = append(a, p.Name)
}It is not pragmatic at all, it is a language for mine workers that are too stressed to think.
Hah, I precisely use Go when I have to think deeply, i.e. about a difficult to solve problem.
When the problem is boring, use a fun & challenging language. When the problem is fun and challenging, use a boring language.