For me the big takeaway is: generics are pretty much guaranteed to happen within a year or two.
> 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
That’s a bold statement...I’m not holding my breath. We still haven’t seen a solid proposal and the work required would likely be even more monumental after the fact.
Judging by package management, I wouldn't be surprised if it took another five years to figure out a plan and they did something controversially different from everyone else.
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.
I recall reading something from some of the language developers who had indicated that their worry with generics was whether they could do it right. I inferred that to mean, whether they could do it in a way that felt as simple as the rest of the language does.
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.
Tangential question: what was used to produce those charts? I love the simple formatting and how the data is laid out.
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.
I have a feeling a survey hosted by the language maintainers is going to be heavily skewed in favor of "used Go for a long time" and "prefer Go over other languages"
Those questions won't be representative of the whole population, but it's good to have a population of your users for things like this. I'm aware that Go is a good language, but I've never had a reason to use it and my opinion about other things related to Go shouldn't impact the development direction.
It absolutely does. This survey doesn't aim to answer, "what is the best language", it aims to understand how Go should improve and to gauge whether Go is improving. Specifically, comparing annual trends for the "prefers Go over other languages" question can help inform how Go is improving relative to its peers. Similar insights can be derived from annual trends in other questions' answers.
This is great for Go and I'm happy for them. I feel like in my career many people are extremely intimidated at the prospect of using Go for more than a pet project. The best answer I can manage to get to the question of "why?" is that it feels unfamiliar to them. I think this is an unfortunate hurdle.
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.
> I feel like in my career many people are extremely intimidated at the prospect of using Go for more than a pet project.
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.
I relate to both of you. Go is a tremendously easy language to learn in my experience, but my peers are so jaded by other languages' grandiose promises and subsequent failures that they refuse to even take the tour. This is especially true for my friends coming from Python and JS who associate "static typing" with C++, Java, Rust, or Haskell.
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.
Your first sentence confuses me. What issues did I cite? Why are you phrasing this as a rebuttal to my post when your content seems to not contradict at all?
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.
Without compile time introspection, those multiple transformation will always run slowly in go, though.
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.
Interesting, I thought it might be an SVG error but it appears fine in Chrome. The screenshot is from Firefox version 58.0.2 (64-bit) on macOS High Sierra 10.13.3.
At first I've avoided Go like the plague because it lacks generics.
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.
Ok so you can deliver projects. But what about the next guy that has to maintain them?
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.
Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written. It turns out that the verbosity of, for example, Go's error handling is actually simpler to understand and easier to read than any monadic contraption I've seen in the wild. It's also safer and lighter than Java's use of exceptions (checked or otherwise) because of the non-exceptional nature of equality comparisons and multi-valued returns.
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.
I think the argument that ‘Scala is over complex’ is not a compelling argument against the premise that ‘go is too simple’.
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.
> Frankly, I’ve seen as many golang error handling bugs in the wild as I ever did with java or c# style exceptions.
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.
If you want to provide more context to your caller, to enable a richer set of responses to this error, you can use more structure.
if err != nil {
return FunctionError{Original: err, ...}
}
That's really about it. Anything that tries to subvert the very simple/plain `if` checking, or tries to perform some kind of monadic error chaining, or builds an ersatz exception system with panic/recover, is what I mean when I talk about "obtuse, clever, or dumb things". The language and its idioms form these expectations.
This is in fact not idiomatic Go style. The Go error idiom is that errors are values, and that if you want cleaner error abstractions, you just program them yourself. People make trees of errors, or aggregate errors and check them once, or have error stacks.
"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.
And in doing that, you demonstrated that the idiomatic default in Go error handling is unhandleable errors, the sort that forces programmers to pitifully parse strings to differentiate.
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.
"Go's syntax and the patterns it encourages are both tailored to the harsh reality that code is read a lot more than it's written."
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".
If null pointers are your problem, Java and JavaScript are not the answer. If overall type safety is your problem, JS is definitely not the answer. If you don't like boilerplate and can accommodate dynamic typing, you can just use interface{} for the generic bits and statically type the other 95% (which is still a 95% improvement over JS--even better since Go catches impossible type assertion errors and gives better messaging for runtime type errors).
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).
I have been coding since 1986, of course I was able to ship software into production despite the lack of generics in the languages I was using.
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).
> 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