Fork me on GitHub
#off-topic
<
2015-12-20
>
borkdude19:12:19

Team size scaling seems to be the problem there. I think Clojure would not have done better there?

borkdude19:12:39

As it is relatively hard to find many Clojure developers

jaen19:12:09

I dunno, I'm all like

> 2015
> using Go
This really feels like a weird choice to me. I think Clojure would have done better than scala - it is a simpler language by design after all, it's harder to write utterly cryptic code than in scala, I think.

sveri22:12:25

I read the same article today and I found it very inspiring. I always wondered why someone like Rob Pike would create a language with such a feature set. It made no sense, someone with such an experience, creating a new language. But after reading that article, it was kind of obvious. He made that one for google, one of the businesses in the world with probably one of the largest developer counts. So he needed something that limits in every way, but makes building across multiple teams a breeze. So, this is how go lang came out. And it makes sense for large firms. Especially as the number of developer rises that does not have a scientific background, especially not in language theory. Why waste the time learning Applicative Functors if you could implement 100 features in that time. I think this is a step further into the assembly line work direction that business wants to move developers to.

jaen23:12:44

Maybe I'm just weird, but I can't understand how, say, allowing null pointers being anything but a wrong decision.

jaen23:12:48

But other than that I can see the appeal of deliberately simplifying the language to the designer and to businesses - I guess that's one of core things that led to the success of Java.

jaen23:12:46

And the niche go targets - a plumbing language for web infrastructure - doesn't make it's simplifications too painful, probably.