81–90 of 291 posts
Earlier quoted context omitted.
The best ecosystem out there? Since when? I'd say that Java and Python have huge, wonderful and full ecosystems. Golang doesn't even come close to that, yet. Furthermore, Golang doesn't even have a community standard (or several standards) dependency manager.
Python's packaging is a nightmare of half-baked, incompatible approaches that puts the lie to the famous "Zen of Python" that "There should be one-- and preferably only one --obvious way to do 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).
That's debatable. Those who can't stand the language don't bother using it,therefore don't bother complaining about it.
My point is Go biggest critics have already abandoned the language long ago.
Go reminds me Rails. It had a huge success 8 years ago but since all other languages have caught up when it comes to RAD webdev. The JVM and others will eventually catch up.
Earlier quoted context omitted.
Complaints about generics aren't coming from a minority group. It's a majority now.
How do you know? Anyone who is not interested in generics simply abstains from these discussions/polls. This skews perception.
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.
But to be honest, more than 50% of the cases where I needed data to be sorted in a certain way, that data came out of a relational database, and adding an ORDER BY-clause to the SQL query was so much easier than doing it myself.
I do agree with the second part of your comment in that Go has a certain type of application where it really shines. But that type of application is not uncommon, and when you hit the sweet spot, it really shines.
Earlier quoted context omitted.
They haven't said "No" to generics. What the developers want is for people to submit _actual_ problems that generics would solve, with examples. Because there are more than a few way to do it and they want to pick the right one.
It's simply astounding that the Google engineers working on Go lack the imagination to understand what problems generics would solve.
Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…
> 1. Probably the best ecosystem out there.
it will when it gets an acceptable PDF library, better enterprise integration (SOAP and co) and an actual debugger (and no Delve isn't good enough given how it often fails at basic debugging).
Go's biggest issues still seems to be the lack of a standard mature dependency management system.
The quote fits perfectly for the design of go.
Things I love about go: 1. Probably the best ecosystem out there. 2. Go routines 3. (Enabled by (2) actually) `defer` 4. That I can add interfaces implementations to structs I don’t own 5. No exceptions. Actually (5) is one of the few things I don’t like about Haskell. If Go had ADTs and generics it would easily be my favorite language. Edit: and of course the channels. Edit2: yeah, i have no idea why i connected (2)…
Novice here. Why is having no exceptions a good thing, in your opinion?
Earlier quoted context omitted.
You are not wrong. But I think there is more to it. I have used Go (almost) exclusively for private toy programs I write in my free time to relax (sounds weird, I know), so my perspective may be warped. But something about is very compatible with the way my mind works. With some other languages, say C or C#, I find myself constantly browsing through documentation to figure out what a given construct means in that lan…
> my intuition what I think a given piece of code should mean is nearly always in line with the language specification. for some things yes, but for others I think that it's more familiarity than intuition, take for example interface slices, you start by learning that you can assign any type to interface{}, so intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough t…
And as there is no way to immediately see where some interface is declared and if/which interface is implemented, you have to rely on comments and resort to manual search to find out more. That may be easy in smaller codebases or worthy of effort in important codebases such as Go standard library. But all an all this ambiguity does not fit with Go's discipline to prevent human errors by making everything uniform and explicit as possible.
Just for the sake of providing an example, let's look at time.go under https://golang.org/src/time/time.go, we can see in the comments of several functions that the programmer states a particular interface is implemented. Line 1112 of the aforementioned file is as follows:
// MarshalBinary implements the encoding.BinaryMarshaler interface.
func (t Time) MarshalBinary() ([]byte, error) {
Tl;dr All I'm saying is that runtime errors due to empty interfaces are not the only flaw of Golang. Interfaces as implemented in Go could in some cases present a serious threat to code structure.