[continuational]

Go is just barely statically typed though, with its lack of generics. Some day soon, it will tacked onto the language; a language that wasn't designed with that in mind.

I don't know about pace, but in absolute terms, Go is far behind even the oldest versions of Scala.

[yahyaheee]

That would be missing the point of Go. It’s not as though the Go team is incapable of introducing genetics they just took a hard line on not putting anything into the language that wasn’t absolutely needed. This built a simpler language and because of that a stronger community, which is why Go has all but entirely eaten scalas lunch

[MiroF]

This is all marketing.

I've never found a more sophisticated type system anything but helpful. It's easy for beginners to start, but when you don't have a good type system and you have a complicated project things quickly become a nightmare.

[yahyaheee]

eh, there is still a cost to it, don't get me wrong I generally think generics are worth the cost if done right, but they can also go really wrong

[saagarjha]

When?

[yahyaheee]

Scalas insane generic type system would be an example of them going wrong. The current proposed Go method seems fairly reasonable.

[dxxvi]

I'll give an example of the Scala type system: let's define combining 2 integers as adding them together, then combining 2 lists of integers will give a new list where an element is the result of combining of 2 elements in the given 2 lists. Now we can make it a bit more generic: if a type A has a method combine, then 2 lists of elements of type A can be combined together to give a new list of which each element is from combining 2 elements in the 2 given lists.

How do you implement it in Go? It can be done in Java with generics, but if I make the problem a little bit more generic, a little bit more complicated, then I don't think Java can do it.

[saagarjha]

Scala’s type system goes far beyond simple generics.

[continuational]

The marketing is very impressive indeed, I won't argue against that. I can only think of Angular 1.0 as an equally impressive feat of advertising (I totally bought into that - for a while).

But logically, what you suggest implies that either generics aren't absolutely needed, and shouldn't be in Go, or it's absolutely needed, and Go has been lacking them for a long time.

[nullspace]

I’m sorry, I don’t think you can state absolutes like this with respect to languages.

After 5 years of programming in Scala, professionally, writing and debugging a cli tool in Go-Lang felt like a breath of fresh air. I agree with about go marketing, in that I think the creators of go found a larger “market” of devs and understood them better.

[continuational]

I think you're replying to the wrong person - I merely explained how the absolutes in the parent post were self contradictory.

[yahyaheee]

haha yup, Go actually understands its community, Scala is more concerned with doing really "smart" stuff

[yahyaheee]

no it just implies the don't willy nilly throw in any feature into the language like Scala, and I am incredibly grateful for it after writing Scala for a couple years, what a mess

[playing_colours]

Scala tends to be more of a kitchen sink, kind of an academic experiment brought to industry, whereas Go is way too far down the path of having only “absolutely needed” features - they promoted it as a “pragmatic, boring” language to focus on your business and write consistent code. As a result, this approach makes the language less expressive, really boring for many engineers, and also, unfortunately, it brought some bad practices - repetitions, error handling from last century, etc.

Languages are in a big part matter of tastes, and it does not make sense to criticize their chosen approaches beyond objective technical merits for your tasks.

[yahyaheee]

Sure there are use cases for Scala, they are just few and far between nowadays. If your looking to experiment with crazy functional stuff have fun, just don't write actual software in it, which was unfortunately the outcome, and a bunch of companies paid the price

[bcrosby95]

This line of reasoning never made sense to me because there's plenty of stuff in the language that isn't absolutely needed, such as the various special syntax for certain concurrency constructs.

[yahyaheee]

They look at how their software is being used and the problems people are encountering using it and then decide what is the best path. To roughly quote Rob Pike 'every feature is useful, but they all have a cost, and its about weighing the outcomes'

[Cyph0n]

That’s precisely the issue imo: it’s a language carefully designed to meet Google’s requirements.

The whole “we don’t need generics” fiasco was hilarious, though.

[yahyaheee]

Its actually not designed to meet Googles requirements, that just something people who don't know Go say. They have a survey they put out every year and take feedback from customers on issues that arise. They try and fix those issues with as little code as possible, because code and features have a cost.

[Cyph0n]

Well, Go magically fits right between C++ and Java, which were both Google’s main backend languages AFAIK.

I wonder if generics and proper dependency management were on this survey you’re talking about...

[threatofrain]

IMO this would be a bet that the Go team does not implement generics in the vague near future. There's a difference between the Go team making a fundamental design judgment against generics vs the Go team feeling that no super-obvious proposition which balances all the values of Go has been put forth. I think it's a matter of time and resource.

[yahyaheee]

They are just against features with a high cost to the community, generics are pricey as they can go quite wrong. They are now entertaining ways of adding them while limiting their downsides.