61–70 of 291 posts
Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).
Earlier quoted context omitted.
how often do you sort? most of the time you would do a database ORDER BY instead.
I...I can't even believe you just said that. Go really does have a unique core audience.
I..I can't believe you just said that. Such generalizations based on a single comment by an anon.
Earlier quoted context omitted.
how often do you sort? most of the time you would do a database ORDER BY instead.
I...I can't even believe you just said that. Go really does have a unique core audience.
Earlier quoted context omitted.
Are the complaints about lack of generics really a minority thing? Writing separate functions to sort different types just strikes me as ridiculous. EDIT: My original tone was a bit nasty in retrospect. Did a little research and while I still am on the generics side, the current situation seems at least workable for a good number of use cases.
But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/
Earlier quoted context omitted.
Lack of exceptions is the main reason I won't use it.
I thought this as for a long time. Then I used go for awhile and I think I like the go way better. It solves the issues I had with execptionless languages without all the noise. With exceptions you most often just let them trickle up the call chain, which is the same thing you often do with err, just return it. And the returning the err works much better when doing async. Cross thread exceptions are a PITA and you ar…
Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).
Most of them have one original goal, and a core philosophy to go with that goal and that guides the compromises.
Take C for instance : its original goal was to write UNIX. Because of this, it has to be low level, portable, and efficient. These are the important things and that's why people use C. Features important for writing UNIX stuff get priority, this ensure consistency.
Go is Google's language, made to be effective at doing what Google does. And its direction ensure that people who follow Google's way of coding are happy. There are other options for those who don't like it.
Go is an example of how to be extremely successful by catering to the needs of the project's core audience (well-rounded stdlib, extremely fast GC, short build times, trivial deployment, etc) while paying much less attention to the vocal minority's complaints (generics, package system, etc).
Complaints about generics aren't coming from a minority group. It's a majority now.
Earlier quoted context omitted.
But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/
You're still writing separate functions (implementations of sort.Interface) to sort different types.
Earlier quoted context omitted.
I wonder how the presence of ADTs and absence of generic functions would mesh together. With ADTs, using a sum type instead of the `result, err = func(...)`, would be an obvious thing to do. But the next thing you'd consider would be `bind` / `>>=`.
I'm not sure why the next thing you'd consider is bind. It seems like plenty of languages with ADTs and generics still either don't have it available in their libraries, or use it extremely lightly, in spite of being able to implement it.
If you replace the two-value assignment with an `Either`, it feels very natural to also eschew the constant `if (err != nil) return err` lines, and adopt a continuation-passing style, the way you do with Futures in JavaScript. You could even consider some syntactic sugar around it, like the `?` operator of C# and Kotlin, or a full-on Haskell-like do-notation.