Go 2017 Survey Results
blog.golang.org
blog.golang.org
> When asked about the biggest challenges to their own personal use of Go, users clearly conveyed that lack of dependency management and lack of generics were their two biggest issues, consistent with 2016. In 2017 we laid a foundation to be able to address these issues
> These two issues will continue to be a major focus of the project through 2018
Which isn't a bad thing, necessarily.
rsc has recently blogged in much detail about the package management situation, basing his work on existing solutions. He seems to specially eye rust's cargo. The blogs have been on HN several times.
https://news.ycombinator.com/item?id=16421966 https://news.ycombinator.com/item?id=16434973
I would guess generics, when it lands, would look syntactically similar to the way channel type declarations look; you can have "chan int", so perhaps you would have "vector int". That feels the most intuitive and Go-ish to me. Channels require special syntax to work with, but with generics, I imagine you'd want to make use of interfaces.
I can see a bunch of ways of doing it—but none I could guarantee would end up in the finished product! But I do think generics land at some point. The unfortunate thing is there's a sense going around that Go doesn't have generics because the language authors somehow know better than everyone else; if anything, I think they have an abundance of caution that some other language developers have lacked.
My company* uses ggplot exclusively for reports that don't look nearly this well done. I love the information density, love the use of colors, love everything about them!
Based on my inspection of the source, these are "native html" charts in the sense that it's a mix of text and svg rect elements — not an "image" that is included.
Does anyone know how these are produced? I would love to shamelessly imitate if possible.
*tiny market research firm
The reply was discouraging in one sense and encouraging in another:
https://twitter.com/spf13/status/968259340619698176
"Custom Go application that parses the raw XML data from Qualtrics and the generates the SVGs"
(No disagreement on the second though...)
Hopefully that is just how things are in my little bubble (as this survey would indicate). I think Go is really cool and I will continue to lobby to implement some mission-critical systems with it.
That has not been my experience. Go is a learner friendly language with plenty of introductions and great, clean examples. If one has a basic familiarity with other languages learning Go is just as easy (or easier) than learning kotlin (python, tcl, java, c#, ...).
For me a bigger hurdle is the lack of some features: no generics is a pain. I would love to use Go for scientific computing, but libraries are not there yet. Writing my own I really miss operator overloading: operator and matrix/function algebras are the only areas where I miss this, but there I miss it badly -- (AB + BA)^2 is so much cleaner than Power(Add(Mult(A, B), Mult(B, A), 2). Writing a simple Kalman gain formula becomes an involved magic incantation.
Just a personal data point.
So it is both easy to learn and intimidating.
To be fair, the issues that you've cited don't seem specific to Go. Static typing is actually being adopted in both Python and JavaScript (via TypeScript), so people who keep up with the trends in those languages now have relevant examples of it.
In any case, it is good to see static typing support among dynamic languages. Hopefully that will help more people try Go. I have yet to find another programming language that makes application development so holistically easy.
C++ solves that with expression templates, which compiles something like ABC from the two step
tmp = AB Result = tmp*C
To the transformation in one traversal. D is also capable of those types of compile time expression evaluation, and is a nice language, but sadly doesn't have a huge following yet.
"""
I've used Go for: (single choice)
- 686 (11%) Less than 3 months
- 1,588 (26%) 3 - 12 months
- 1,338 (21%) 13 - 24 months
- 1,678 (27%) 2 - 4 years
- 809 (13%) 4+ years
- 102 (2%) I've never used Go
- 25 (0%) No response
"""
a- Generics
b- True, elegant exception handling
c- Built-in metaprogramming, not that "Go Generate" joke.
Nice to have: Sum types.
Nice to have: Shorthand for interface{}.
Nice to have: Package manager that does not depend on Git as first-choice of package repository.
Alternatively (c) can sort-of replace (a) as well.
A couple of years ago, I happened to pick up Go for a work project, and managed to ship it despite the lack of generics in Go. I realized that this was some of the most fun work I've ever done because of Go's various properties. I decided to take what is given and kept Go-ing. (Pun intended...)
Having just passed my 2nd anniversary as a Gopher (a Gopherversary?) I still manage to ship projects despite Go's glaring lack of generics.
Based on my own personal experience I can thus conclude that the non/availability of generics has very little to do with how strongly a programming language enables engineers to deliver projects.
At my work, we use Go extensively on the backend. Yes, it’s capable of being used by engineers to ship projects - most languages are capable of that.
But I do know we write a lot of boilerplate, and repeat ourselves all the time. We still see nil pointers occasionally (in 2018! Why are they still a thing). Even though I work with a bunch of smart engineers, the language has pressured us to write more code than we need to, which means more maintenance will be required in the future. After having worked with it for 2+ years, I wish we had just used Java or even JavaScript.
Lastly, the idea that generics somehow remove the pain of null pointers is simply false. I've done 8 years of Scala before defecting to Go, and still have nightmares about an empty Option[T] that has caused some n-level-deep monadic computation to return nothing. In this case, Go would at least blow up with a helpful stack trace, while the Scala program would continue to run and return erroneous results.
Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions. Don’t get me started on the golang generics & concurrency problems.
I continue to use golang in spite of their language decisions around these items, not because of them.
This has not been my experience. Idiomatic Go -- that is, not trying to do obtuse, clever, or dumb things to avoid error handling -- results in very clean and error-free code by default. I see unexpected runtime errors maybe a few times a year. I haven't seen unexpected panics in years.
In Go there is typically a very restricted set of ways to idiomatically accomplish a given task, often only one. Error management is a prime example.
result, err := function()
if err == ErrTryAgain {
continue
}
if err != nil {
return fmt.Errorf("function failed: %v", err)
}
if err != nil {
return FunctionError{Original: err, ...}
}
"continue" doesn't recover from an error, obviously. It is not hard to find screwups in error recovery code in Go.
Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the major Go error handling warts. Since you (like everyone else) didn't create an error variable or type to capture any of the meaning of the error, what you've created is a by-design unrecoverable error, one where your only hope of responding in any way other than aborting the entire operation is to parse the string error message, which is something more than one Go program has had to do.
I don't think this is a very strong rebuttal to "Go error handling kind of sucks".
This is absolutely idiomatic, with progressively increasing levels of opt-in expressivity. "If you want [additional] error abstractions, you just program them yourself" was clearly demonstrated: my "tree" of error-chaining was only one level deep (FunctionError), but that's a nit.
> "continue" doesn't recover from an error, obviously.
ErrTryAgain clearly carries semantic meaning that "continue" acts upon.
> Your "fmt.Errorf" "idiom" (it unfortunately really is one) is one of the major Go error handling warts. Since you (like everyone else) didn't create an error variable or type to capture any of the meaning of the error, what you've created is a by-design unrecoverable error, one where your only hope of responding in any way other than aborting the entire operation is to parse the string error message, which is something more than one Go program has had to do.
I demonstrated an alternative for situations when clients might want to parse and act on errors.
I kind of love Go. I'm a former professional C programmer and Go is now my default language. But I don't feel a need to kid people about things Go gets wrong.
var ErrTryAgain = errors.New("...")
type RetryError struct { ... }
You're acting as if this is some critical flaw in the language. It's nothing like that.
Yes, it honestly sounds like a taste issue. Go has it's own patterns, so if you instinctively expect your code to be like another language, it will probably feel wrong. I suspect that it is at the root of a lot of the comments about generics: people aren't comfortable with the style of Go, but aren't sure why, so they latch on to "generics".
Code also needs to be written quickly and cleanly so it can be augmented later. I don't think Go contributes in this regard.
Generics would be an improvement to Go for sure, but Go is still one of the best overall application development languages available today (greenfield or maintenance mode).
Even Oberon, one of my favourite languages and influence to Go, which I had the pleasure to spend one year using during the mid-90's lacks generics.
That doesn't mean in 2018 I should be happy when forced to use a language whose concept of generics is to manually generate code like we used to do on those days (//go:generate).