I like the fact that many people consider "reading source code" a way to get Go answers. Go code, the standard library in particular, is really readable.
This is absolutely true, the standard library is very easy to read and this makes using Go very pleasant. When you compare this with C and the libc, the contrast is striking.
At least complicated Scala code is very in-your-face about how complicated it is, as opposed to C.
The types also make it hard to change one small thing and make everything go wrong. Sure, the standard library source looks like a trainwreck, but it has structural strength. And it's easy to use.
I read go's stdlib implementation more than any other language I have ever worked with. The main reason? Because the implementation is just a click away when you are looking at godoc.
You can make a lot of critiques of the standard library documentation, but "rather thin" is certainly not among them. I don't think there's a more deeply-documented stdlib besides maybe Python.
Users are overwhelmingly happy with Go: they agree that they would recommend Go to others by a ratio of 19:1, that they’d prefer to use Go for their next project (14:1), and that Go is working well for their teams (18:1).
Hmm. That's some great results, but is that survey representative of Go users as a whole? The respondents are self-selected, right?
I can imagine such a survey is reliable for things like best/worst features, how the language is used and other things that probably aren't correlated with enthusiasm for the language. Simply asking people who already chose to do a survey whether they like the language or not seems kind of pointless: if they didn't they'd presumably not bother spending time to say they didn't.
It is however illuminating how many of Go's developers are attracted by simplicity. The top adjectives for "like most" are: simplicity, easy, concurrency, simple, fast.
So that's 3 of the top 5 things people name basically being "it is simple".
On the other hand, the top "improve the most" adjective is generics.
This appears to put Go in a somewhat awkward spot. There's clearly a large population of developers who have been left behind by static typing and its consequent complexity (generics in particular being a fertile source of confusing error messages in most languages), and Go caters to these people, hence its attraction to former dynamic language users.
But at the same time, people are saying they want more complexity in the form of generics. If Go were to add good generics would it really be any simpler than Java? I'd struggle to identify any major complexity gap between them after that, unless you consider OOP to be too complex (unlikely given the Python/JavaScript backgrounds of many Go users?).
I wonder if it's the same people giving the top answers. Are Go users split into those who are happy with its current level of complexity and others who chafe against it? If so, is it possible for them to satisfy both camps simultaneously?
This is an interesting idea, it is quite a heterogenous community, which means there are definitely different schools of thought coming from entirely different backgrounds. I'm quite happy with the slow progress/lack of changes, to me that's a feature.
But, also, number one liked issue: simplicity. The go team doesn't say they don't want generics, they say they haven't found a non-complicated way to implement generics.
There are just the N ways PL research has found for implementing generics. Either they implement them, and tackle the complication one of those N ways entails, or they don't.
Besides, has anyone seen much experiments, with actual coding or at least design, for finding this "non-complicated" way anyway? Not just some post once in a blue moon re-iterating the basic well known tradeoffs.
Yeah, I've read both -- and more. None of this is what I described: either actual code, even if in some experimental compiler branch/fork, or at least a concrete design.
Ian's just reiterates the various options (Rob Pike has already written similar things), and Russ Cox is just several vague ideas for future additions to the language.
So, Russ says it is Ok to have generics but there are higher priorities. The problem with this approach is that eventually when they will add generics, there will be whole ecosystem living without them, which means this ecosystem will need to be entirely reimplemented.
Yet millions of VB and C# users deal with them every day and seem to be doing fine. For a concept that's so old, it seems unlikely they're going to find some breakthrough either in implementation or language-simplicity.
Add invariant-only generic types (no subtyping relations between types with different type parameters) as a way to avoid 90% of casts. It doesn't get easier than this.
As for going further, I think covariance and contravariance, while conceptually simple, will always be too complicated to wrap your head around.
I think the future is invariant types + advanced generics functions. But research hasn't explored that direction yet. I might want to do that in the future.
If it's relevant to anyone's interest, feel free to contact me.
It's not possible to sum them. See the explanation of how to read the data under the "What do you like about Go?" results. In particular, "management" and "dependency" both include the "dependency management" counts, so including those in the sum double-counts responses that say "dependency management".
I ran the numbers just now, and 571 responses contain the (case-insensitive) text substring "package manage" or "dependenc", compared to 623 for substring "generic". These two topics are very clearly the top two. They're also both on my list for this year (research.swtch.com/go2017). It doesn't seem that important which one "won".
If you have suggestions for how to summarize free-response text in a way that lets the data speak rather than lend itself to cherry-picking, please let us know. I'm certainly open to improved analysis next time.
The interpretation of the open questions could definitely use some semantic analysis; I agree that it really does look like there's more frustration around packaging than generics, based on how they interpreted the results.
And one could say it was too early. Under the hood, generics are pretty bad in Java [0]. Type information is mostly lost; it's a compiler time only feature. They're much better implemented in C#, even if they look the same on the surface, probably because it came later and they took it seriously.
So I applaud the Go architects with being conservative about it. More languages should take their time thinking about implementing features, no matter how needed they seem to be initially. You only get one chance, and then if it's a bad choice you live with the consequences.
Just about every programming language expert I've seen who's talked about Java generics says Java did a better job than C#. In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes. Examples of runtimes that do not specialize or reify generics:
* JVM
* Haskell runtime
* ML family of languages
* Modula-3
* Ada
The problem with specialized generics in the runtime is that they bake the type system of the language into the runtime itself, making the runtime more difficult to work with. Type erasure, for instance, makes it much easier to implement alternative languages on the JVM such as JRuby, Clojure, Scala, or Kotlin, than on .NET.
As another example, C# in 4.0 added the concept of generic type variance, which is completely at odds with specialized generics. To implement this feature, the C# language designers had to modify the underlying runtime itself and add special bytecode instructions for the feature. The feature itself is also incompatible with specialized generics, so when you use it you silently lose specialization.
In contrast, thanks to type erasure, the Scala language designers could easily add the same feature on top of the JVM as-is without needing Oracle to add special bytecode instructions.
Specialization has advantages for performance when doing number crunching with data structures and algorithms operating directly on integral or floating point data types. At the end of the day, though, if you really need performance for this very narrow field of use cases, you're probably not going to be using generic data structures and algorithms anyways. It takes an incredible amount of effort to build a data structure or algorithm that is both generic and also performant in all possible usage scenarios. It is however, much easier to build a data structure or algorithm that is specific and performant relative to your use case alone.
Case in point: when I was in college doing a NLP assignment that needed to be fast, my data structures were arrays of doubles because that was the easiest way to reason about and ensure performance.
> In fact, of all language runtimes that do generics, the .NET runtime is the only one that specializes.
As a C++ programmer I would mention templates as something similar.
> The problem with specialized generics in the runtime is that they bake the type system of the language into the runtime itself, making the runtime more difficult to work with.
When inheritance comes in to play Java ends up storing generic type information in the child classes. It even has to generate bridge methods since Runtime does not really deal with int compareTo( Comparable<? extends T> ) vs. int compareTo ( MyInteger ) .
> if you really need performance for this very narrow field of use cases, you're probably not going to be using generic data structures and algorithms anyways
An ArrayList<Integer> makes sense in very few cases and is extremely slow, 64 bit pointers to objects that contain useless metadata and a immutable 32 bit int. Sadly an IntList is neither generic nor is it compatible with anything that operates on List<T>s, which results in duplication of a lot of algorithms just to sort primitives.
> when I was in college doing a NLP assignment that needed to be fast, my data structures were arrays of doubles because that was the easiest way to reason about and ensure performance.
Case in point: In C++ std::vector<double> and the standard algorithm header take care of most of that. If there is some specialized implementation of some algorithm for double values then you can still use that without copy pasting the implementation of everything else.
I purposely left out templates because I do not consider them to be the same as generics. Their is no "runtime" support for templates; templates are basically a glorified macro engine for creating new code based on type parameters. But yes, templates by definition specialize since they are creating new code every time they are instantiated.
At runtime any Java List is a list of Objects, you cannot distinguish an ArrayList<Integer> from an ArrayList<Double> both are a raw ArrayList. What runtime support do they have?
> I feel bad for the C++ linkers that have to sift through all the template bloat to dedupe them :(.
If you have a template used often enough you can declare it extern and force instanciation in a specific cpp file.
There actually is some basic runtime support for generics, just enough to avoid breaking the runtime. For instance, if I create a class MyList extends ArrayList<Double>, there actually is some runtime information that says MyList is an ArrayList<Double>, not just an ArrayList.
You're right though that saying templates are different from generics is based on opinion, not fact. There's no widely-accepted definition of both that would separate them as distinct from one another.
Generics just bake a little bit more into the runtime; there's already a lot of the type system there. And it increases interop potential. I don't understand your point about Scala - they could always choose to use type erasure instead of any runtime-provided generics. F# implemented generics with erasure on the 1.x CLR, and used the runtime when on CLR 2.
And this is the first time I've heard that the JVM is easier to target for non-Java languages. .NET has had multi-language support an official design goal, the JVM is just for Java. Even simple stuff like pointers, so you can do ref/out parameters. Or unverified instructions. The CLR is simply more all-around capable.
I am pretty sure the CLR always supported variance, it was just unused up until C# 4.0. AFAIK, there haven't been any changes to the runtime bytecode since CLR 2.0, when generics were added.
The performance benefits of specialization are pretty nifty. The Mono guys ported Android to C# and got quite the performance improvement on some code: https://blog.xamarin.com/android-in-c-sharp/ - so that's existing code that got a perf benefit "for free" due to not using type erasure.
Edit: A quick skim of the specialization proposal for Java[1] makes no mention of other languages. Just the general pain of integrating it in a compatible way.
Isn't that more a function of MS's hostility to other platforms, not technical reasons? If MS had been more open and friendly 15 years ago things might be different.
Here's a post from a JRuby developer saying he prefers a simpler VM.
In the comments section of the same post you'll see Martin Odersky, creator of Scala, saying he also prefers a simpler VM. I could probably find more examples if I dug further.
>I am pretty sure the CLR always supported variance, it was just unused up until C# 4.0
I can't speak about any of the programming language experts you've seen, but:
> To implement this feature, the C# language designers had to modify the underlying runtime itself and add special bytecode instructions for the feature
I think this argument is misconstrued. This is inherent to the way the CLR was designed. It is not meant to be something that is kept as-is in terms of the bytecode it accepts. It is constantly being improved upon. Most new language features to C#, F#, or other CLR languages mean an update to the CLR if they're related to a new feature in the abstract.
While there's an argument to be made on whether this better than a more generic runtime, the point is that requiring a change to the CLR is not a big deal; that's part of their plan.
It should be plain to see that it would be much easier to implement your programming language on top of the CLR or JVM if you didn't need to request new features from Oracle or Microsoft to be added to the runtime.
Which is why I've been very happy to see .Net Core take the path it has... it's been much more open to outside collaboration even if the bulk is done by MS employees.
Wasn't it too late? I thought the reason they went the type erasure path was because they didn't want to take the compat hit of changing the bytecode that much. Is that not accurate? Maybe if they had done generics originally it'd have been built in to the runtime. Isn't this potentially going to happen in Java10 or something?
So? Java doesn't have channels either (except in third party libs added much later), but they were in Go from the start. Same for e.g. plain structs, which Java will only now acquire.
When one language added a feature has no bearing to when another should add it.
FWIW Go is almost 8 years old now, and there is absolutely no plan to implement generics in anyway right now. I think they just can't without breaking backward and forward compatibility, they should just admit it instead of trying to avoid the question.
I'm a Go user, both at work and at home. My most-wanted feature is Generics, but I trust the Go core team when they say they want to ensure the feature is implemented correctly. The absolute last thing I want is for them to rush some half-assed implementation, which becomes semi-permanent because they can't fix it without breaking everyone's code.
Coding without generics turns out to have many advantages. Mostly code bases that need to evolve rapidly without getting locked in to abstractions that don't fit anymore. It certainly is a mindset shift, and may be better at scale, but it's also more tedious and sometimes you just want a freaking Foo<Bar>.
>Coding without generics turns out to have many advantages. Mostly code bases that need to evolve rapidly without getting locked in to abstractions that don't fit anymore.
How would Generics restrict you any more than the numerous variations on the same functions for different types (that you need today)?
Except if the alternative is using interface{} for everything, in which case, yes, Generics would be more restrictive.
Generics would make go code safer, less reliant on complicated tricks to circumvent language limitations and the need for reflection and ultimately make programs less brittle since it would reduce the amount of code needed for a task in general. The only valid argument against them is compilation speed but it hasn't been tried in real.
I'm not a Go programmer as I like my languages baroque, overcomplicated and with ridiculously overpowered generic systems [1], but there value in simplicity and maybe a macro system would be a better fit for go than fully featured generics.
If you are a C++ programmer then you know that the latest features that were added aim at making C++ programming simpler and easier. Adding something to a language to fix its flaws is not necessarily adding some complexity.
That they already have in the form of Go generate, although it brings me memories from MS-DOS Borland C++ before they implemented templates and used preprocessor macros.
A quick look shows that 'go generate' simply allows filtering a file through an external tool. This is a powerful feature but has great setup overhead. Something slightly more integrated with the language (as a distinct compiler pass but still part of the language), with the capability of defining macros inline (and being exportable), and AST based instead of string based would be better.
Users always like simplicity in everything. They want a big red button that does what they need. Which is why asking them about design is generally useless. They would choose simplicity every time.
There are, of course, some users, that can make substantial comments about design, but they cannot be represented in a survey.
so 84% don't want generics, right? :) I switched to Go from Python several years ago, I admit that I missed generics for the first several weeks but then just moved forward. Nowadays I don't really think I actually need them anymore.
Generics are a mechanism by which a statically-typed language can approach the generality of abstraction possible in a dynamically typed language while preserving static type safety, so even though Python doesn't have generics, one absolutely would have good cause to miss them going from Python to Go.
Because everyone of us that cares about generics uses languages that support them, and most likely a Go++ effort would be in vain, after all there are already a few Go preprocessors, which don't seem to be widely adopted.
Take a look at CLOS. It's for a dynamically-typed language, but the same principles could be used to provide for multi-methods in a statically-type language like Go.
With what money and whom to maintain the fork? The survey even shows that most go users never or rarely contribute the any open source go project (25% + 34% respectively). You'd need a solid corporate backing.
I have repeatedly thought about building a variant of Go that compiles down to Go and then gets compiled by the upstream compiler, mostly to add generics and autogenerate all these
if err != nil {
return nil, err
}
blocks. But it would most definitely be a pain in the ass to integrate this with the toolchain.
What I think is a bit remarkable is that it's not so much generics which are lacking, but syntactic abstraction. Folks focus on generics, but really the one thing Go is missing is the ability to extend the language as a programmer.
Just want to point out this is a terrific display of data. Easy to read, grasp and scan through. Much better than some so-called data visualizations that confuse rather than present and clarify.
good point. i brushed over this fact since the charts were not especially pretty, but your comment helped me focus on how they're inline with content you don't need to jump between graph and description. it reminds me of how sparklines[0] can be used to visualize data in line.
To be clear, the discussion of survey free-text answers is based on us (mainly Steve) reading all the text. The goal in the free-text presentations was to show raw data in a useful way for others to look for details.
As I noted in a comment elsewhere on this page, if you have suggestions for how to summarize free-response text in a way that lets the data speak rather than lend itself to cherry-picking, please let us know. I'm certainly open to improved analysis next time.
Everyone is talking about Generics but the thing that I found tiring in Go is having to do the "err != nil" thing all over the place (I admit that I spent couple of days learning Go so I'm not familiar with best practices/idioms in Go about error handling). Seems like the error handling in Go is another point the survey brought out:
> Other popular responses were GUIs, debugging, and error handling.
I really like the ease of defining Exceptions and just being able to "raise" them in Python - provides an easy early exit and the caller can handle them nicely in "except" clauses.
Interesting. I mentioned something I don't like, gave an example of what I like, some Go users in the survey have also mentioned their dissatisfaction with error handling and I got downvoted? Did I break any rules/etiquettes?
Instead of getting some abstract exception and stack trace over several pages, the error message is usually pretty specific. Yes, it forces to handle errors locally, but that is a good thing, because locally you know what can go wrong. Your user, who is going to be separated by several layers, won't know that and the specificity is a godsend to him.
One use case where this is a bit of an problem for me is with a user facing api. Say a web request calls a top level method/subroutine which calls more and so on. Now if there is an error in the the lower level subroutine and I wish to expose it to the user gracefully (say a json response), in Go, I need to handle it explicitly and pass it as part of my return statement (along with the actual results which may be empty/null due to the error). Doing this with each of the nested methods becomes tedious. Please correct me if I'm wrong about this understanding as my knowledge of Go is limited.
If I could raise an exception, taking example of Python, I can choose not to worry about handling it in the intermediate methods and it'll float right to the top level subroutine with error message etc and I can handle it there anyway I wish.
I've actually come to dislike it a bit more in the last few days when dealing with SQL statements. If you're not meticulously adding context to all errors at every part of the step, you end up with a result like
$ go build -o my-program .
$ ./my-program
error: SQL syntax error at column 9
$
Now have fun figuring out which of your dozens of db.Prepare() caused that. Of course, when you manually add context at every step of the error return chain, you can just as well show a stacktrace for the same amount of (if not more) information.
I guess many people don't have problem with the 'errors are values' concept, just would like to handle them with much less boilerplate: like in Rust or Haskell...
Yup, totally agreed. The specificity is great. I meant more around the actual syntax, which, as another comment mentioned, requires a lot of boilerplate.
Lots of great info here, thanks to the Go team and Steve Francia in particular for taking the time to compile all this data into something intelligible. Some interesting data about what improvements users would like:
What changes would most improve the Go documentation?
Collectively examples gets 26%
What Go libraries do you need that aren't available today?
Lots of demand for UI libraries and mobile support - both very hard to get right and would really require corporate backing. Sometimes I suspect large corporations (MS/Apple/Google) churn their OS APIs/languages simply to keep devs busy learning their one platform. This would be hard to do and hard to support long term.
What changes would improve Go most?
The G word comes first (not being worked on), and then package management (being worked on), also library discovery is highlighted as an issue. I'd prefer if they took a step back and prepared a Go 2.0 which removed some of the inevitable cruft (comments as directives, struct tags), and rethought some other features - mostly taking things out rather than adding things, though it would be nice also to see a solution to generics and better containers built-in.
And https://golangnews.com makes an entry in news sources, even if it is near the bottom :)
It'd be nice to see the raw data too (some of the data points require a bit of tidying up (mostly the write in responses for which 1-2 word breakdowns don't really help much and split up similar responses like example/more examples/examples/code examples/tutorials) and words like 'great' are not really helpful without context. Now that they have the data presumably they could merge some of those categories or if they released it others could look at this sort of thing for them.
I think I'm the only go user who doesn't like them :) IMO they mix up separate concerns, use an ad-hoc syntax and end up a mess in complex apps, it's like a whole other language stuffed into a string and defined by random lib authors. A field might have json, xml, db tags all in one string. But there's no chance they'll be removed.
I don't like them either, so you're not alone. Nor do I like comments as compiler directives. Go needs a proper attribute syntax that works with the package system (so attributes don't collide) and can be applied to everything, including struct fields.
I haven't used Go a lot (couple of hobby projects), but found package management to be pretty good. The only thing I could think of is the $GOROOT structure, is this it?
It's referring to being able to pin dependencies easily so that you have a stable set of dependencies which is defined. At present go get, while convenient, fetches from head, so things can break when you move computer for example and refetch dependencies, or a new team member comes on board, or if you have an open source project.
What package management? AFAIK, there is no package management at all in Go, unless you use a third-party tool for doing that. The only thing you can do is fetching the latest revision of some package.
Vendor has some very basic problems though, and honestly i think it's unusable due to that. It's a ticking time bomb, imo.
In short, types, especially interfaces in returns, are strictly bound to their location which might be a vendor. If two libraries are using vendors[1] then the types are inherently incompatible between the two libraries. My most common point of failure for this is running into Logging interfaces that return themselves. That interface is completely incompatible with the other package's vendored logger, and so you have to have two instances of a logger - one for each package.
[1]: (ie, they both have a main package and a library package, so they both have vendors). It's to the point where if you have a main and a library, like many repos, you should simply move the main to another repo entirely.. which sucks, imo.
Which is a poor solution since it involves checking all your dependencies into source control. There's no reason why you shouldn't be able to have a file that lists all your dependencies and versions and lets you pull them down on-demand.
If you can't build and deploy your own system without a piece of code, you should not be relying on the goodwill of any third party to keep it available for you with no SLA. A good build system is a deterministic function of its input (a commit from your repo) and can run offline.
It extremely hard to deduce anything from most of the data, especially the open handed questions.
Obviously despite what some people kept on suggesting for years on HN, the 2 main concerns regarding the language are 1 - dependency management and 2 - lack of generics.
The stat that jumped out at me the most, among respondents to the survey, twice as many identified as LGBTQ* as identified themselves as women. Self-identified women respondants to the survey rounded to 1%.
That's not what the question asks. It asks "do you identify as part of an under-represented group" with an option for "I identify as a woman".
That's not the same as a straight gender m/f question. I can imagine that some women felt they weren't under-represented and didn't primarily "identify as a woman" even if they were one. Consider the reverse question with s/woman/man/ - how many men would pick "I identify as a man" vs "I do not identify as part of an underrepresented group". It's a leading question. Bear in mind on that question the vast majority of respondents were just a shrug: either no response, explicitly saying they didn't want to answer, or not identifying as part of such a group.
I'm glad to see that 63% develop on Linux; IME there really is no substitute.
I think it's a real shame that vi, VSCode, Atom, IntelliJ & Sublime Text come in ahead of emacs — emacs & go-mode are a wonderful way to write Go, particularly if one's using projectile or spacemacs. It's really worth a shot!
I'm surprised how high/well JS and Python rank as secondary/preferred languages. I'm a fan of modern JS myself, but surprised to see this carry over into another environment considering how many outside the current JS culture tend to reject the changes as complexity.
I guess so... And as it seems at least to me, that most development these days has some sort of browser interface (not all software used, or even most, just that there are more developers working on something with a web front end) it shouldn't surprise me that much.
The GUI issue could be fixed once Go gets WASM support(along with DOM access). Developing entirely new GUI libs is quite laborious considering the expectations.
This is not true. No one says generics aren't required, and it's more about finding the implementation that makes sense for go. For at least a year several people on the Go team have acknowledged the demand for generics. Ian Lance-Taylor even added a doc to the go repo which summarised the entire discussion on the various possible implementations and their pros and cons. For instance, most of what's required could come from a nice implementation of macros.
As usual you, coldtea, have posted an uninformed, polarising comment with the intent to provoke. Not surprised.
That crosses into personal attack and so is not allowed here.
coldtea is a forceful arguer but stands out in my mind as one of the users who has done the most to improve the quality of their comments (and thus HN) over the years by becoming more civil and substantive. Admittedly Go+generics isn't likely to hit any peaks of either civility or substantiveness.
>This is not true. No one says generics aren't required
Actually many have maintained exactly that, here on HN. Do you want me to post excerpts of such comments?
Heck, from this very thread: "I admit that I missed generics for the first several weeks but then just moved forward. Nowadays I don't really think I actually need them anymore."
>For at least a year several people on the Go team have acknowledged the demand for generics. Ian Lance-Taylor even added a doc to the go repo which summarised the entire discussion on the various possible implementations and their pros and cons.
I've read the summary, and most of the related blog posts. It has been close to a decade of Golang now. At which point can no practical progress in an area finally be considered as a neglect of indifference? After 7-10 more years?
Besides, regarding the acknowledgement I've posted sometime ago that I consider the standard "Generics are difficult, we just want to make sure we create them perfect before we attempt at adding them" position of the team as a discussion-stopper more than anything else. Perhaps you have some reason why I should be disallowed to be of and express that opinion? Because you don't seem satisfied to point that you consider it wrong.
>As usual you, coldtea, have posted an uninformed, polarising comment with the intent to provoke. Not surprised.
My intent is to express my position on the issue. Which is more or less the same, all these years, and I'm not sure why you'd expect that it should change, or that people who disagree with you should just shut up or something.
It's been ~7 years, so there's still two more years before it reaches the amount of time it took Java to get generics.
I'm confident generics will come to Go (I sure hope so), but even if it doesn't, Go's impressive uptake shows that it's not something it desperately needs in order to be a successful language.
Impossible to answer, how much would uptake would C# have had without Microsoft behind it pushing it HARD (MUCH more than Google has promoted Go), how much would Swift have had without being pushed hard by Apple as the new native language to replace ObjectiveC etc ?
Are the Go devs finally starting to wake up to the realisation that maybe a better generics story, or less verbose and primitive error handling, is something people do, actually, want?
I get the impression the Go devs have been stoking the flames a bit by refusing to countenance the extension of the language even into areas where it was clearly lacking.
Every second comment in discussions on the matter on HN ever is about how "people don't want them" and how those asking for them haven't really used Go to see how it doesn't need them in practice, and other such inanities.
It can obviously be simultaneously true that people don't find themselves needing generics in practice, but still want them in the language. Also, there's nothing "inane" about that.
Well, from my outside perspective there are certainly "Lack of generics is a feature" and "Generics are a feature that has not yet arrived" camps.
Again from an outside perspective, it also seems that these camps talk about their viewpoints to outsiders more than to each other.
Personally, I always thought the reality is probably closer to "Not adding generics prematurely is a design feature, and it hasn't moved forward yet since the core team doesn't need it enough, and no proposal developed critical mass of community support to consider it appropriately vetted."
Discussing what you "need" isn't remotely interesting in the context of programming languages. You don't need anything more than assembly language to get anything done.
Redefining need as nice to have isn't interesting either. It should be possible for there to exist a set of features which are convenient if present, but the absence of which does not substantially impede the development of solutions.
You described a feature that good engineering practice says should be eliminated. Features have costs (the most significant of which IMO is learning an unfamiliar feature when you read other people's code), thus only features that allow better (less error prone, more maintainable, faster) implementation of applications should be included in any language.
Is the difference between "needs and wants" an engineering concept applicable to programming languages?
We're not talking about wanting the new iPhone or a Tesla here, it's about wanting something that simplifies code / improves the expressiveness of a language.
No, the inane part I was referring to was the often heard notion that those that want Generics are not really Go users, else they would have seen that they are not needed.
They're talking about them in the sense that they acknowledge the demand but still don't seriously pursue it. The constant answer of "well gee, we'd love to do generics but unfortunately there isn't a perfect solution that has zero tradeoffs, darn" isn't really "talking" so much as it's "dismissing".
Is there a way they can disagree with (presumably) you without being "dismissive", or to avoid that accusation do they simply need to implement some version of generics?
I have some sympathy here - generics is hard to get right, and language changes are forever. As a Go user, I have absolutely no problem with them taking their time on this and only introducing it (probably with Go 2) when it has been thoroughly thought through. There are workarounds (writing for specific types, go generate).
Generics have been around for decades. It seems very unlikely that Go will discover some entirely new way to implement them. They'll end up implementing them the same way they would have if they'd done it years ago. The tradeoffs are well known.
Well they're listening... at least in the next couple of versions there should be an official dependency manager coming out. IMHO it's meh. They need to get rid of the damn gopath.
Everyone involved in the technical decisionmaking agrees that, long term, the GOPATH will be deprecated and removed. The question is just about getting from here to there without fucking people's workflows too badly. It will probably be 2 or 3 more release cycles, at least, before that's a reality.
vendor still doesn't work if your project is outside of GOPATH. The only thing the vendor folder is doing right now is precedence. Dep, the pre-alpha tool that is lining up to be the official dependency manager still doesn't work outside the GOPATH, hopefully they change that. The only thing that Go 1.8 did was add a default to GOPATH to $HOME/go.
In my ideal world, I should be able to clone a go project anywhere on my system, fetch the dependencies from the internet, yes the internet, because its 2017. (if you're that concerned with security fine, include them in your repo) but I should be able to call go build in that directory wherever it is.
