Eight years of Go(blog.golang.org)
blog.golang.org
Eight years of Go
https://blog.golang.org/8years
290 comments
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).
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 language. And don't get me wrong, I like both of these languages.
But with Go, my intuition what I think a given piece of code should mean is nearly always in line with the language specification. The only other language I had this level of rapport with is Python.
There are many things I miss in Go, but all in all, I think it is simplicity done right.
BUT if Go had not also gotten the things right that you mention, it probably would not have become this popular.
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 language. And don't get me wrong, I like both of these languages.
But with Go, my intuition what I think a given piece of code should mean is nearly always in line with the language specification. The only other language I had this level of rapport with is Python.
There are many things I miss in Go, but all in all, I think it is simplicity done right.
BUT if Go had not also gotten the things right that you mention, it probably would not have become this popular.
Go does have brilliant simplicity! It's the simplicity of Pascal I used in middle school, and of Modula-2 I used on my freshman year, with basically the same syntax. I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon.
For writing toy programs to relax (can relate), I personally prefer Python, or maybe a Scheme. While also being simple at the core concepts, they have much more expressive power, an easier way to combine simple things into complex things. They pay for that by higher resource consumption, of course. I do fondly remember a PDP-11 Pascal compiler reporting "15 KB used" after compiling my program; you can't get a Python process with these constraints. But by now we have _vastly_ more computing power.
For writing toy programs to relax (can relate), I personally prefer Python, or maybe a Scheme. While also being simple at the core concepts, they have much more expressive power, an easier way to combine simple things into complex things. They pay for that by higher resource consumption, of course. I do fondly remember a PDP-11 Pascal compiler reporting "15 KB used" after compiling my program; you can't get a Python process with these constraints. But by now we have _vastly_ more computing power.
Go has human-sized simplicity. Programming language complexity is limited by human cognitive limitations, and Go has a small cognitive load.
This makes it feel like a very intuitive language.
That doesn't mean it is an intuitive language - just that it feels like one for a specific class of problems.
Personally I enjoy using it for the same reasons as everyone else. But... I'm also aware it's quite an old-fashioned language, with some bumps under the floorboards where useful things were hammered down to make them go away, instead of being fully solved.
This makes it feel like a very intuitive language.
That doesn't mean it is an intuitive language - just that it feels like one for a specific class of problems.
Personally I enjoy using it for the same reasons as everyone else. But... I'm also aware it's quite an old-fashioned language, with some bumps under the floorboards where useful things were hammered down to make them go away, instead of being fully solved.
There is a good chance you are right.
But as long as it is humans writing most/all Go code, fitting a human brain well is a valid design choice.
Yes, it has its fair share of problems. But for now, I find it preferable to anything else we have got.
But as long as it is humans writing most/all Go code, fitting a human brain well is a valid design choice.
Yes, it has its fair share of problems. But for now, I find it preferable to anything else we have got.
> I'm glad Go revived a number of good ideas from Pascal / Modula / Oberon.
Sadly it feels more like Oberon-07 than Modula-2, feature wise.
Sadly it feels more like Oberon-07 than Modula-2, feature wise.
> 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 that doesn't work
If you dig a bit it is completely understandable why it doesn't given how interfaces are laid out in memory, but from an intuitive standpoint you'd think that since you can do it in the scalar case you should be able to do it in the slice case too...
This is a very minor nitpick, I do agree that compared to many other languages golang is very easy to mentally parse, at the expense of some expressivity at times.
Whenever I code in it, which these days is pretty much all the time, I do miss some conveniences from other languages (generics, list comprehensions, ...) but of course every language has its tradeoffs, I most certainly miss golang's strengths every time I have to write some C or python.
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 that doesn't work
If you dig a bit it is completely understandable why it doesn't given how interfaces are laid out in memory, but from an intuitive standpoint you'd think that since you can do it in the scalar case you should be able to do it in the slice case too...
This is a very minor nitpick, I do agree that compared to many other languages golang is very easy to mentally parse, at the expense of some expressivity at times.
Whenever I code in it, which these days is pretty much all the time, I do miss some conveniences from other languages (generics, list comprehensions, ...) but of course every language has its tradeoffs, I most certainly miss golang's strengths every time I have to write some C or python.
IMO interfaces are the Achilles' heel of Golang. Another thing that has been bugging me about them is that you cannot specify which interface you're implementing in the code (beside from comments). I think that is so because Go hates circular imports. If you had to import a file to be able to use an interface, you'd soon run into compile errors due to circular dependencies.
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:
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.
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.
I actually experienced the opposite. Interfaces in go work so well, partly because you can create an interface which automatically gets satisfied by existing structures. For example I often use a requestDoer interface which only has the http clients "Do" method.
I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling.
The structurally typed interfaces are actually my favorite part about Go probably.
I'm using Goland so I have jump to interface from any structure implementing it. So that's another one that gets solved by tooling.
The structurally typed interfaces are actually my favorite part about Go probably.
How do you jump to the interface from any structure implementing it? Beside from comments there is no immediate way to which interface/interfaces a structure is implementing.
Maybe Gogland solves this by keeping records on all interfaces, and checking all structures whether they satisfy them. If that's the case, this is definitely solved by tooling.
Maybe Gogland solves this by keeping records on all interfaces, and checking all structures whether they satisfy them. If that's the case, this is definitely solved by tooling.
If you need this, you can write type assertion lines in a var block of the interfaces that you explicitly want to implement (and this will throw compile time errors if they don't).
The standard godoc documentation browser does this too when started with the -analysis option. They all use the same source code oracle functionality available from the x/tools repo.
No, Goland actually doesn't use that, they're rolling their own for everything.
Thanks for the correction. I think that's somewhat unfortunate, though. The powerful shared tooling is one of the strengths of the Go ecosystem and if there are issues with it that prevent the use in Goland I'd rather see those get fixed.
OTOH, they (Jetbrains) probably have shared infrastructure (between languages) within their IDE code base, too, and are more comfortable using their existing tooling.
OTOH, they (Jetbrains) probably have shared infrastructure (between languages) within their IDE code base, too, and are more comfortable using their existing tooling.
They are actually parsing the code into their custom ast format, so they have a lot of things done out of the box already.
That's exactly what it does as far as I know.
EDIT: I can also search for any interface with a struct selected, and generated stubs for all method. Well, basically what you get for any other language when implementing interfaces.
EDIT: I can also search for any interface with a struct selected, and generated stubs for all method. Well, basically what you get for any other language when implementing interfaces.
[deleted]
[deleted]
It would be nice to add at least the options to explicitly state that type X should implement interface I, and have the compiler barf / emit an error if X does not implement Y.
Like I said before, this has not been enough of a problem to really bother me, but I would be quite happy if Go fixed this.
Like I said before, this has not been enough of a problem to really bother me, but I would be quite happy if Go fixed this.
can't you simply do this (from [1]) somewhere in your code to enforce?
type T struct{}
var _ I = T{} // Verify that T implements I.
var _ I = (*T)(nil) // Verify that *T implements I.
Yes you could, but then you'd have to have both the declaration and the implementation of the interface in the same package. That would mean that if either of them is in a separate file, you'd have to import it. That in return, could easily call hellish compiler errors due to circular dependencies. In Go any circular dependency is an immediate compile error.
Looking at the link, the second advice is that you could require users to implement special functions such as ImplementsFooer() to explicitly declare which interface they're implementing. This could help, but this practice is not present in the codebases I've seen including the Go standard library (to the best of my knowledge).
Looking at the link, the second advice is that you could require users to implement special functions such as ImplementsFooer() to explicitly declare which interface they're implementing. This could help, but this practice is not present in the codebases I've seen including the Go standard library (to the best of my knowledge).
A possible solution is to have a separate (otherwise unused) package in your codebase with just a test in it:
//compile_test.go
func TestThatThisModuleCompiles(t* testing.T) {}
//list of "type implements interface" tests
var _ mymodule.MyInterface = myothermodule.MyStruct{}
...
That's a clever way to solve the issue. I think most Go codebases could benefit from such explicit checks where the language does not provide an unambiguous solution.
The interface issue has been on my mind for quite sometime. I had thought maybe declaring all interfaces in seperate files might help with the structure (like having the definitions in a header file in C), but the Go standard library does not use this approach. Interfaces and implementations are scattered across files and modules. Maybe I'm being too clever and we all know that Rob Pike always says that programmers should not be too clever. Maybe I should loosen up a bit, and treat Golang more like a pragmatic language. They did the best they could and produced a wonderful language. Any additional feature such as generics and explicit implements statements would have made the language much more complex.
The interface issue has been on my mind for quite sometime. I had thought maybe declaring all interfaces in seperate files might help with the structure (like having the definitions in a header file in C), but the Go standard library does not use this approach. Interfaces and implementations are scattered across files and modules. Maybe I'm being too clever and we all know that Rob Pike always says that programmers should not be too clever. Maybe I should loosen up a bit, and treat Golang more like a pragmatic language. They did the best they could and produced a wonderful language. Any additional feature such as generics and explicit implements statements would have made the language much more complex.
This can go even further.
All the go files in a directory have to declare the same package name (`package mypkg`), with one exception: a test file (filename ends with `_test.go`) that has a package name that's the same as the normal package but ends with `_test` (as in `package mypkg_test`) is allowed to be in the same directory.
These are actually completely separate packages and you have to import the main package if you want to actually use it. But when you run `go test` it automatically complies and runs tests in both packages. This means that you can import both your package and a dependent package to make sure interfaces are satisfied without any circular dependencies.
All the go files in a directory have to declare the same package name (`package mypkg`), with one exception: a test file (filename ends with `_test.go`) that has a package name that's the same as the normal package but ends with `_test` (as in `package mypkg_test`) is allowed to be in the same directory.
These are actually completely separate packages and you have to import the main package if you want to actually use it. But when you run `go test` it automatically complies and runs tests in both packages. This means that you can import both your package and a dependent package to make sure interfaces are satisfied without any circular dependencies.
Sibling comment shows one way to do it, but in most cases, at least for me, which is when both the struct and interface are in the same package it gets solved by the NewMyInterface method.
As it's return type is MyInterface, but it actually returns myStructure which causes the compiler to check the interface satisfying.
As it's return type is MyInterface, but it actually returns myStructure which causes the compiler to check the interface satisfying.
> And as there is no way to immediately see where some interface is declared and if/which interface is implemented
you can use go-oracle (https://camo.githubusercontent.com/3fb1d62bbc7b1306da783f395... that!
you can use go-oracle (https://camo.githubusercontent.com/3fb1d62bbc7b1306da783f395... that!
It's now called Go Guru:
https://docs.google.com/document/d/1_Y9xCEMj5S-7rv2ooHpZNH15...
https://docs.google.com/document/d/1_Y9xCEMj5S-7rv2ooHpZNH15...
> I think that is so because Go hates circular imports.
Well it could be but I don't think so --- "duck typing" when it comes to interface{}s has been a goal from early on, quite simply. The very idea of interfaces as "a set of func signatures" preclude the necessity to verbosely spell out "struct Foo implements BinaryMarshaler" and/or "func (_ Foo) MarshalBinary implements BinaryMarshaler.MarshalBinary"!
In the same vain, you don't even need to declare interface TYPES, you can accept/pass/return "inlined" interface{MethodSig(argtype)rettype} anywhere if you want. Not the most ergonomic choice in practice, but the possibility hints at this underlying interfaces-are-duck-typed-method-sets paradigm at work here.
Well it could be but I don't think so --- "duck typing" when it comes to interface{}s has been a goal from early on, quite simply. The very idea of interfaces as "a set of func signatures" preclude the necessity to verbosely spell out "struct Foo implements BinaryMarshaler" and/or "func (_ Foo) MarshalBinary implements BinaryMarshaler.MarshalBinary"!
In the same vain, you don't even need to declare interface TYPES, you can accept/pass/return "inlined" interface{MethodSig(argtype)rettype} anywhere if you want. Not the most ergonomic choice in practice, but the possibility hints at this underlying interfaces-are-duck-typed-method-sets paradigm at work here.
> 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 that doesn't work
Why do you expect this to be the case? Just because you can assign a char to an int in C, you wouldn't expect to be able to assign a char pointer to an int pointer. Similar for C++ and std::vector<char> vs std::vector<int>.
It's the same and probably even more relevant with void∗/int∗ (assignable) vs. void∗∗/int∗∗ (not assignable). You can assign an int∗∗ to a void∗, though, just as you can assign an []int to an interface{} in Go.
Also, even as an absolute greenfield programmer with no experience in other system languages, if you really think it through, you will come to the conclusion that it mustn't be possible to assign arbitrary slice values to an []interface{} variable, given the way slices work.
Why do you expect this to be the case? Just because you can assign a char to an int in C, you wouldn't expect to be able to assign a char pointer to an int pointer. Similar for C++ and std::vector<char> vs std::vector<int>.
It's the same and probably even more relevant with void∗/int∗ (assignable) vs. void∗∗/int∗∗ (not assignable). You can assign an int∗∗ to a void∗, though, just as you can assign an []int to an interface{} in Go.
Also, even as an absolute greenfield programmer with no experience in other system languages, if you really think it through, you will come to the conclusion that it mustn't be possible to assign arbitrary slice values to an []interface{} variable, given the way slices work.
> intuitively you'd think that you could assign any type slice to []interface{} but you find out soon enough that doesn't work
I've been writing Go for upwards of six years, professionally for three, and I have never tried that. I can't think of the last time I used interface{}...
I generally consider anything using interface{} crap code someone who doesn't know the language wrote, probably coming from a loosely typed language.
I've been writing Go for upwards of six years, professionally for three, and I have never tried that. I can't think of the last time I used interface{}...
I generally consider anything using interface{} crap code someone who doesn't know the language wrote, probably coming from a loosely typed language.
> I generally consider anything using interface{} crap code someone who doesn't know the language wrote, probably coming from a loosely typed language.
Disagree. There's ample usage of interface{} that you need to type-switch on in parts of the stdlib that deal with the AST and reflection or various other areas. You might also UnmarshalJSON a structure where some field can contain any one of a number of possible sub-structures. Once we're talking about 1-2 dozens of possible sub-structures, you'll have that field be an interface{} and type-switch on it --- rather than having 1-2 dozen pointer fields that will all-but-1 be nil and having to if-else through them all.
Disagree. There's ample usage of interface{} that you need to type-switch on in parts of the stdlib that deal with the AST and reflection or various other areas. You might also UnmarshalJSON a structure where some field can contain any one of a number of possible sub-structures. Once we're talking about 1-2 dozens of possible sub-structures, you'll have that field be an interface{} and type-switch on it --- rather than having 1-2 dozen pointer fields that will all-but-1 be nil and having to if-else through them all.
> I write in my free time to relax (sounds weird, I know)
Not weird at all. I do that myself. I believe the relaxation is in pure creativity, the wonder of exploring something novel and the absence of any pressure or stress due to timelines or deadlines. You're also exercising both right and left sides of the brain.
I suspect there are many many more who do the same.
Not weird at all. I do that myself. I believe the relaxation is in pure creativity, the wonder of exploring something novel and the absence of any pressure or stress due to timelines or deadlines. You're also exercising both right and left sides of the brain.
I suspect there are many many more who do the same.
Huh. That are exactly the reasons I would give if I had to explain that hobby to somebody. ;-)
Feels kind of good to know that I am not the only one doing this.
When it goes really well, programming is akin to what I think meditation must be like. But explaining that to people who have never programmed themselves is hard.
Feels kind of good to know that I am not the only one doing this.
When it goes really well, programming is akin to what I think meditation must be like. But explaining that to people who have never programmed themselves is hard.
> sounds weird, I know
No, it doesn't.
No, it doesn't.
That is a relief.
I know other people meet a similar purose by knitting or solving crossword puzzles, but explaining to them the trancendetal nature of their favorite pastime is quite difficult.
I know other people meet a similar purose by knitting or solving crossword puzzles, but explaining to them the trancendetal nature of their favorite pastime is quite difficult.
> But something about is very compatible with the way my mind works.
Yes. For me it is channels. After nearly 20 years of UNIX'ish systems, pipes are a mental abstraction that I do not have to think about any more. And channels fit right in, they feel much closer to a how a pipe is used on the cli than a pipe or socketpair ever did in code.
For example a range loop over a closed channel is, for me, piping things to xargs. It's easy to understand, reason and conceptualize because it feels familiar.
Yes. For me it is channels. After nearly 20 years of UNIX'ish systems, pipes are a mental abstraction that I do not have to think about any more. And channels fit right in, they feel much closer to a how a pipe is used on the cli than a pipe or socketpair ever did in code.
For example a range loop over a closed channel is, for me, piping things to xargs. It's easy to understand, reason and conceptualize because it feels familiar.
I'm not sure what you mean by vocal minority's complaints.
Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac...
(I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well)
Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded as a vocal minority, but above data doesn't seem to.
Golang generics is the second most voted issue on GitHub itself: https://github.com/issues?q=is%3Aopen+is%3Aissue+sort%3Areac...
(I'm not sure if GitHub sorting is broken, but the same issue has more +1s than the top +1d issue as per that sort mode as well)
Generics has the most experience reports in Go 2 proposal. Maybe this can be categorized and excluded as a vocal minority, but above data doesn't seem to.
It's the biggest issue, but that doesn't mean the majority of Go developers support it. 1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that.
But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.
But the people who read the proposal and reacted to it may be the vocal minority who are concerned about generics. The majority may not spend their time reading or reacting to proposals they don't care about.
>Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.
And many more want Generics without having responded to the issue.
Issues are representative as a sampling, not absolute numbers.
And many more want Generics without having responded to the issue.
Issues are representative as a sampling, not absolute numbers.
Unless you do random sampling, you still can't conclude anything one way or the other about whether it's a majority of users. Perhaps something like Google Surveys could be used to settle this?
I'm not sure who you're quoting or why.
> Issues are representative as a sampling, not absolute numbers.
My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again:
>> The majority may not spend their time reading or reacting to proposals they don't care about.
Maybe the majority do want generics, but the Github issue is poor evidence. A random sample of Go developers would be much better, and then we wouldn't have to make up things like "And many more want Generics without having responded to the issue."
> Issues are representative as a sampling, not absolute numbers.
My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it. I'll say it again:
>> The majority may not spend their time reading or reacting to proposals they don't care about.
Maybe the majority do want generics, but the Github issue is poor evidence. A random sample of Go developers would be much better, and then we wouldn't have to make up things like "And many more want Generics without having responded to the issue."
>I'm not sure who you're quoting or why.
I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread.
Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that".
>* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it.*
And my point is that I don't think this is the case. I don't know either way, but there's no reason to assume people caring to vote in the issue are necessarily not representative -- like I don't think that for any other project/issue combo on github.
In any case, even if they aren't representative of existing heavy Golang users, who cares about them? The language is still niche. There are tons more programmers to come to the language than those that already are using already.
So I would very much pay attention to what those not yet using it but caring enough to vote have to say about it.
I accidentally re-pasted the same quote from nine_k I've answered to higher up the thread.
Meant to quote this from you: "1734 people reacted to the generics issue, most in favor, but there are many more Go developers than that".
>* My point was that issues are not a reliable sample of the Go community as a whole. They're a self-selected population of Go developers who cared enough about generics to click on a Github proposal on the subject and react to it.*
And my point is that I don't think this is the case. I don't know either way, but there's no reason to assume people caring to vote in the issue are necessarily not representative -- like I don't think that for any other project/issue combo on github.
In any case, even if they aren't representative of existing heavy Golang users, who cares about them? The language is still niche. There are tons more programmers to come to the language than those that already are using already.
So I would very much pay attention to what those not yet using it but caring enough to vote have to say about it.
Yeah, I would guess you're right, most existing (and potential) users would probably appreciate having generics.
Speaking as someone who worked fulltime with C# when it was relatively simple in v1/1.1 which was before generics, and Object Pascal/Delphi for many years before then - when generics arrived in C# 2 it was a truly wonderful upgrade.
However the complexity of C# has exploded over the years, and it now lacks in simplicity, where Go shines. Yet I expect adding generics would improve Go as it certainly improved C#.
However the trick is knowing when to stop adding features, and with with the incredible pace of churn in most languages these days, it's a major competitive advantage to just not change the language. And advantage that would complement the simplicity of Go nicely.
(Of course it's theoretically possible for users to not upgrade as the language upgrades, but the reality is when the language changes it fragments the documentation, user base, and overall experience - so the argument for users not to upgrade, is not realistic.)
In chess there is the concept of a zugzwang, a situation where it's actually a dis-advantage to make a move. There's lots of other kitchen sink languages these days, Go may be best to keep building on the strength of it's simplicity, by simply not changing.
However the complexity of C# has exploded over the years, and it now lacks in simplicity, where Go shines. Yet I expect adding generics would improve Go as it certainly improved C#.
However the trick is knowing when to stop adding features, and with with the incredible pace of churn in most languages these days, it's a major competitive advantage to just not change the language. And advantage that would complement the simplicity of Go nicely.
(Of course it's theoretically possible for users to not upgrade as the language upgrades, but the reality is when the language changes it fragments the documentation, user base, and overall experience - so the argument for users not to upgrade, is not realistic.)
In chess there is the concept of a zugzwang, a situation where it's actually a dis-advantage to make a move. There's lots of other kitchen sink languages these days, Go may be best to keep building on the strength of it's simplicity, by simply not changing.
And then there are many Go users, who don't really care for generics, or like me, think generics could be nice, but could also make the language more complex than desirable.
If someone came up with a practical, clean, working proposal for Go - then absolutely. But so far I've only seen complaints and proposals where the conclusion starts with "this proposal will not be adopted" - mostly because it's somehow flawed.
If someone came up with a practical, clean, working proposal for Go - then absolutely. But so far I've only seen complaints and proposals where the conclusion starts with "this proposal will not be adopted" - mostly because it's somehow flawed.
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.
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.
That's easy. Concurrent access to maps is unsafe. https://golang.org/pkg/sync/#Map should be a drop-in replacement but due to the lack of generics it can't present a compatible or typesafe API.
I've run into concurrency problems using maps while writing an irc client. It was really frustrating for me, because it did not happen everytime I ran the program, but rather rarely. I had chosen Go for it's memory-safety and easy concurrency. But I felt like I could not vouch for my program's safety any more. I did not know about sync/map at the time, had I known, I would probably have used it.
I think Golang has a fondness for magical (to me) special language constructs. For example if you want to use the RPC modules, you have to write your functions a certain way. Or as I've explained in a comment above, if you want to use an interface you just have to implement all it's properties. Or you can't have generics, but we have a special language construct called maps, where you kind of can mimick genericks but it is not safe and may break.
Golang is a great language, but I think it expects all its users to think very rigidly in the same way their designers do. Basically, you have to explore the language's deficiencies yourself, read the designers' explanations, dive into the intrinsics of the language, understand it, make yourself believe and move on. I sometimes half-jokingly feel like Golang follows the principle of most obedience.
I think Golang has a fondness for magical (to me) special language constructs. For example if you want to use the RPC modules, you have to write your functions a certain way. Or as I've explained in a comment above, if you want to use an interface you just have to implement all it's properties. Or you can't have generics, but we have a special language construct called maps, where you kind of can mimick genericks but it is not safe and may break.
Golang is a great language, but I think it expects all its users to think very rigidly in the same way their designers do. Basically, you have to explore the language's deficiencies yourself, read the designers' explanations, dive into the intrinsics of the language, understand it, make yourself believe and move on. I sometimes half-jokingly feel like Golang follows the principle of most obedience.
> I did not know about sync/map at the time
Apparently also not about sync.Mutex =)
> if you want to use an interface you just have to implement all it's properties
You surely mean "methods" --- don't interfaces work like that everywhere they exist?
Apparently also not about sync.Mutex =)
> if you want to use an interface you just have to implement all it's properties
You surely mean "methods" --- don't interfaces work like that everywhere they exist?
I discovered Waitgroups during the project, but I have no formal training in concurrent programming, so it was a bit daunting for me. And as the error occured very rarely I could not be sure if using a mutex had solved my problem. But now I understand mutex was the way to go for accessing a shared resource.
As for the second point, sorry for the wrong wording, I meant "methods". But interfaces don't work like that everywhere they exist. For example in Java you explicitly use Class X implements Y, and if you do not implement all methods and properties, the compiler complains.
As for the second point, sorry for the wrong wording, I meant "methods". But interfaces don't work like that everywhere they exist. For example in Java you explicitly use Class X implements Y, and if you do not implement all methods and properties, the compiler complains.
> I discovered Waitgroups during the project
Don't know about your exact map use-case you had at hand, but generally speaking the Mutexes suffice for Lock()ing/Unlock()ing a resource that is accessed concurrently, whereas the WaitGroups serve usually best to just fire off a couple of parallel jobs (that don't access any shared-between-them resources) and then simply Wait() for them all to finish. No real protection from concurrent accesses in there, other than for the WaitGroup's own hidden internal counter that's used to Wait()
Of course these are the low-level sync primitives, channels are the higher-level abstraction, but the former can take you far --- sometimes the latter are the sanest/only choice of course. Especially for parallel goroutines needing to work with each other's intermediate results.
Don't know about your exact map use-case you had at hand, but generally speaking the Mutexes suffice for Lock()ing/Unlock()ing a resource that is accessed concurrently, whereas the WaitGroups serve usually best to just fire off a couple of parallel jobs (that don't access any shared-between-them resources) and then simply Wait() for them all to finish. No real protection from concurrent accesses in there, other than for the WaitGroup's own hidden internal counter that's used to Wait()
Of course these are the low-level sync primitives, channels are the higher-level abstraction, but the former can take you far --- sometimes the latter are the sanest/only choice of course. Especially for parallel goroutines needing to work with each other's intermediate results.
Java interfaces don't have properties either (nor do Java classes), and you can explicitly state interface conformance in Go as well as others have explained elsewhere in this debate: https://news.ycombinator.com/item?id=15672619
What Java does have (since 8) is default method implementations in interfaces.
What Java does have (since 8) is default method implementations in interfaces.
Sorry, my fault. It seems in java you can declare constants in interfaces, but this is frowned upon.
(Another useful link explaining that statements resembling instance variables in interfaces are in fact constants: https://coderanch.com/t/178630/certification/Instance-variab...)
Interfaces cannot require instance variables to be defined -- only methods.
(Variables can be defined in interfaces, but they do not behave as might be expected: they are treated as final static.)(Another useful link explaining that statements resembling instance variables in interfaces are in fact constants: https://coderanch.com/t/178630/certification/Instance-variab...)
For concurrency issues, -race flag is your friend.
Don't blame the language for your buggy code.
Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe.
In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).
Don't blame the language for your buggy code.
Unless otherwise stated, Go's data structures are not thread-safe. Maps are not thread safe.
In that respect Go isn't different from any other mainstream language with pre-emptive threading (C++, Java, C#).
go, a language which comes with many built in concurrency primitives, has chosen to leave its core datatypes thread unsafe (the magic ones with generic powers) and gives no sensible tools to remedy this with. this is one of the many ways in which it is a language hostile to its users.
Often, you don’t need concurrent types and their overhead. The sync package makes it easy to bolt on if you truly do.
It’s not as if every block is sending out each line to run in a separate goroutine. Go encourages users to share data by communicating, not communicating by sharing data [0].
On phone, sorry for syntax
It’s not as if every block is sending out each line to run in a separate goroutine. Go encourages users to share data by communicating, not communicating by sharing data [0].
On phone, sorry for syntax
struct CMap {
sync.RWMutex
i int
}
func (m *CMap) Inc() {
m.RWLock()
defer m.Unlock()
m.i++
}
i understand the patterns and design intentions of the language, despite not having written very much of it. (i just checked my work stats and i'm surprised to find that i've written/changed nearly 40k lines of go - of course that counts for less given how verbose the language is). one of my complaints is that a language designed to be simple has made (to me) incomprehensible design choices in the name of efficiency.
for instance, in a for loop ranging over a slice:
for your example, you can look to the newly added sync/map which uses interface{} everywhere as an example of how the lack of generics have left users with no _sensible_ tools to remedy these kinds of language problems. how wonderful would an efficient thread-safe and type-safe concurrent map be? it's possible in many other modern and not so modern programming languages, but it is intentionally not possible in go.
for instance, in a for loop ranging over a slice:
for _, i := range some_slice {
go func() {
something(i)
}()
}
for your example, you can look to the newly added sync/map which uses interface{} everywhere as an example of how the lack of generics have left users with no _sensible_ tools to remedy these kinds of language problems. how wonderful would an efficient thread-safe and type-safe concurrent map be? it's possible in many other modern and not so modern programming languages, but it is intentionally not possible in go.
Java gets this right.
for (int i : someCollection) {
pool.execute(() -> something(i));
}
>Don't blame the language for your buggy code.
No, DO blame the language if its the one that enables and allows for said buggy code when it could as well prevent it.
Case in point: http://lambda-the-ultimate.org/node/3186
No, DO blame the language if its the one that enables and allows for said buggy code when it could as well prevent it.
Case in point: http://lambda-the-ultimate.org/node/3186
Fair enough, in that case.
However a common situation is that the language is supporting a wide range of uses, not just the use a particular developer has in mind at the time.
I've seen this most commonly where a developer operating at a higher level of abstraction, without understanding low level details, complains that the language doesn't match his high level needs exactly.
When in fact it supports lower level operations for maximum performance or flexibility, while allowing layering on top for higher level uses. In language design it's essential to support the lowest level use cases you are targeting, because you can build on top but not go lower than the language exposes (unless it supports embedded asm or another trick to go lower again). I'm using higher/lower here only to refer in the sense of the level of abstraction.
It's a really common trap for someone working usually at one level of abstraction and not deeply understand other levels, to not understanding why a language or library is the way it is because if needs to support others users needs that are different to ones own - I've done it myself enough to detect the pattern, and seen lots of other people do it. Lurking on design committee discussions can be eye opening!
However a common situation is that the language is supporting a wide range of uses, not just the use a particular developer has in mind at the time.
I've seen this most commonly where a developer operating at a higher level of abstraction, without understanding low level details, complains that the language doesn't match his high level needs exactly.
When in fact it supports lower level operations for maximum performance or flexibility, while allowing layering on top for higher level uses. In language design it's essential to support the lowest level use cases you are targeting, because you can build on top but not go lower than the language exposes (unless it supports embedded asm or another trick to go lower again). I'm using higher/lower here only to refer in the sense of the level of abstraction.
It's a really common trap for someone working usually at one level of abstraction and not deeply understand other levels, to not understanding why a language or library is the way it is because if needs to support others users needs that are different to ones own - I've done it myself enough to detect the pattern, and seen lots of other people do it. Lurking on design committee discussions can be eye opening!
kmicklas(1)
It is a vocal minority in the (probably correct) assumption that the majority of Go programmers are not part of that GitHub issue, nor any other group asking for Generics.
I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first.
Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.
Frankly, there is a number of reasonably nice languages that do provide generics, good / great type systems, good / great package management, decent async features, and quite decent performance: Rust, Nim, Crystal, ... all the way down to Haskell. Go is not competing with them at their strongest features. Instead, it's in the sweet spot of simplicity, fast build times, reasonable hygiene, and trivial deployment. It's the "getting job done" mentality which worked so well for PHP and Perl back in the day. There is a considerable demand for that.
Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.
Frankly, there is a number of reasonably nice languages that do provide generics, good / great type systems, good / great package management, decent async features, and quite decent performance: Rust, Nim, Crystal, ... all the way down to Haskell. Go is not competing with them at their strongest features. Instead, it's in the sweet spot of simplicity, fast build times, reasonable hygiene, and trivial deployment. It's the "getting job done" mentality which worked so well for PHP and Perl back in the day. There is a considerable demand for that.
>I'm afraid not all votes are (and should be) considered equal by the project maintainers. A great number of casual Go users might want feature XYZ. OTOH a couple dozen of large Go projects, with combined millions MLOCs and hundreds of millions of end users, may have a different list of priorities, and these priorities might be catered first.
Many large users writing in company and project blogs have mentioned lack of Generics as a pain point, so that distinction doesn't go very far.
>Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.
Go was not created through some official decree to create a Google language, nor was it mandated to be used or to have some timeline to convert other stuff to it, etc.
It's just a project started by some Go people with the idea "let's examine what a language appropriate for Google's programming would be" -- but using their personal ideas of what Google style programming would need, not something requested, researched etc by Google as an organization. In other words it started as a glorified 20% project, and today it's not any more official in Google than C++ or Java is.
Many large users writing in company and project blogs have mentioned lack of Generics as a pain point, so that distinction doesn't go very far.
>Also, let's not forget that Go is created at Google, and definitely Google's internal projects, likely large-scale by both line count and users served metrics, must take priority.
Go was not created through some official decree to create a Google language, nor was it mandated to be used or to have some timeline to convert other stuff to it, etc.
It's just a project started by some Go people with the idea "let's examine what a language appropriate for Google's programming would be" -- but using their personal ideas of what Google style programming would need, not something requested, researched etc by Google as an organization. In other words it started as a glorified 20% project, and today it's not any more official in Google than C++ or Java is.
Actually I think it's one of half a dozen languages whose use is mandated at Google
I suspect that Rob Pike's and Russ Cox's work is paid for by Google.
But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.
But even if it were not, I suspect that heavyweight users like Google do have a weighty say, just because of the sheer amount of practical experience they have with developing and running software using the language. Just like Mozilla, I suppose, do have a say in the development of Rust.
We’ve actually worked a lot to ensure that Mozilla can’t dictate what happens with Rust; we run a consensus based process, and while Mozilla has the largest single group of people involved in leadership, it’s still a very stark minority.
As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.
As a huge production user, Mozilla’s needs are still important to us, but we think of Rust as an open source project Mozilla contributes to, not a Mozilla project per se.
I wonder if this is good or bad. Sometimes it helps to have that singular vision. I think here of all the systems C coders I know, who have never used complex numbers, yet that finds its way into the standard.
As a Rust user outside of Mozilla, it's very good. Rust would have had a hacked-on OO system solely in order to implement the DOM in Servo if browser engine hackers were the only ones with a voice. :P
It's fair to be concerned at the potential evolution of a language that doesn't have a BDFL (I myself came to Rust from Python, after all), but in practice I've come to trust the Rust devs as having very good taste (objective, I know!) and a strong resistance to maximalism (regardless of what some may claim... the list of features removed from the language is longer than the list of features that it has!).
It's fair to be concerned at the potential evolution of a language that doesn't have a BDFL (I myself came to Rust from Python, after all), but in practice I've come to trust the Rust devs as having very good taste (objective, I know!) and a strong resistance to maximalism (regardless of what some may claim... the list of features removed from the language is longer than the list of features that it has!).
I think in general, the teams, and especially the core team, have a "singular vision" in the big-picture case; this helps. It really can go any way though, I've also seen BDFL projects where the D doesn't care about what the community wants, which ends up with that complex number problem too.
>I suspect that Rob Pike's and Russ Cox's work is paid for by Google.
They are. The distinction I'm trying to make is they have not been tasked to "create an official Google language for Google scale projects", nor what the language officially adopted as "THE" google language the way e.g. Kotlin was officially adopted as a language for Android programming.
Some googlers (Pike and Cox among them) sat and designed a language that they thought would be good for Google scale programming (according to their ideas and experience) and they went and implemented it. Google paid their salaries the whole time, but at least at first, not for the purpose of creating such a language. After the language is out it paid, and even added more people, to keep it going --it gives good PR, and can be used internally here and there, so that's worth it to them.
It's just not "the Google language" in the way Obj-C/Swift are the Apple languages and C#/VC++ is the MS one (the company heavily investing in them, explicitly asking them to be built, suggesting their use everywhere, etc. For Google it's more of a side project than what e.g. Lars Bak worked on.
They are. The distinction I'm trying to make is they have not been tasked to "create an official Google language for Google scale projects", nor what the language officially adopted as "THE" google language the way e.g. Kotlin was officially adopted as a language for Android programming.
Some googlers (Pike and Cox among them) sat and designed a language that they thought would be good for Google scale programming (according to their ideas and experience) and they went and implemented it. Google paid their salaries the whole time, but at least at first, not for the purpose of creating such a language. After the language is out it paid, and even added more people, to keep it going --it gives good PR, and can be used internally here and there, so that's worth it to them.
It's just not "the Google language" in the way Obj-C/Swift are the Apple languages and C#/VC++ is the MS one (the company heavily investing in them, explicitly asking them to be built, suggesting their use everywhere, etc. For Google it's more of a side project than what e.g. Lars Bak worked on.
The most vocal group is the always the one that is not happy with someone. Doesn't mean this is majority and often it's not.
Thanks for pointing that out, I went there to downvote the issue.
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.
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.
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.
(This is not endorsement of the parent post; I don’t agree with it either.)
This is how you can sort slices of arbitrary types in Go:
https://play.golang.org/p/VHJW9lVY9b
I’m not sure about you, but it feels very reasonable to me. It’s not anywhere near the top of my list of pains that I feel when working with Go everyday.
This is how you can sort slices of arbitrary types in Go:
https://play.golang.org/p/VHJW9lVY9b
I’m not sure about you, but it feels very reasonable to me. It’s not anywhere near the top of my list of pains that I feel when working with Go everyday.
more like tree_of_interface{}
interfaces are a poor substitute for generics, but that's by design. the minute they add a reasonable implementation of generics Go will begin to metastatize into something unrecognizable as people will no longer be bound by the limitations of the already existing core generic types. the core developers really do not want that to happen.
it's a highly opinionated language and for some reason some people enjoy writing mountains of for loops so that their code can remain "simple" as they produce a maze of twisty funcs all alike. i mostly see a for loop or two per func with a map and some slices repeating the same patterns over and over. that's the way the language designers want it.
i work with a lot of go programmers and they are all fine and good programmers. that makes it even harder to understand why they enjoy all the boilerplate and even defend it.
interfaces are a poor substitute for generics, but that's by design. the minute they add a reasonable implementation of generics Go will begin to metastatize into something unrecognizable as people will no longer be bound by the limitations of the already existing core generic types. the core developers really do not want that to happen.
it's a highly opinionated language and for some reason some people enjoy writing mountains of for loops so that their code can remain "simple" as they produce a maze of twisty funcs all alike. i mostly see a for loop or two per func with a map and some slices repeating the same patterns over and over. that's the way the language designers want it.
i work with a lot of go programmers and they are all fine and good programmers. that makes it even harder to understand why they enjoy all the boilerplate and even defend it.
> 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.
I..I can't believe you just said that. Such generalizations based on a single comment by an anon.
Ignorant here (I've never done database work):
What's wrong with asking the database to do the sorting for you? (assuming you do work that involves a database. Perhaps this assumption itself is the problem?)
I understand why that would make you uncomfortable. ;-)
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.
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.
care to enlighten me? if you have an index you could get the sort for free, also you never pull all results, so why would you pull all, just to sort, on the web I would love to work more in ram, but since you assume a server will crash, you need to save the actual state in the db.
I didn't down-vote, but what jumps out to me is the assumption that you'll generally be pulling data from a database. Yeah, that's almost certainly true in a web-application, but it's not going to be nearly as universal in a systems-programming niche which is where Go appears to be excelling (as perceived by someone outside of the Go community).
So ease of implementing sorting in your core language without making assumptions about the operating environment of code written in that language sounds like a reasonable demand.
So ease of implementing sorting in your core language without making assumptions about the operating environment of code written in that language sounds like a reasonable demand.
Thanks, that was great. :D
can't tell if joking
Assuming developers are rational in their choices, by far most of the Go developers still prefer to use the language without generics.
I think its just a minor problem compared to all benefits.
I think its just a minor problem compared to all benefits.
> by far most of the Go developers still prefer to use the language without generics
I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.
I've been writing Go regularly for at least 5 years, and my guess is that at most 60% of Go developers prefer no generics. I also think that number is climbing.
I write Go at work but have never heard anyone say this.
Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?
Can you explain why you would prefer no generics to this dumb junior engineer who wants to be enlightened?
Not OP, and this is only one aspect to consider, but it's from experience - when generics were added to C# the language became nicer to use, but it caused a lot of churn and added complexity. The base libraries have the original non-generic classes as well as newer generic ones.
As I've written above, there's huge potential to be the language that doesn't churn, when just about everything else does these days.
As I've written above, there's huge potential to be the language that doesn't churn, when just about everything else does these days.
To be clear I prefer generics. The cases for why other Go developers don't want generics seem to mostly fall on "it will change the language / encourage people to write stupidly complex code" to "it's too hard to implement". The first one is valid--Go's constraints give it this nice property that there is (more or less) one obvious way to write most programs, and that will go away with generics; however, I think that cost is worth the gain. The other criticism seems like a cop-out; the Go team has far and away more than enough talent to slap generics onto the language.
Not the OP, but here are my 2¢. Introducing generics in a language implies a deep revision of the type system, which risks to become much more complex to understand. Moreover, this might have a bad impact on compilation performance (compare C++ compilation times with Go compilation times and you'll understand what I mean).
C++ compile times are huge for many reasons, but templates are only one of them. And note that templates aren't the same thing as generics.
Java has near-instant compile times and has generics. Likewise for Kotlin. Generics don't have to mean slow compiles.
Java has near-instant compile times and has generics. Likewise for Kotlin. Generics don't have to mean slow compiles.
It sounds like you're saying Java's generics are somehow superior to C++ templates.
For those who don't know, C++ generates a separate instance of the code for each type which means that it can operate directly on a value instead of through a reference/pointer and it also makes it possible for the compiler to inline the type-specific code in many cases. Ie., it has the potential to be much more efficient. That is why it works the way it does. The downside is that the code generation slows down compile times, as you noted.
Java simply casts a reference to an instance of Object to the type on behalf of the user. So you effectively have generic code the way it's done in C (void*) and Go (interface{}) but without the explicit casts.
Maybe the JIT offsets many of these inefficiencies but making that comparison is beyond me. I only bring this up because you made it sound like Java got generics completely right and C++ got it all wrong, and with the amount of flak C++ gets these days I think it deserves a little help now and then.
For those who don't know, C++ generates a separate instance of the code for each type which means that it can operate directly on a value instead of through a reference/pointer and it also makes it possible for the compiler to inline the type-specific code in many cases. Ie., it has the potential to be much more efficient. That is why it works the way it does. The downside is that the code generation slows down compile times, as you noted.
Java simply casts a reference to an instance of Object to the type on behalf of the user. So you effectively have generic code the way it's done in C (void*) and Go (interface{}) but without the explicit casts.
Maybe the JIT offsets many of these inefficiencies but making that comparison is beyond me. I only bring this up because you made it sound like Java got generics completely right and C++ got it all wrong, and with the amount of flak C++ gets these days I think it deserves a little help now and then.
I didn't intend it to come across like that. C++ is how you have to do aggressive type specialisations and optimisations in the absence of a JITC. Java's JITC is able to do many of the same things at runtime as C++ does at compile time, but it's less predictable.
I was not referring to templates only, but to the overall complexity of the C++ language. Examples: syntactic ambiguities, the preprocessor... Templates are a big part of the problem, but not the only one for sure. Languages like Free Pascal have outstanding compilation times because they privileged language simplicity, and IMHO Go falls in the same ballpark.
yes, but those of us who would desperately like to use Go because there are vanishingly few GC languages that compile to native exe AOT, won't because of no generics. So it is a bit of a tautology.
How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much better performance vs the workarounds available.
I wonder how many people who prefer Go without generics are coming from C++ templates, or Java generics, vs C# or F# generics.
How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much better performance vs the workarounds available.
I wonder how many people who prefer Go without generics are coming from C++ templates, or Java generics, vs C# or F# generics.
Have a look at .NET Native with .NET core, it support AOT compilation with GC, and a very fully featured language and cross platform targets.
see https://blog.rendle.io/what-ive-learned-about-dotnet-native/ https://stackoverflow.com/questions/29609993/difference-betw... https://docs.microsoft.com/en-us/dotnet/framework/net-native...
see https://blog.rendle.io/what-ive-learned-about-dotnet-native/ https://stackoverflow.com/questions/29609993/difference-betw... https://docs.microsoft.com/en-us/dotnet/framework/net-native...
To be clear, I agree with you. I was just responding to the OP's claim that the Go community overwhelmingly rejects generics with my perception that at most 60% of the community feels that way. I am very much in favor of generics.
What's the big need for an AOT native EXE for you? You just don't want to copy a directory tree instead of a single file?
Not OP, but I can't execute a directory tree. I always seem to need a runtime, and often additional libraries and a bunch of `$*PATH` munging so the compiler locates the _correct_ dependencies.
Performance is often the answer.
[deleted]
But you don't need to do that. It's a bit clunkier than generics, but it's usable: https://golang.org/pkg/sort/
I have had the need to sort data rarely enough that it has not been a real problem to me (most of the time that data came out of a relational database that did the sorting for me).
But when I did have the need to sort stuff, I have found it annoying. Even C has a more convenient solution for this problem. (Admittedly, Go's sort.Sort can work for data structures other than arrays/slices.)
Like I said, it has not been a sufficiently large problem to really bother me, but it is not a pretty solution, IMHO.
Of course, one might argue that the creators of Go knew that sorting things was not such a common problem for their target audience, and thus they made the trade off to make sorting suck in return for overall simplicity; Go's type system makes it practically impossible to implement a type-generic sorting function like C's qsort(3) without sacrificing performance or making the language more complex.
So maybe that is one of the trade offs we have to make. I still wish for a better solution, even if that may be impossible without turning Go into another C++. And if you like C++, that is totally fine, it has a number of very big advantages. But then you do not need Go to become another C++ if you have the original right there; and even if you wanted to get away from C++ without giving up the benefits it offers, D looks like a more promising alternative.
But when I did have the need to sort stuff, I have found it annoying. Even C has a more convenient solution for this problem. (Admittedly, Go's sort.Sort can work for data structures other than arrays/slices.)
Like I said, it has not been a sufficiently large problem to really bother me, but it is not a pretty solution, IMHO.
Of course, one might argue that the creators of Go knew that sorting things was not such a common problem for their target audience, and thus they made the trade off to make sorting suck in return for overall simplicity; Go's type system makes it practically impossible to implement a type-generic sorting function like C's qsort(3) without sacrificing performance or making the language more complex.
So maybe that is one of the trade offs we have to make. I still wish for a better solution, even if that may be impossible without turning Go into another C++. And if you like C++, that is totally fine, it has a number of very big advantages. But then you do not need Go to become another C++ if you have the original right there; and even if you wanted to get away from C++ without giving up the benefits it offers, D looks like a more promising alternative.
You're still writing separate functions (implementations of sort.Interface) to sort different types.
For sorting slices you only have to pass one function:
sort.Slice(s, func(i, j int) bool { return s[i].X < s[j].X })But this is something you often need to do for any non-trivial type, even with generics. There's a reason that C++ std::sort<> takes a comparator, or why Rust requires you to implement the 'Ord' interface.
Again, it's a little clunkier in Go, but not unusably so.
Again, it's a little clunkier in Go, but not unusably so.
You need to define how to order things in other languages (though not in languages where you can automatically derive implementations like Haskell or languages with built-in polymorphic comparison like OCaml) but you don't need to define how to swap elements over and over.
Yes, I'm aware. That's the clunky part that I was referring to (although, you can still avoid it for slices, and simply pass a single compare function.)
Go is far from my favorite language, but the sheer amount of bad criticism by people that clearly don't use the language annoys me.
Go is far from my favorite language, but the sheer amount of bad criticism by people that clearly don't use the language annoys me.
A little boilerplate hasn't killed anyone. If you're talking about "100s of different Enterprise Business Objects (TM) structs", something is probably off in the overall program design and/or code-gen should probably be introduced regardless of the 'sort' (and related typically-generics use-cases) question, as that sounds like something to be largely derived from pre-existing schemas of some sort..
> A little boilerplate hasn't killed anyone.
It's annoying, especially since basic generics are simpler than interfaces.
> If you're talking about "100s of different Enterprise Business Objects (TM) structs"
I don't write enterprise software. I sometimes need to sort things.
It's annoying, especially since basic generics are simpler than interfaces.
> If you're talking about "100s of different Enterprise Business Objects (TM) structs"
I don't write enterprise software. I sometimes need to sort things.
I did a little research after I posted my original comment and came across that. It does seem usable even if it's not what I'd prefer
I've been using Go at work and for my personal projects for over 4.5 years. I rarely have to sort. It's not a big deal for me.
It's not about sorting, it's about every single abstract operation on a collection or other type of container. You either have to use primitives, or reimplement everything yourself on each new type. Most people just use primitives. This proliferation of primitives is what I actually dislike about reading and writing code in Go, but it's caused by not having a way to define abstract data types that work well.
There are a few good templating (gengen, genny, etc) solutions for generics in Go, but yeah, it would be nice if it was baked into the language.
Yes, it is minor. Go has interfaces, so you just write a Comparer interface and sorter that takes two Comparers and then anything implementing Comparer is sortable.
*Note: author has written basically nothing in Go and only has a passing familiarity.
*Note: author has written basically nothing in Go and only has a passing familiarity.
So you define the Comparer interface with a Compare method. What does it look like?
If I have a struct X, then I might write it as:
But that's exactly what generics are.
You know how Java has .equals? Go doesn't have an equivalent concept. Test code is neigh unreadable because there is no generic way to compare two structs of the same type. This is a similar problem.
If I have a struct X, then I might write it as:
interface Comparer {
Compare(other X)
}
But that's exactly what generics are.
You know how Java has .equals? Go doesn't have an equivalent concept. Test code is neigh unreadable because there is no generic way to compare two structs of the same type. This is a similar problem.
I am admittedly thinking of an interface from how they work in Java, so I may be making incorrect assumptions about how they work in Go, but wouldn't I have to do that anyway? In what sense can the compiler work out how I want to compare my types? If I hand it some vec3s, for instance, does it know I want them sorted by x value, or by length?
By defining an interface that assures the compiler each type has a compare(x) method, I can write a generic sort function that takes any two comparable objects and sorts them based on whatever the class of those objects decided was the ordering criteria.
By defining an interface that assures the compiler each type has a compare(x) method, I can write a generic sort function that takes any two comparable objects and sorts them based on whatever the class of those objects decided was the ordering criteria.
If your `Comparer` is an element type (as opposed to Go's `sort.Interface` abstraction over collections), this is going to be horribly unperformant. Suppose your `Foo` type implements `Comparer`, and you have a large `[]Foo`. Then you'll first have to iterate over each element in `[]Foo` and add it to your `[]Comparer`, probably with an allocation per element. Then each invocation of `foo.Compare()` is going to be indirect as well (in other words, an interface lookup and a function call, i.e. no inlining). Mind you, this is still faster than many languages, but it's not the kind of performance people expect from Go.
From this description, I'm getting the impression that Go's interfaces are not as much like Java interfaces as I had assumed.
Never the less, I find that generics usually are just an over-engineered solution to any given problem.
Never the less, I find that generics usually are just an over-engineered solution to any given problem.
The primary differences (I think) are that everything in Java is already a pointer, so there isn't an extra alloc to make an interface. The same is true in Go if your comparables are all pointers. Probably the more significant difference is that Java has a JIT compiler, which may be able to inline all of those calls to Compare(). This is largely why Go's `sort` package abstracts over the collection, not over the element.
I don't see any reason why the interface lookup couldn't be done at compile time in this instance.
I don't think there is a technical reason. It's probably not something they'll do for a while because it probably requires some significant reorganization of the compiler and making a passably fast implementation is probably quite hard (the Go community places a premium on fast compiler times, rightly or wrongly). Also they seem to value predictable optimizations. Not sure how keen they would be to add an optimization that works until a seemingly inoccuous code change prevents the compiler from guaranteeing that all elements in the slice have the same concrete type, making performance (probably) significantly worse.
Again, I don't necessarily agree with the Go team; I'm just guessing the are some of the concerns they're weighing.
Again, I don't necessarily agree with the Go team; I'm just guessing the are some of the concerns they're weighing.
[deleted]
Ah I misunderstood the previous comment. Sure, if you have a list of pointers to values that satisfy a given interface, dispatching at compile time would not be trivial.
Apparently, the project leaders see it as a lower-priority (though not unimportant) issue. Looking at the adoption figures, they seem to be right.
I personally stay away from Go due to lack of generics and other expressiveness issues. People who have to work with it write code generators on top of the compiler, because the compiler team won't include it into the language. (I can see how it's not an easy thing to do; Russ Cox wrote a nice piece about it.)
Java prior to version 5 had the very same problem. It was wildly popular nevertheless. It took Java 8 years to gain support for generics, though, about as long as it took Go to not yet obtain them. (By that time, Java was widely considered the Cobol of 21st century; I think Go must be successfully stealing that crown now.)
I personally stay away from Go due to lack of generics and other expressiveness issues. People who have to work with it write code generators on top of the compiler, because the compiler team won't include it into the language. (I can see how it's not an easy thing to do; Russ Cox wrote a nice piece about it.)
Java prior to version 5 had the very same problem. It was wildly popular nevertheless. It took Java 8 years to gain support for generics, though, about as long as it took Go to not yet obtain them. (By that time, Java was widely considered the Cobol of 21st century; I think Go must be successfully stealing that crown now.)
> Looking at the adoption figures, they seem to be right.
Not really, for me Go is a bit like JavaScript.
I have to deal with Go thanks to Docker and K8s, doesn't mean I would use it when given the option.
Not really, for me Go is a bit like JavaScript.
I have to deal with Go thanks to Docker and K8s, doesn't mean I would use it when given the option.
Would you rather have them use C++? In this regard, Go is a lesser evil.
Yes, as long as it was modern C++, not C compiled with C++ compiler.
Or any modern natively compiled language.
Or any modern natively compiled language.
That's kind of part of the problem - with C++, or Java, or C#, you can write in 15 different styles, syntactically valid but quite possibly unreadable to another programmer who is experienced in the language. That's because there isn't one idiomatic standard for the code, there's 15++, and the language has the complexity that enabled that mess.
If you want to work in a kitchen sink language (and I often do haha), just use one of the many available.
But perhaps you're missing the value of simplicity? It is after all the main strength of Go, and a rare commodity in software engineering these days.
Overall I think it's a shame to have less choice, and we lose something by making all languages too similar (in both features, and at the meta level in complexity).
If you want to work in a kitchen sink language (and I often do haha), just use one of the many available.
But perhaps you're missing the value of simplicity? It is after all the main strength of Go, and a rare commodity in software engineering these days.
Overall I think it's a shame to have less choice, and we lose something by making all languages too similar (in both features, and at the meta level in complexity).
Or Rust, if you really really want to avoid C++.
My concern is less about writing a bunch of separate functions, but rather the way this hampers the abstractions that are available to you everywhere in the language. You don't have map or fold! And that's only the very tip of the iceberg.
Yeah, I wish go had more functional stuff, like .map(), .filter(), etc.
On the other hand I enjoy that when I pickup a package someone wrote there is not a bunch of different meta-programming using templates.
Generics sometimes lead people (including myself) to over-engineer solutions... usually because we want as much compile safety as possible. But at what cost in complexity.
On the other hand I enjoy that when I pickup a package someone wrote there is not a bunch of different meta-programming using templates.
Generics sometimes lead people (including myself) to over-engineer solutions... usually because we want as much compile safety as possible. But at what cost in complexity.
I'd rather read x.filter().map() than read the loops someone had to expand them into by hand.
I groan every time I have to implement the 15th type-specific loop implementation of what I'd do with a single map or fold in Ruby/Elm/Haskell/JS/TS/Crystal/every other language I use. It's not a lot of effort but it's a lot of mess and cruft.
Check out goderive
linking this for you: https://github.com/awalterschulze/goderive
i wish i could laugh, but i can't. the lengths people will go to work within such an impoverished language, and by means so antithetical to the go philosophy.
i wish i could laugh, but i can't. the lengths people will go to work within such an impoverished language, and by means so antithetical to the go philosophy.
"... trivial deployment, etc.)..."
Does this refer to static binaries?
What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them.
Were there many complaints about the absence of shared libraries originally?
Whenever I have mentioned the benefits of compiling C programs as static binaries and that in some cases with todays hardware one can have enough memory that shared libraries may not be necessary in order to conserve memory (one of the original goals of shared libraries), I have encountered substantial resistance to the idea. Perhaps some folks are interested in shared libraries for reasons other than memory conservation.
Does this refer to static binaries?
What amazes me most about Go is that they managed to successfully pitch a C-like systems language that does not promote use of shared libraries. About six years passed before they added an option to create them.
Were there many complaints about the absence of shared libraries originally?
Whenever I have mentioned the benefits of compiling C programs as static binaries and that in some cases with todays hardware one can have enough memory that shared libraries may not be necessary in order to conserve memory (one of the original goals of shared libraries), I have encountered substantial resistance to the idea. Perhaps some folks are interested in shared libraries for reasons other than memory conservation.
In my experience, shared libraries can simplify deployment as well; say you’ve got a 100 programs using the same library, and you need to change the implementation. With a shared library you only need to build and deploy one artifact, you don’t need to relink and redeploy 100 programs.
The deployment time benefits of static binaries far outweigh the resource saving benefits of dynamic linking. I'm speaking from experience with C++. There is also a latency boost for high CPU intensive processes.
Security: they need to be updated in one place instead a hundred different places.
The Go community mostly deploys network server daemons to its own datacenter infrastructure. C and systems programming in general also target end-user devices, where it isn't the programmer's memory to spend.
The open-source community already has a mature ecosystem for dealing with shared libraries via package managers and distro maintainers. In a company's proprietary backend it's almost certainly cheaper to throw memory at the problem than to spend engineer time crafting and maintaining a coherent/compatible set of packages for its various backend services.
The open-source community already has a mature ecosystem for dealing with shared libraries via package managers and distro maintainers. In a company's proprietary backend it's almost certainly cheaper to throw memory at the problem than to spend engineer time crafting and maintaining a coherent/compatible set of packages for its various backend services.
> while paying much less attention to the vocal minority's complaints
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.
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.
i don't think you can "catch up" with go, because it has aimed at being minimalist. catching up by removing major features to a language isn't something i've ever witnessed.
> because it has aimed at being minimalist.
You can absolutely catch up with the concurrency model, on the single binary deployment, and a other features. Go isn't "minimalist", that's false, go look at the reflect package, it's complex as hell.
You can absolutely catch up with the concurrency model, on the single binary deployment, and a other features. Go isn't "minimalist", that's false, go look at the reflect package, it's complex as hell.
I’ve used go for around 5 years on multiple large deploys without touching the reflect package. It is neither recommended nor necessary.
Go is radically minimalist compared to other languages - it leaves a lot out, most notably inheritance.
Go is radically minimalist compared to other languages - it leaves a lot out, most notably inheritance.
> ... while paying much less attention to the vocal minority's complaints (generics, package system, etc).
It is much more difficult not to add a feature than to add it, and the ability to reject even important feature requests is very important for the survival of a system in long term. This observation is formulated in "Getting Real" (https://gettingreal.37signals.com) as "Forget Feature Requests" and "Start With No".
It is much more difficult not to add a feature than to add it, and the ability to reject even important feature requests is very important for the survival of a system in long term. This observation is formulated in "Getting Real" (https://gettingreal.37signals.com) as "Forget Feature Requests" and "Start With No".
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.
because people at my company collect data on this.
Could you expand in this? Like, if there's somebody surveying what programmers want as a population, that's pretty cool.
https://blog.golang.org/survey2016-results
Note that generics is the highest requested change.
Note that generics is the highest requested change.
People want generics because they think every language should have generics.
What they don't know is the exact cases where the lack of generics causes a real-world problem for them. This is what the developers are requesting at the moment, in order to possibly bring generics to Go 2.
What they don't know is the exact cases where the lack of generics causes a real-world problem for them. This is what the developers are requesting at the moment, in order to possibly bring generics to Go 2.
Every statically-typed language needs generics to allow a function to be used with more than one type. Otherwise you throw away most of the type info and end up with the same problems dynamically-typed languages have.
The majority may want generics.
I don't know that the majority want generics at the expense of compile times or other possible tradeoffs.
I don't know that the majority want generics at the expense of compile times or other possible tradeoffs.
This is exactly my feeling. I don't want generics if I have to pay anything for them in build time, or if it limits go/ast or go/types. A lack of generics has been a pain point a couple of times in my current project (beyond what very simple code generators can provide), but crazy fast build times have been a massive benefit.
Imagine how much wailing and gnashing of teeth there will be if Go 2 delivers generics but with triple the build time and +50% binary size... if you thought the minority was vocal now, wait til you see that!
Imagine how much wailing and gnashing of teeth there will be if Go 2 delivers generics but with triple the build time and +50% binary size... if you thought the minority was vocal now, wait til you see that!
How would allocating resources to making a nice package mnger would have hindered Go popularity :)? Tacking it on postfactum is always a big pain.
go would be seen as a project of insanity if not been made by google; and would most likely be in a field of dead language husks
Like pretty much every successful programming language.
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.
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.
Another take, from the Bell Labs POV:
Go is an example of how to be extremely successful by inventing Unix and then going obscure for 30 years doing stuff like Inferno and Plan 9, and making a comeback when Google shows up.
Go is an example of how to be extremely successful by inventing Unix and then going obscure for 30 years doing stuff like Inferno and Plan 9, and making a comeback when Google shows up.
Go still lacks a few goodies from Limbo, like proper dynamic loading (only kind of working on Linux currently).
Maybe, but javascript is also extremely successful and quite opposite on many fronts.
How do you know that go would be less popular if it had generics and package system?
How do you know that go would be less popular if it had generics and package system?
Survivorship bias would explain this pretty succinctly.
Maybe, but even then at the end they decided to pay attention to this "vocal minority" and add go dep.
Go is woefully missing some really key features, which you encounter when tuning it for high performance. My list of grievances:
- Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works.
- Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered.
- No easy way to construct arenas/pools. Once you go down this route you have a great headache of releasing in the right places. The GC doesn't cut it, you need pools sometimes
- Debugging basically doesn't work on some OSes. No easy way to attach gdb and see what's happening. Doubly so if you use Cgo
- Similarly, Go doesnt bother to hide the differences of different OSes. Up to you as the programmer. Again not surprising for Google's all Linux world. If everything is Linux then OS difference doesnt matter. But even Python does a better job here.
- Logging is poorly thought out as evidenced by multitude of third-party log packages. Anemic compiler means you can't get verbose logging without paying a performance penalty.
- No RAII. Defers are a lazy attempt at this, but they're not even close to being as good as RAII. This is probably the biggest point where you realize Go can't dethrone C++
- Tricky Close() semantics force you to architect entire program around who will close() things at end of their lifetime. Lots of terrible hacks ensue when people build something that works but realize close ownership is ambiguous and rightfully don't want to rebuild it all
- Channels don't have a good way to deal with errors. You're forced to come up with an ad hoc solution to deal with your graph of goroutines/channels when one node errors
- No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it
- Hacky reflection semantics that cause subtle runtime bugs when a JSON struct field's name starts with a lowercase letter. And of course, there are no generics, the larger issue here.
I was hopeful that Go would fix some of these things before it went 1.0 and locked in its syntax. Sadly that didn't happen as it was likely already locked in at Google. Go is ultimately kind of brain dead, useful for some very particular features but not so compelling that it can replace any other language.
- Dep handling was never considered. Makes sense given Google's monorepo but thats not how the world works.
- Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered.
- No easy way to construct arenas/pools. Once you go down this route you have a great headache of releasing in the right places. The GC doesn't cut it, you need pools sometimes
- Debugging basically doesn't work on some OSes. No easy way to attach gdb and see what's happening. Doubly so if you use Cgo
- Similarly, Go doesnt bother to hide the differences of different OSes. Up to you as the programmer. Again not surprising for Google's all Linux world. If everything is Linux then OS difference doesnt matter. But even Python does a better job here.
- Logging is poorly thought out as evidenced by multitude of third-party log packages. Anemic compiler means you can't get verbose logging without paying a performance penalty.
- No RAII. Defers are a lazy attempt at this, but they're not even close to being as good as RAII. This is probably the biggest point where you realize Go can't dethrone C++
- Tricky Close() semantics force you to architect entire program around who will close() things at end of their lifetime. Lots of terrible hacks ensue when people build something that works but realize close ownership is ambiguous and rightfully don't want to rebuild it all
- Channels don't have a good way to deal with errors. You're forced to come up with an ad hoc solution to deal with your graph of goroutines/channels when one node errors
- No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it
- Hacky reflection semantics that cause subtle runtime bugs when a JSON struct field's name starts with a lowercase letter. And of course, there are no generics, the larger issue here.
I was hopeful that Go would fix some of these things before it went 1.0 and locked in its syntax. Sadly that didn't happen as it was likely already locked in at Google. Go is ultimately kind of brain dead, useful for some very particular features but not so compelling that it can replace any other language.
> - Stdlib just loosely wraps posix features with many C flags copied verbatim. These APIs are old and could use a refresh but Go never bothered.
> - Similarly, Go doesnt bother to hide the differences of different OSes.
I disagree with these. Go runtime/stdlib is architected to work around many many POSIX headaches and design bugs, hiding them completely from programmers, and to be fully portable. For instance:
* Concurrency is completely redesigned (goroutines). * Signal handling is redesigned and doesn't cause bugs when interacting with concurrency. * Forking/Exec'ing is redesigned not to cause fd leaks in subprocesses (all file descriptors are marked as O_CLOEXEC, in a race-free way), nor have races while interacting with concurrency * Sockets are exposed through a higher-level API (Dialer/Listener). * epoll is not exposed but transparently used by a single thread to handle all supported file descriptors without wasting OS threads, to improve performance
In fact, I think the only thing that is pretty much low-level is os.File and filesystem access in general, which tends to expose lower-level details.
I disagree with these. Go runtime/stdlib is architected to work around many many POSIX headaches and design bugs, hiding them completely from programmers, and to be fully portable. For instance:
* Concurrency is completely redesigned (goroutines). * Signal handling is redesigned and doesn't cause bugs when interacting with concurrency. * Forking/Exec'ing is redesigned not to cause fd leaks in subprocesses (all file descriptors are marked as O_CLOEXEC, in a race-free way), nor have races while interacting with concurrency * Sockets are exposed through a higher-level API (Dialer/Listener). * epoll is not exposed but transparently used by a single thread to handle all supported file descriptors without wasting OS threads, to improve performance
In fact, I think the only thing that is pretty much low-level is os.File and filesystem access in general, which tends to expose lower-level details.
Having experienced a situation where I had to call select() directly, I have to completely disagree. If you run into situations like this, you need the syscall escape hatch. It's really painful to get this working, and it interacts poorly with goroutines.
Sockets are actually another good example. If you need to tweak then at all, you get to use the same old horrendous POSIX names for everything. No name aliases?
Sockets are actually another good example. If you need to tweak then at all, you get to use the same old horrendous POSIX names for everything. No name aliases?
Why would you want a supervision tree?
This would suggest using an actor-like model, which is pretty senseless for single-machine usage. It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash".
I'm not sure, but I think this also ends up being good for modelling interactions with good performance, as you know where you do network calls, where you have reliability, and where you have instant local calls. Though not to say that Erlang applications aren't blazingly fast too.
This would suggest using an actor-like model, which is pretty senseless for single-machine usage. It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash".
I'm not sure, but I think this also ends up being good for modelling interactions with good performance, as you know where you do network calls, where you have reliability, and where you have instant local calls. Though not to say that Erlang applications aren't blazingly fast too.
Wow! My network daemon at work, written in Lua (which uses Lua coroutines for processing, which are similar enough to Go routines/channels for this comparison) has a supervision tree. It can log the unexpected death of Lua coroutines and keep going, which is nice for the unexpected bit of input [1]. It's also helpful when testing new code as unexpected errors are logged (stack dump, so the location of the crash is reported) in development/QA.
[1] Yeah yeah, all input should be well specified. Could you please inform the vendors that their programs are spewing unspecified crap at me? Thanks.
[1] Yeah yeah, all input should be well specified. Could you please inform the vendors that their programs are spewing unspecified crap at me? Thanks.
Go can do almost the exact same thing, in fact, it's baked into the stock http server library.
Idiomatic Erlang involves handling only errors that are expected (read: part of the program’s specification), and crashing on any other kind of error. This keeps the error handling out of the business logic and makes the app code simpler and more reliable.
For instance, you can’t forget to close a socket, release a lock, or log the actor state and stacktrace, since these things are handled by the VM and supervisors when an actor dies. These are nice properties to have even in a single-node system if you’re aiming for high reliability.
I do agree though that a supervision tree doesn’t make as much sense in Go, since the VM does not provide the cleanup guarantees and strong process isolation that make the Erlang model really workable.
For instance, you can’t forget to close a socket, release a lock, or log the actor state and stacktrace, since these things are handled by the VM and supervisors when an actor dies. These are nice properties to have even in a single-node system if you’re aiming for high reliability.
I do agree though that a supervision tree doesn’t make as much sense in Go, since the VM does not provide the cleanup guarantees and strong process isolation that make the Erlang model really workable.
> It's totally understandable for Erlang, where the VM spans multiple machines, so everything is unreliable, but in Go, I take it for granted, that my goroutines won't "just crash".
Supervision tree gives a structure to put whole subsystems somewhere, including their boot initialization and shutdown (not just restarting it at crash), allows to spawn workers while keeping usual logging/crash monitoring for free, gives a way to inspect the system at runtime (much easier debugging), and allows to run several different applications in the same VM space, which is a flexible way of combining code. I can, for instance, run a CouchDB instance with bolted on my own HTTP server that exposes monitoring data or an administrative interface. It cannot be done in Go (or any other language, barring maybe Lisps) without modifying source code.
And no, none of this "spans multiple machines", it all works and helps on just one single node. Maybe except for debugger, where you spawn a shell node from which you operate.
And yes, your goroutines will "just crash" in situations you haven't expected, as every non-trivial daemon experiences crashes on transient bugs. Though in Erlang transient bugs don't bring the whole daemon down. Saying `my goroutines won't "just crash"' means `my code and code I use as libraries doesn't have bugs, ever'.
Supervision tree gives a structure to put whole subsystems somewhere, including their boot initialization and shutdown (not just restarting it at crash), allows to spawn workers while keeping usual logging/crash monitoring for free, gives a way to inspect the system at runtime (much easier debugging), and allows to run several different applications in the same VM space, which is a flexible way of combining code. I can, for instance, run a CouchDB instance with bolted on my own HTTP server that exposes monitoring data or an administrative interface. It cannot be done in Go (or any other language, barring maybe Lisps) without modifying source code.
And no, none of this "spans multiple machines", it all works and helps on just one single node. Maybe except for debugger, where you spawn a shell node from which you operate.
And yes, your goroutines will "just crash" in situations you haven't expected, as every non-trivial daemon experiences crashes on transient bugs. Though in Erlang transient bugs don't bring the whole daemon down. Saying `my goroutines won't "just crash"' means `my code and code I use as libraries doesn't have bugs, ever'.
No, it's saying: if my goroutines crash it's the same as if my main thread crashed, which means: game over, application down.
Which gets handled by the container scheduler
Which gets handled by the container scheduler
So every unrelated request that happened to be currently processed is thrown
away because of a rare corner case, and with no way to intercept shutdown and
save state, flush buffers, or anything. Yes, totally right granulation.
Not to mention that you have just introduced a very complicated piece of software to run a single daemon.
Not to mention that you have just introduced a very complicated piece of software to run a single daemon.
Or, you just catch the panic in a defer up the call chain, log the error, and then exit that goroutine. Like: https://golang.org/src/net/http/server.go#L1694
I'm not disagreeing with you (I've previously criticized Go here) but I think it's helpful to think of Go as a more "modern" C. A lot of the warts you see here (Cludgey POSIX interfaces, no smart scheduling around channel error handling, bad reflection semantics, etc.) are the same as you'd find in C.
Except, it's not a compelling replacement of C. The type system doesn't give me good assurances about program behavior at compile time. Go inserts itself as a heavy unwanted additional layer for cases where I want C. Especially considering that now my program will have GC pauses.
> - No supervision tree. Erlang existed far before Go but they didn't learn from this key feature. But it would greatly enhance Go to have it
This is the one thing in your list that I don't recognise. What is a supervision tree? Can you (or another Erlang programmer) point to your favourite reference?
This is the one thing in your list that I don't recognise. What is a supervision tree? Can you (or another Erlang programmer) point to your favourite reference?
Here's the relevant chapter from Learn You Some Erlang
http://learnyousomeerlang.com/supervisors
http://learnyousomeerlang.com/supervisors
A supervision tree would be a tree of goroutines where a "master" (supervisor) gets notified when children die (normally and more importantly abnormally).
In Go, if a goroutine panics for some reason it just dies on its own and the world does not know unless you have some sort of ping service or you specifically send a notification from a defer.
In Erlang, if a process faults and it has a supervisor, the supervisor gets a message that one of its children died with some additional metadata, it can then log the issue, restart a child, … This also led to an interesting "let it crash" philosophy (since Erlang processes have isolated private heaps a process dying also cleans up any potential data corruption in the process's private state, this is often considered a feature, but at its core it mostly avoids processes dying unnoticed.
Incidentally, supervision is actually the result of two individual features: linking and trapping. Linking means that when one process dies with an abnormal status (any reason other than regular process exit), all process linked to it will also die (the EXIT signal gets propagated through the link), which is repeated until all linked processes are killed, trapping lets a process handle the incoming exit signal in code rather than automatically suicide
Finally, because supervisors and supervision trees are so common the Erlang standard library provides generic behaviours which let developers declaratively set up which strategies they want in their supervisor, the maximum restart frequency (beyond which the supervisor consider the system's broken and shuts down), ...
In Go, if a goroutine panics for some reason it just dies on its own and the world does not know unless you have some sort of ping service or you specifically send a notification from a defer.
In Erlang, if a process faults and it has a supervisor, the supervisor gets a message that one of its children died with some additional metadata, it can then log the issue, restart a child, … This also led to an interesting "let it crash" philosophy (since Erlang processes have isolated private heaps a process dying also cleans up any potential data corruption in the process's private state, this is often considered a feature, but at its core it mostly avoids processes dying unnoticed.
Incidentally, supervision is actually the result of two individual features: linking and trapping. Linking means that when one process dies with an abnormal status (any reason other than regular process exit), all process linked to it will also die (the EXIT signal gets propagated through the link), which is repeated until all linked processes are killed, trapping lets a process handle the incoming exit signal in code rather than automatically suicide
Finally, because supervisors and supervision trees are so common the Erlang standard library provides generic behaviours which let developers declaratively set up which strategies they want in their supervisor, the maximum restart frequency (beyond which the supervisor consider the system's broken and shuts down), ...
> In Go, if a goroutine panics for some reason it just dies on its own and the world does not know unless you have some sort of ping service
If a goroutine panics and is not recovered, it not only dies but tears down the whole process. This seems to be the more appropriate approach for a language with pervasive shared state (locks, etc.). Erlang is quite different here, as you say.
Restarting or otherwise dealing with the exiting process is best left to the service manager that started it.
If a goroutine panics and is not recovered, it not only dies but tears down the whole process. This seems to be the more appropriate approach for a language with pervasive shared state (locks, etc.). Erlang is quite different here, as you say.
Restarting or otherwise dealing with the exiting process is best left to the service manager that started it.
http://www.jerf.org/iri/post/2930 is a really nice blog post from an Erlang programmer attempting to bring supervisor trees to Go as https://github.com/thejerf/suture.
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) and (3). Had just woken up. No idea what I was thinking.
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) and (3). Had just woken up. No idea what I was thinking.
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."
and yet Pipenv is miles ahead of what Go has to offer.
Agreed on the packaging side, but the python community / existing libs (the entire rest of the ecosystem) is miles ahead of Go's at this point.
[deleted]
Bold choice.
I hear people praise the Java ecosystem so often, but when I use it I cannot replicate that.
There is nothing like Django in Java land? Instead you are sent into a confusing mess of interface standards like JPA and implementations (hibernate, ebeans, ...) and little guidance how to choose.
There is nothing like Django in Java land? Instead you are sent into a confusing mess of interface standards like JPA and implementations (hibernate, ebeans, ...) and little guidance how to choose.
Equivalent of Django would be something like Spring Boot, Play Framework etc.
It's quite common that some of these frameworks rely on community infrastructure that has several competing implementations, like JPA, but the point of a tool like Boot is that they picked all the implementations for you and documented it all centrally.
It's quite common that some of these frameworks rely on community infrastructure that has several competing implementations, like JPA, but the point of a tool like Boot is that they picked all the implementations for you and documented it all centrally.
We tried Play. It is not close to Django. At least with Java. It might be better if you use Scala.
For example, one thing which seems to be worse across the board is database evolutions. Django will autogenerate an evolution in Python for you [0] and if necessary you can adapt the code. In Java land you have to write SQL by hand [1] afaik? If SQL is not enough, I don't know what to do at all.
[0] https://docs.djangoproject.com/en/1.11/topics/migrations/ [1] https://www.playframework.com/documentation/2.6.x/Evolutions...
For example, one thing which seems to be worse across the board is database evolutions. Django will autogenerate an evolution in Python for you [0] and if necessary you can adapt the code. In Java land you have to write SQL by hand [1] afaik? If SQL is not enough, I don't know what to do at all.
[0] https://docs.djangoproject.com/en/1.11/topics/migrations/ [1] https://www.playframework.com/documentation/2.6.x/Evolutions...
Hibernate can do automatic migrations, but I think most complex deployments prefer to take direct control of the process.
Fair enough. I should have said one of the best. A bit of sensualism there.
Really love your language ;)
Sensationalism maybe?
Sensationalism maybe?
Yes, of course, thanks for correcting me!
WTF is wrong with me?? I should be banned from this forum for life!
WTF is wrong with me?? I should be banned from this forum for life!
> If Go had ADTs
In the process of hacking on my PureScript2Golang "transcompiler", I've realized that under the hood ADTs, also known as "tagged unions", will likely more often than not be represented exactly as just that: a "tag flag" and a data pointer. (Of course if all of an ADT's ctors are nullary, an enumish int will do the trick just as well --- I doubt this gains anything over interface{}-boxed 0-size struct type-defs though in reality.)
Now the natural "box"/container for this tag+content pattern in Go is the `interface{}` that can hold as 'content' any of your "constructors" (whether it be a struct or type-alias or prim type), plus your 'tag' pattern-matchings translate to Go's type-assertions. You see this also whenever ADTs are translated to JS or OOP languages, in some manner the "type" tag is carried along to be able to switch-case on.
Anyway, you can do poor-man's ADTs as per above today. The catch is that you get fewer compile-time checks (won't check for pattern exhaustiveness in your switch-cases, or illegal/impossible/invalid (as per your custom "dumb" ADT layouts) type assertions).
But anyone who's done some linked lists or devised parser ASTs in Go has written "ADTs" in this manner --- whether by intention or inadvertently =)
Personally, I don't care about Generics now that I'm aiming to generate low-level Go code for PureScript's parametric polymorphism and higher-kinded types system.. --- expressive beyond the old-school oop/imperative "generics" band-aid ;)
> That I can add interfaces implementations to structs I don’t own
Wait, did I miss out on some new feature only recently introduced? The way I parse your above statement, it sounds like you could define methods for receiver types imported from other packages, is that what you meant? Or did you simply have classical workarounds in mind, such as type-aliasing or set-the-"method"-as-a-struct's-func-typed-field?
In the process of hacking on my PureScript2Golang "transcompiler", I've realized that under the hood ADTs, also known as "tagged unions", will likely more often than not be represented exactly as just that: a "tag flag" and a data pointer. (Of course if all of an ADT's ctors are nullary, an enumish int will do the trick just as well --- I doubt this gains anything over interface{}-boxed 0-size struct type-defs though in reality.)
Now the natural "box"/container for this tag+content pattern in Go is the `interface{}` that can hold as 'content' any of your "constructors" (whether it be a struct or type-alias or prim type), plus your 'tag' pattern-matchings translate to Go's type-assertions. You see this also whenever ADTs are translated to JS or OOP languages, in some manner the "type" tag is carried along to be able to switch-case on.
Anyway, you can do poor-man's ADTs as per above today. The catch is that you get fewer compile-time checks (won't check for pattern exhaustiveness in your switch-cases, or illegal/impossible/invalid (as per your custom "dumb" ADT layouts) type assertions).
But anyone who's done some linked lists or devised parser ASTs in Go has written "ADTs" in this manner --- whether by intention or inadvertently =)
Personally, I don't care about Generics now that I'm aiming to generate low-level Go code for PureScript's parametric polymorphism and higher-kinded types system.. --- expressive beyond the old-school oop/imperative "generics" band-aid ;)
> That I can add interfaces implementations to structs I don’t own
Wait, did I miss out on some new feature only recently introduced? The way I parse your above statement, it sounds like you could define methods for receiver types imported from other packages, is that what you meant? Or did you simply have classical workarounds in mind, such as type-aliasing or set-the-"method"-as-a-struct's-func-typed-field?
Can you link to your project?
Current approach: http://github.com/metaleap/gonad-corefn (to be renamed later) --- heavily in-flux, even more slow-going pretty-soon-now (long-term freelance gig coming up), but I'm committed to keep committing =) --- won't be polished in terms of docs/tests/better-commit-msgs etc until reaching a certain stage of completeness. Also about 1/3rd of the code can be ditched at some point, coming from earlier stages --- only will become fully apparent which 1/3 at a later stage of maturity as well though.
Earlier first approach, won't currently compile due to deps: http://github.com/metaleap/gonad-coreimp
Auxiliary stuff currently dumped in: http://github.com/golamb
For a fun ps2go comparison, side-by-side:
https://github.com/golamb/test-pscorefn-src/tree/master/src/... <-> https://github.com/golamb/test-pscorefn2go/tree/master/Mini --- lots to-do still =)
Earlier first approach, won't currently compile due to deps: http://github.com/metaleap/gonad-coreimp
Auxiliary stuff currently dumped in: http://github.com/golamb
For a fun ps2go comparison, side-by-side:
https://github.com/golamb/test-pscorefn-src/tree/master/src/... <-> https://github.com/golamb/test-pscorefn2go/tree/master/Mini --- lots to-do still =)
What's the connection between `defer` and goroutines?
Not a strong connection, but both features are managed by the Go runtime.
Yeah, none. I wrote this while still in bed. No idea what I was thinking at the time :D
None, the feature that completely depends on defer is recovering from panics.
The order in which defer statements are executed is predictable, unlike goroutines.
The order in which defer statements are executed is predictable, unlike goroutines.
Novice here. Why is having no exceptions a good thing, in your opinion?
In Go’s philosophy most problems are not exceptional. File can’t be opened? This is to be expected on systems with file permissions. The common pattern is for functions to return an error type as last return argument (Go supports returning multiple arguments). Programmers can then handle the problem right then and there if the error is not nil. This approach also helps to keep control flow straight forward. The happy path flows from top to bottom. If an error occurs, it is typically handled in an if-block. There are no nested exception blocks or exception blocks that follow each other and do things far removed from the exception’s origin in the code. As a result Go code looks very clean and is easy to follow.
It's actually pretty common for a file exception to be exceptional.
In all programs I've ever worked on you don't want to have to check useless junk like that and just want the general exception handler to handle it.
In all programs I've ever worked on you don't want to have to check useless junk like that and just want the general exception handler to handle it.
This isn't true at all depending on your work. I program software that has to work alongside other programs on busy file systems...failing to read/write a file is not someone else's problem...it needs to be handled, logged, there is potentially a retry and/or notification.
For exceptional, unforeseen situations you do have exceptions, aka "panic".
For signaling error conditions that the caller has to expect and handle, you have the `result, err = func(...)` idiom, and a compiler that would warn you if you forget to use the value of `err`.
If Rob Pike's opinion on this is not enough, here's Martin Fowler saying essentially the same thing: https://martinfowler.com/articles/replaceThrowWithNotificati...
In general: http://wiki.c2.com/?DontUseExceptionsForFlowControl
For signaling error conditions that the caller has to expect and handle, you have the `result, err = func(...)` idiom, and a compiler that would warn you if you forget to use the value of `err`.
If Rob Pike's opinion on this is not enough, here's Martin Fowler saying essentially the same thing: https://martinfowler.com/articles/replaceThrowWithNotificati...
In general: http://wiki.c2.com/?DontUseExceptionsForFlowControl
Go does not warn you if you forget to handle an error. It only does so if the function in question also returned a value that you're using. There exist important functions that don't return non-error values and report errors that you very much would like to avoid dropping on the floor: os.Chdir() for example.
While this is technically true, I've considered `errcheck` to be standard tooling for what feels like forever now, and it does exactly this; make sure you're checking your errors.
I’ve read the first article. It was eye opening, cause I am writing a bot right now and using exceptions to control input flow. Made me think about my design.
That said, it does not argue against exceptions. So, I am not sure what your argument is.
That said, it does not argue against exceptions. So, I am not sure what your argument is.
Exceptions are bad outside the "your computer just started burning" cases, but Go has replaced them with something even worse, "multiple return values".
So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options:
And due to the lack of proper ADTs you can't even properly model "value OR error" manually.
So instead of some imagined return of "int or throw Exception" you now have "(int, error)", which basically means that the result of a function call can be any of these four options:
- ( value, no error)
- (no value, error)
- ( value, error)
- (no value, no error)
And due to the lack of proper ADTs you can't even properly model "value OR error" manually.
The last case is rarely seen in Go (at least not in the standard library).
Accepting for the moment that Go has no exceptions and and error returns are the way to go, the first two cases make sense.
The third case ( value, error) is actually useful in several scenarios. For instance, considering you're writing bytes to a stream that fail partway. The value is the number of bytes return so far and the error is the error that was encountered. In fact, this is the signature that the ubiquitous io.Writer's Write method uses.
If all you had was single return values (aka "int or throw Exception"), how would you model the io.Writer?
Accepting for the moment that Go has no exceptions and and error returns are the way to go, the first two cases make sense.
The third case ( value, error) is actually useful in several scenarios. For instance, considering you're writing bytes to a stream that fail partway. The value is the number of bytes return so far and the error is the error that was encountered. In fact, this is the signature that the ubiquitous io.Writer's Write method uses.
If all you had was single return values (aka "int or throw Exception"), how would you model the io.Writer?
> If all you had was single return values (aka "int or throw Exception"), how would you model the io.Writer?
This is not an problem, because a single return value is _not_ everything one has.
This is not an problem, because a single return value is _not_ everything one has.
The last two options are not idiomatic Go.
(zero, err) and (nonZero, nil) are.
So the error check is almost always a simple `if err != nil {return err}`.
> The last two options are not idiomatic Go.
Who are the authors of https://golang.org/pkg/io again?
Yeah, 90% of Go devs agree with you.
10% think it is a really great idea.
So you can never be sure without reading the documentation.
Who are the authors of https://golang.org/pkg/io again?
Yeah, 90% of Go devs agree with you.
10% think it is a really great idea.
So you can never be sure without reading the documentation.
Because it makes you handle errors by value, which makes you handle them one by one, and not group everything into one try statement.
This usually makes the error handling much better and better thought through.
You can see the same thing happening in all the functional languages using the Either monad instead of exceptions.
This usually makes the error handling much better and better thought through.
You can see the same thing happening in all the functional languages using the Either monad instead of exceptions.
Exceptions are one of those things which are really nifty when programming in the small. However, they can create outsize problems when programming in the large.
>Actually (5) is one of the few things I don’t like about Haskell.
Haskell has exceptions FYI
https://wiki.haskell.org/Exception
Haskell has exceptions FYI
https://wiki.haskell.org/Exception
Yes, that's what I say I don't like. Sorry for not making myself clear.
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 are basically back to just returning an error obj.
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 are basically back to just returning an error obj.
On the whole I agree that I prefer Go's explicit error returns over other languages implicit "alt-return paradigm" aka exceptions. But you're really well advised here to run a couple of linters occasionally that inform about ignored/unchecked/non-passed-on errors, it can happen all too easily while "rodeo-coding" prototypes/MVPs
I thought this as for a long time.
I have tried Go and worked with languages without exceptions in the past. The problem is the amount of error handling code I was writing time and time again. It might only be a case of returning an error but that is one more thing you need to think about instead of concentrating on the the domain.
Error handling in threads is a pain either way.
I have tried Go and worked with languages without exceptions in the past. The problem is the amount of error handling code I was writing time and time again. It might only be a case of returning an error but that is one more thing you need to think about instead of concentrating on the the domain.
Error handling in threads is a pain either way.
Lack of exceptions (in my code, but more importantly in library code) is one of the main reasons I use go.
[deleted]
Defer is not enabled by goroutines. C++ has `defer` as well, although it's called "destructors" there.
Heh, that is fun: the thing I hate about go is immature very varied stdlib quality, leading to even more varied ecosystem.
Rust seems on the right path, go ... well do you even have package management after 8 years? No..
What other systems do you compare it with? Its not the best I guarantee it...
Rust seems on the right path, go ... well do you even have package management after 8 years? No..
What other systems do you compare it with? Its not the best I guarantee it...
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` / `>>=`.
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.
I'm referring specifically to the error-handling situation.
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.
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.
Again, it doesn't seem like this is something that many communities do, in spite of having languages that support it. The '?' operators in the languages you cited, as far as I recall, are specific to null, and don't work on generic option types.
Go has (inferior) exceptions, they are called panics. error as value is not a feature of the language, it's a convention.
> 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).
> 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).
[deleted]
> every single cloud company has critical components of their cloud infrastructure implemented in Go
And this is how the "network effect" propagates. As the customers of cloud services also begin to experiment in Golang. And discover the holistic ecosystem of distributed systems packages.
Even Blizzard with its massive C++ codebase is gaining converts
https://youtu.be/Az5F4lwSljI?t=23m50s
And this is how the "network effect" propagates. As the customers of cloud services also begin to experiment in Golang. And discover the holistic ecosystem of distributed systems packages.
Even Blizzard with its massive C++ codebase is gaining converts
https://youtu.be/Az5F4lwSljI?t=23m50s
That source just mentioned a few popular open source projects and provided no sources citing actual cloud providers using it in their backend infrastructure.
Simplicity is the Ultimate form of sophistication -- Leonardo da Vinci
The quote fits perfectly for the design of go.
The quote fits perfectly for the design of go.
I think it fits better for Scheme or Forth. I would not describe Go as simple at all relative to those languages.
Like nil interfaces not being nil.
Or using characters from the Canadian Aboriginal Syllabics unicode block to emulate generics.
Or using characters from the Canadian Aboriginal Syllabics unicode block to emulate generics.
I agree with all of you, but when I compare go with C++/Java, go turns out to be very simple.
way to go, Go!
Just to accentuate some of the neat things you can do with Go, watch: 'Can you write an OS Kernel in Go?' from the Golang UK Conf. https://www.youtube.com/watch?v=8T3VxGrrJwc
Just to accentuate some of the neat things you can do with Go, watch: 'Can you write an OS Kernel in Go?' from the Golang UK Conf. https://www.youtube.com/watch?v=8T3VxGrrJwc
That was seriously impressive.
I find myself wondering how important the "fun facts" are in this fascinating thread about Go:
https://twitter.com/pasiphae_goals/status/923820615022399488
https://twitter.com/pasiphae_goals/status/923820615022399488
Some of those things are true and annoying, while others are exaggerations, and the rest are just wrong. That thread is poor taste.
They're not important. The author admitted she was just shitposting. It was an amusing thread, but rife with misinformation. If someone wanted valid criticisms of Go, I would not send them there.
A post earlier this year by Rob Pike, celebrating ten years of Go:
https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...
https://commandcenter.blogspot.com/2017/09/go-ten-years-and-...
I use golang since 2010. My only complaint is that they dropped gxui. So I use golang mainly for cli utilities. The other options (I do not like javascript) are ill-maintained. For me it is more important than generics.
eight years a-go? :)
For me Go is amazing, is my first language where I don't need a virtual machine or interpreter to compile to machine code, C++ is OK but not for day to day web.
Changing something then having to wait 40 seconds for java to recompile drive me crazy, also same for tests. Yes would love to have a package system, but is coming.
Changing something then having to wait 40 seconds for java to recompile drive me crazy, also same for tests. Yes would love to have a package system, but is coming.
Java has some flaws, but slow compilation is not one of them. Incremental compilers are available and pretty much eliminate pauses.
Really? I've recently been recruited to pitch in on a Java project, they're using maven, and the compiles sure aren't incremental.
What should we be using instead?
What should we be using instead?
Eclipse or IntelliJ IDEs will compile while you code (like C#). Depends on the project setup and dependencies. But I've found that this works for most development until I need to produce an artifact. Then I run maven which does a lot more than just compile code and usually is longer than 40s.
Yeah, having to run a whole IDE just to get incremental compilation is pretty annoying tho. Perhaps I should just bite the Java bullet and try to use IntelliJ.
You don't normally use Maven to compile every change when doing Java projects. Your IDE will incrementally compile what's needed based on importing the Maven config. You use Maven for tasks like packaging, linting, building JavaDocs etc.
Can you do something about Golang's performance on Arm servers? It seems to be terrible compared to x86 performance:
https://blog.cloudflare.com/arm-takes-wing/
This would have a positive impact on Google, too, as the more server chip competition there is, the cheaper it will be for Google to buy those chips for its cloud services.
https://blog.cloudflare.com/arm-takes-wing/
This would have a positive impact on Google, too, as the more server chip competition there is, the cheaper it will be for Google to buy those chips for its cloud services.
In honor of the exponential, I wish the conclusion was “Thank you, and here’s to sixteen more years!” :-)
Go's biggest issues still seems to be the lack of a standard mature dependency management system.
Could it be a strange mindset of our time that we look to language ecosystems to provide this? What if we could manage dependencies without being locked into language?
Conda goes some way. Think of something like virtualenv, but not specific to python. I would be happier with something that had fewer features than conda, but where critical features were easier. Example: setting up a package server should be trivial.
I think we do not yet have the git of dependency systems, with the gravity to draw in the community and for people to regard it a solved problem. Maybe the most efficient route would be: find a way to get Linus pissed off about it.
Conda goes some way. Think of something like virtualenv, but not specific to python. I would be happier with something that had fewer features than conda, but where critical features were easier. Example: setting up a package server should be trivial.
I think we do not yet have the git of dependency systems, with the gravity to draw in the community and for people to regard it a solved problem. Maybe the most efficient route would be: find a way to get Linus pissed off about it.
How about Nix, could it be the 'virtualenv, but not specific to python' you mentioned? I've never used it, but from what I understand that would be an appropriate description of Nix.
I don't know why people are so upset about this. Go standardizes enough things about imports and package structure that you can completely solve dependency management in literally a shell script: https://github.com/holocm/golangvend (I'm using this productively for the Go apps that I develop at work).
the issue becomes that there are so many solutions out there that going from project to project becomes a pain.
Large projects use a litany of different tools like glide, dep, godeps, vndr, govendor, etc. that managing all of them is a pain.
What makes it worse is that Golang's official solution seems half-baked when compared with other solutions out there.
Large projects use a litany of different tools like glide, dep, godeps, vndr, govendor, etc. that managing all of them is a pain.
What makes it worse is that Golang's official solution seems half-baked when compared with other solutions out there.
this is being addressed in dep, it's obviously not fully ready yet but works pretty well in my experience
https://github.com/golang/dep
https://github.com/golang/dep
Which is why I added the 'mature' qualifier.
Glide is great - it supported the most important feature I cared about, which was aliasing for forks where I had to fix bugs. "Standard" matters less because there's also no centrally-controlled repository of packages, unlike npm/maven/pip