Go Developer Survey 2019 Results(blog.golang.org)
blog.golang.org
Go Developer Survey 2019 Results
https://blog.golang.org/survey2019-results
124 comments
I've been a Go programmer for many years, and I like the language and the community, but I have not found it to be uniformly welcoming. "Aggressively pedantic" is a good way to put it.
I have been to 4 Go conferences (two gophercons). Despite being first generation mediterranean-descent (my father is the exact immigrant story touted in many circles), because I fit the 'white christian male' bill, I have felt anything but welcome in the Go community. Actually, many times, I feel like it is actively hostile towards me. I remember one of the closing keynotes, a man stood up on the stage and said "Come take a picture with me out back if you look like me, you know who you are" which left me with my jaw dropped.
Not looking to put a bunch of negative energy out about it, but I know what you mean and you're right.
I am missing something. Do you mean you feel there is a hostility toward those who fit the "white christian male" bill?
I think he means the opposite, which is that he fits the "white christian male" and feels that there is hostility towards towards people who fit the "white christian male" bill.
To the contrary, I am usually assumed to be middle eastern (egyptian, oddly enough, although it may not be that surprising considering the hellenistic period and where my relatives are from) and despite being Christian, I am not one of the accepted mainstream forms of Christianity in the US, so I face double prejudice, on the one side from those who think Christianity is the cause of all the worlds problems, on the other side from other Evangelical types who think we are idol worshipping heretics. It is only when I correct people, that I get the "oh" reply, usually in disappointment that now I don't qualify for one of their acceptable groups of people who experienced prejudice or a lack of acceptance.
I've been to 2 Go conferences myself, and had an absolutely fantastic time. Great people all-around.
But ... the online experience here is a bit different from the conference experience.
But ... the online experience here is a bit different from the conference experience.
(I meant nothing like what the other replies to this comment said.)
Re: point 3 the "go" tag on Stack Overflow is the worst one I know. Some very nice and helpful people, and some ... people who just love to nitpick Every. Single. Mistake. Loads of questions in the go tag getting downvoted and closed just because of that :-/
Even as someone who mostly answers questions it's frustrating.
Even as someone who mostly answers questions it's frustrating.
That’s my experience with StackOverflow in general.
It really buggers me that Go had no modules for such a long time.
The first commercial project in our company was done with the stupid old gopath system. Builds broke all the time due to version problems.
It was atrocious and made me never consider Go again. However the module system came along shortly after and while being kind of crappy, compared to systems like the one in Rust, it gets the job done.
We have no Go projects without modules now. This was just a bad experience and i have no idea why a module system was not included in the beginning.
Good tooling should be a first class citizen in every good programming language and library management is part of that.
The first commercial project in our company was done with the stupid old gopath system. Builds broke all the time due to version problems.
It was atrocious and made me never consider Go again. However the module system came along shortly after and while being kind of crappy, compared to systems like the one in Rust, it gets the job done.
We have no Go projects without modules now. This was just a bad experience and i have no idea why a module system was not included in the beginning.
Good tooling should be a first class citizen in every good programming language and library management is part of that.
> i have no idea why a module system was not included in the beginning.
Because Google internally has a monorepo. $GOPATH works great when it contains just one repo.
Because Google internally has a monorepo. $GOPATH works great when it contains just one repo.
I'm really hoping that gopls gets to 1.0 soon. I feel like gopls is the elephant in the room that's taking a lot of air from some of the smaller tools, and I'm glad it's being called out as a priority in this report.
I've been following it since the first public release. It's still, unfortunately, very buggy.
I restart gopls perhaps 20-30 times a day, working in VSCode. I have to restart it every time I switch git branches or do other major file changes that completely break its mind.
I try to report every bug I find, but bug-reporting is even more of a productivity killer than the bugs. It's often difficult to reproduce exactly when they depend on an exact order of events.
Sometimes it's just seems infuriatingly like incompetence. After struggling for hours with gopls suddenly going insane the other day (i.e. even a restart wouldn't fix things), I realized gopls doesn't understand build tags, and will just fail in random ways on code that has a "// +build" comment. The gopls team knows perfectly well tags are not supported, but instead of warning you when you open the file, which would be the sensible option, they just let gopls mismanage it.
I really hope gopls reaches maturity soon, or I'll have to consider GoLand instead, which seems to have gotten this right.
I restart gopls perhaps 20-30 times a day, working in VSCode. I have to restart it every time I switch git branches or do other major file changes that completely break its mind.
I try to report every bug I find, but bug-reporting is even more of a productivity killer than the bugs. It's often difficult to reproduce exactly when they depend on an exact order of events.
Sometimes it's just seems infuriatingly like incompetence. After struggling for hours with gopls suddenly going insane the other day (i.e. even a restart wouldn't fix things), I realized gopls doesn't understand build tags, and will just fail in random ways on code that has a "// +build" comment. The gopls team knows perfectly well tags are not supported, but instead of warning you when you open the file, which would be the sensible option, they just let gopls mismanage it.
I really hope gopls reaches maturity soon, or I'll have to consider GoLand instead, which seems to have gotten this right.
It has gotten more fixes in the last couple of releases. I now in situation where it works in vscode as it used to with gopath. But yeah that was very painful
Between languages like Go, Rust, Swift, and others I feel pretty optimistic about these new players (and I very much prefer more language diversity).
No surprise to see generics being so strongly pined for again. Very curious about how Go getting generics will change its position in the landscape.
No surprise to see generics being so strongly pined for again. Very curious about how Go getting generics will change its position in the landscape.
If Go ends up getting generics it will be a serious competitor to Java in the enterprise small-medium size application space, and perhaps make it viable for larger applications.
So I think it will be a huge step up for Go. This is of course if they do it in such a way that does not increase language complexity by an order of magnitude (e.g C++ style templates). I think Java style generics is not as complex and something along those lines would be a huge win IMO.
So I think it will be a huge step up for Go. This is of course if they do it in such a way that does not increase language complexity by an order of magnitude (e.g C++ style templates). I think Java style generics is not as complex and something along those lines would be a huge win IMO.
I'm probably not representative, but when I last really tried to use Go on a project seriously the lack of generics and the way that errors were handled became a real blocker for me. Which is unfortunate, because I really wanted to like the language and did for the most part. But those two things made development feel like a real chore.
Again, I don't expect my personal preferences to dictate language development. Clearly many do not feel the way I do, but I do find it telling that those were the top two complaints. The pain is real, at least to a subset of us.
Again, I don't expect my personal preferences to dictate language development. Clearly many do not feel the way I do, but I do find it telling that those were the top two complaints. The pain is real, at least to a subset of us.
I hear complaints like this sometimes but I don’t relate. I don’t know if my style of programming is simply less abstract than others or if I just learned how to write (typesafe) abstract code without depending heavily on genetics. Note that there are still times where I can’t get the abstraction I want in a typesafe way, but these cases have been rare for me.
I feel it really boils down to the preferences and approach to the programming. My preference is C# and having no generics and exceptions irritates me quite a bit. (among with unused import/variable and styling being enforced.)
One aspect may be tools, too. Generics works great when things like contextual code completion (e.g. Intellisense) is present. One might see a bit of gaps, where someone's coming from C# on Visual Studio, compared to someone doing the same on a simple text editor. For this, I wonder if there's some correlation to preferred development environment, too. (IDE vs. editor, for instance.)
One aspect may be tools, too. Generics works great when things like contextual code completion (e.g. Intellisense) is present. One might see a bit of gaps, where someone's coming from C# on Visual Studio, compared to someone doing the same on a simple text editor. For this, I wonder if there's some correlation to preferred development environment, too. (IDE vs. editor, for instance.)
> I feel it really boils down to the preferences and approach to the programming.
That's it right there! With Go you have to get over this idea that _your_ preference has any place in Go code. Go was designed to be inflexible in style and immune to preference from the start. For those new to Go, if they can't get over that hump then it's really hard not to be frustrated with the language.
That's it right there! With Go you have to get over this idea that _your_ preference has any place in Go code. Go was designed to be inflexible in style and immune to preference from the start. For those new to Go, if they can't get over that hump then it's really hard not to be frustrated with the language.
I think this is where like/dislike is polarized.
Some may see the language being way too opinionated for that aspect, while some may be fine. (Also if such style is already aligned with their own established preference.)
I myself prefer less opinionated languages. As a professional, if someone presents me with a Go code, I will of course work with one, but it definitely won't be my go to language.
Some may see the language being way too opinionated for that aspect, while some may be fine. (Also if such style is already aligned with their own established preference.)
I myself prefer less opinionated languages. As a professional, if someone presents me with a Go code, I will of course work with one, but it definitely won't be my go to language.
As a Java developer I would need a few things to switch and maintain my current level of productivity: generics, a map/filter/reduce paradigm for working on collections, and more flexible error handling -- in that order.
Oh, and let me leave "fmt" in the list of imports even when it's unused, because adding it every time I stick in a printf to debug something, and then needing to remove it later because of compiler errors, is incredibly frustrating.
Oh, and let me leave "fmt" in the list of imports even when it's unused, because adding it every time I stick in a printf to debug something, and then needing to remove it later because of compiler errors, is incredibly frustrating.
Integrate `goimports` into your editor.
It's been an unpopular opinion but I've contended for a long time that if Go had map/filter/reduce from the onset like it has copy and append, most people screaming for generics would have been silenced.
But doesn't that require some level of generics? This is an honest question not rhetorical / a retort.
Go has several generic functions like append() or make() baked into the compiler (https://golang.org/pkg/builtin/). When people are asking for generics, they're asking for a language-level mechanism for defining additional generic functions beyond these provided by the compiler.
I'm talking more along the line for Map/Filter/Reduce support and why those weren't included in Go originally.
Yes. The distinction is that there are two ways to implement map/filter/reduce: either as additional built-in functions or in std. Only the second way requires language-level generics support.
Java is moving to complicated generics though, see project Valhalla, although not like C++ templates, but more about specialization for primitive types, which can be a huge performance win.
More complicated for the JVM to implement, sure, but if anything, won't this simplify the semantics? Users don't need to worry about boxing/unboxing values.
I am eagerly waiting for this to land, but it will complicate both JVM implementation and user programms, since now List<int> might be a separate class,
Interesting, I haven't heard of Valhalla (I haven't really used Java since around 2014). From their landing page it seems like their priorities are value types (which Go already has - you need to specify pointer types explicitly) and support value types as generic type parameters, which Go has to do, because it has value types.
I guess it will complicate things a bit, you're right. I'm pretty happy I don't have to use Java anymore though :)
I guess it will complicate things a bit, you're right. I'm pretty happy I don't have to use Java anymore though :)
An eco-system is much more than a language grammar.
Until Go comes with an OS, a set of drivers comparable to JDBC for Oracle, SQL Server, DB2, Informix, CMS tooling like Magnolia/Liferay, profilers like VisualVM/JFR, graphical debuggers (delve just barely does it), code reloading, dynamically loading, an UI toolkit that at least matches Swing, and plenty of other stuff, I rather leave it to Docker/K8S tooling.
Until Go comes with an OS, a set of drivers comparable to JDBC for Oracle, SQL Server, DB2, Informix, CMS tooling like Magnolia/Liferay, profilers like VisualVM/JFR, graphical debuggers (delve just barely does it), code reloading, dynamically loading, an UI toolkit that at least matches Swing, and plenty of other stuff, I rather leave it to Docker/K8S tooling.
What if "huge applications" is a bad pattern and Go is pushing forward in the right direction? :)
I don't even know what this means. Are you arguing for doing less or breaking up a task into components like with microservices? If the latter, all you've done is changed the scope of the application (now your application is made of multiple services not one), not it's size. If the first ... not all problems are small.
golang has got nothing on Java's (and the JVM's) performance, monitoring, profiling, GCs, etc. Not to mention all the new features Java is getting which are not even on golang's roadmap, such as records and pattern matching. This is not even touching on golang's bad design decisions that won't get fixed (e.g. structural typing of interfaces).
And when Java gets Project Loom then Go will not have any real world advantages.
If only the JVM could get it's memory usage down.
I think that >75% of people who complain about Java's memory usage don't provide a heap size and use the default, which is asking Java to go ahead and take up up to 25% of RAM whether it really needs to or not. You want to use less RAM? Tell Java to use less RAM.
And even then, many are just doing bad stuff like using new in loops, iterators in hot loops, and most relevant not actually thinking about their data structures.
Iterators and other allocations in hot loops are not universally harmful to performance and footprint. Very often they are scalar-replaced (allocated on the stack and reused)-- in fact, if they don't escape, they're almost certain to be. Escape analysis is also now significantly stronger and able to see through abstraction in JDK 14 thanks to increasing the default inlining depth from 9 to 15 (https://bugs.openjdk.java.net/browse/JDK-8234863).
Agreed, but it depends very much on which JVM one is using, and not all of them offer the same capabilities as Hotspot.
And then there is that other special flavour of coffee beans out there.
And then there is that other special flavour of coffee beans out there.
Pron while I usually agree with you when it comes to criticisms about Java I just can't here. Using 25% of available ram is just not a sane default.
Because it is too high or too low? What would be a sane default? Note that native applications don't have an upper limit at all, but to Java's GCs will be happy to trade available memory for performance.
Goroutines are very, very low on my list of reasons that I prefer Go over Java. I think many people misunderstand the value proposition of Go.
What are the top reasons?
Tooling and deployment are two big ones. Go doesn’t have a Turing complete DSL for it’s project files (that you have to run in daemon mode if you want a fast feedback loop); just a simple list of dependencies and a lock file. Testing is dead simple and built into the standard library and toolchain. Documentation generation is just comments; no javadoc syntax to learn, nor documentation packages to build and publish—godoc.org and friends can read any package available to them (including private repos if you host your own instance) and they automatically link to other packages’ docs without additional work. Also, static linkage by default that just works—yeah, fat jars and AOT are things in the Java world, but they take extra setup and often they aren’t feasible in practice. Meanwhile, I can send a Go binary to any Linux server and it will run. A lot of Java people love Java tooling because everything is super configurable and you can do just about everything you could ever theoretically want to do, but I rarely find this helpful—Go’s tooling generally does what I want it to do; I rarely have problems but I benefit immensely from being able to quickly figure out how to solve my problem. Different values, I guess.
Another big one is the data model. Go doesn’t have object types nor inheritance; it has value types, interfaces, pointers, and closures. While in Java I don’t have to use inheritance and one day there may be value types, inheritance and objects are and will continue to be pervasively used in the Java ecosystem, which means I’ll have to interact with lots of such code. Not the end of the world, but I really don’t enjoy it—I wouldn’t spend time fighting it if I have the option of using something else. More importantly, the data model and Go’s AOT allow me to reason about code performance more predictably, although JVM’s JIT compiler would be really nice for the very few highly dynamic programs that I write.
Notably, I don’t think Go does everything well or that it’s AOT model is good for everything and Java’s VM model is bad for everything. I actually would like to see a simpler, high performance JITing VM with better semantics for languages with value types (and a lower latency default GC although I hear that is improving in recent JVMs). I specifically don’t want all the bells and whistles for tuning my GC or my VM. I also want a dramatically simpler language running on it. Maybe a super simple lisp or something like Julia but geared toward general app dev.
Another big one is the data model. Go doesn’t have object types nor inheritance; it has value types, interfaces, pointers, and closures. While in Java I don’t have to use inheritance and one day there may be value types, inheritance and objects are and will continue to be pervasively used in the Java ecosystem, which means I’ll have to interact with lots of such code. Not the end of the world, but I really don’t enjoy it—I wouldn’t spend time fighting it if I have the option of using something else. More importantly, the data model and Go’s AOT allow me to reason about code performance more predictably, although JVM’s JIT compiler would be really nice for the very few highly dynamic programs that I write.
Notably, I don’t think Go does everything well or that it’s AOT model is good for everything and Java’s VM model is bad for everything. I actually would like to see a simpler, high performance JITing VM with better semantics for languages with value types (and a lower latency default GC although I hear that is improving in recent JVMs). I specifically don’t want all the bells and whistles for tuning my GC or my VM. I also want a dramatically simpler language running on it. Maybe a super simple lisp or something like Julia but geared toward general app dev.
Thank you!
I hear you re tools. I think there's definitely room for simpler ones, available out of the box. Anyway, I'll save your comment for future reference when the topic comes up (I work on OpenJDK).
As for GC, ZGC will have lower latency and higher throughput than Go's GC within a year, and the only tuning it needs is setting the heap size, and I expect Java will gradually increase the performance advantage it already has over Go. BTW, perhaps my biggest intrinsic reason for preferring Java (other than ecosystem size) is observability, which is also getting better with each release, and is probably ahead of any other mainstream runtime/language out there (and most non-mainstream ones, too), followed by performance, maintainability and flexibility.
I hear you re tools. I think there's definitely room for simpler ones, available out of the box. Anyway, I'll save your comment for future reference when the topic comes up (I work on OpenJDK).
As for GC, ZGC will have lower latency and higher throughput than Go's GC within a year, and the only tuning it needs is setting the heap size, and I expect Java will gradually increase the performance advantage it already has over Go. BTW, perhaps my biggest intrinsic reason for preferring Java (other than ecosystem size) is observability, which is also getting better with each release, and is probably ahead of any other mainstream runtime/language out there (and most non-mainstream ones, too), followed by performance, maintainability and flexibility.
Yeah, I've been hearing that the ZGC work is promising! What an exciting development! It's interesting that you cite observability--I've always been of the impression that observing the inner workings of the JVM is tremendously difficult and requires a high degree of expertise? I'm tremendously impressed with the JVM as a runtime (JIT and ZGC); I just hope they're (you're?) able to really make the developer experience seamless so things Just Work.
Observability in modern Java:
* https://blogs.oracle.com/javamagazine/java-flight-recorder-a...
* https://youtu.be/xrdLLx6YoDM
* https://blogs.oracle.com/javamagazine/java-flight-recorder-a...
* https://youtu.be/xrdLLx6YoDM
> Very curious about how Go getting generics will change its position in the landscape
Go cannot get generics because "conservative politics" in its community period. A lot of prominent gatekeepers are all about the status quo.
There are a few things Go could do to make it easier to work with, ease "type equivalence", introduce some covariance into the mix. Maybe unions, maybe replace multiple return types with tuples and destructuring assignement.
I don't believe a second Go will ever get generics and the courageous proposal done by Ian Lance Taylor, the hero of the language right now, won't really satisfy anybody because it's too complex yet doesn't do that much IMHO.
This is purely a political question, not a technical one. We had that debate for almost 10 years now and I dread more petty drama.
Go cannot get generics because "conservative politics" in its community period. A lot of prominent gatekeepers are all about the status quo.
There are a few things Go could do to make it easier to work with, ease "type equivalence", introduce some covariance into the mix. Maybe unions, maybe replace multiple return types with tuples and destructuring assignement.
I don't believe a second Go will ever get generics and the courageous proposal done by Ian Lance Taylor, the hero of the language right now, won't really satisfy anybody because it's too complex yet doesn't do that much IMHO.
This is purely a political question, not a technical one. We had that debate for almost 10 years now and I dread more petty drama.
There is some work being done here, https://go-review.googlesource.com/c/go/+/187317
But I agree with you, as seen by the commit messages they still aren't fully there, and at the end it might just happen as with the error proposal anyway.
But I agree with you, as seen by the commit messages they still aren't fully there, and at the end it might just happen as with the error proposal anyway.
You could have said the same about modules. Generics are clearly on the roadmap even if they are taking their sweet time about it.
>A lot of prominent gatekeepers are all about the status quo.
Who are these ?
Who are these ?
> No surprise to see generics being so strongly pined for again. Very curious about how Go getting generics will change its position in the landscape.
Well, only 25% of respondents said there were any features blocking adoption; and of that group yes the majority want generics. Since this is a survey of Go developers, it is not surprising to find out that a very solid majority find the language usable as it is. I think this also limits what this particular survey can tell us about the uptick in adoption you might see if that feature ever lands.
Well, only 25% of respondents said there were any features blocking adoption; and of that group yes the majority want generics. Since this is a survey of Go developers, it is not surprising to find out that a very solid majority find the language usable as it is. I think this also limits what this particular survey can tell us about the uptick in adoption you might see if that feature ever lands.
> ...how Go getting generics will change its position in the landscape.
I think it'll have minimal immediate effect. It'll quieten the vocal ones, but being a pragmatic bunch of people, most golang users just won't care much, at least at first. No doubt libraries will adopt it over time. Other golang projects will slowly follow.
I think it'll have minimal immediate effect. It'll quieten the vocal ones, but being a pragmatic bunch of people, most golang users just won't care much, at least at first. No doubt libraries will adopt it over time. Other golang projects will slowly follow.
I think this is right. Few people will say "oh Go has generics let me start using it now". But at the same time we shouldn't underestimate the benefit improved libraries could have on adoption in the long-run. I've heard several people say they just are not happy with any ORM in the Go ecosystem, for example and I think that situation would improve significantly with generics.
That's hard to measure. If Go had sum types and generics I'd be more willing to give it a serious try , but in its current state I don't see myself writing complex algorithmic code in it. Maybe other people feel the same, especially among the crowd already used to static typing.
I've been avoiding Go as much as possible as a poor use of engineering time, but I'll reconsider if they fix generics and error handling and comprehensions. Java 8 isn't outstanding (the JVM is!) but it's about where I put the bar for a tolerable language.
I disagree. I think there are tons of people who won’t touch Go because they can’t fathom programming without generics. I think lots of people will use the language and interact with lots of existing code and realize how far one can go with respect to type safety without ever touching generics. Unfortunately, I’m also afraid that this sea of newcomers will bring all of their paradigms to the Go ecosystem which is made possible by generics, and frankly the consistency that makes Go so productive will be lost. I like generics, but I’m afraid of the cost.
My favorite example is https://golang.org/pkg/sync/#Map, which should have been a typesafe drop-in replacement for map[K]V, but that isn't possible even within the standard library.
Yeah, I tend not to write or use these data structures. If I want a concurrent map, I usually write my own anyway. It’s easier to add the locks I want than to keep track of how sync.Map thinks about locking a map. I understand that this attitude angers a lot of people who believe that everything should be as DRY as possible, but this way works better for me.
I don't know about sync.Map, but many concurrent maps don't require any locking (or require rarely).
Protecting map with a lock is a very naive solution, it'll perform badly with a lot of concurrent writes.
Protecting map with a lock is a very naive solution, it'll perform badly with a lot of concurrent writes.
https://golang.org/src/sync/map.go is not completely lock-free but yeah, I think it's trying to batch structural changes to the map (and atomic compare-and-set on existing entries) which isn't something I would rewrite casually.
There's just no good reason that you can't reuse it without rewriting all call sites. []T and map[K]V and chan T should implement interfaces, everyone should always use those interfaces, and monomorphization should skip the runtime dispatch.
There's just no good reason that you can't reuse it without rewriting all call sites. []T and map[K]V and chan T should implement interfaces, everyone should always use those interfaces, and monomorphization should skip the runtime dispatch.
> Does your organization manage their own internal go documentation server (similar to godoc.org)?
> No (85%)
I would be very open to setting this up at my org - is there a canonical way to do this?
> What is the biggest challenge you personally face using Go today? > Working with modules / vendoring / pkg mgmt 12%
Go has come a long way since the solutions in the early days and is now supremely better than it every was. However, vendoring is still confusing, and it's unclear when one should commit vendor files (we did that at one of the places I used to work) and when one shouldn't. We kept getting afraid that one day some guy would just delete that repo off GitHub, or somebody would end up hacking it, then we can't get an important fix out into prod. I'm not sure if the Go team has any advice regarding this.
> What is the biggest challenge you personally face using Go today? > Issues with tooling 12%
I think Go in general has become very mature. From a tooling standpoint it's almost feature complete. The only thing I would like to see there is better autocomplete and tooling around calling C from Go but I know that's kind of hard to achieve. I frequently work with C libraries that I have to call from Go because Go is simply easier to write than C, but I don't think that Cgo has good integration with gopls at the moment (and I don't think it did in any other tooling that I've used).
I would be very open to setting this up at my org - is there a canonical way to do this?
> What is the biggest challenge you personally face using Go today? > Working with modules / vendoring / pkg mgmt 12%
Go has come a long way since the solutions in the early days and is now supremely better than it every was. However, vendoring is still confusing, and it's unclear when one should commit vendor files (we did that at one of the places I used to work) and when one shouldn't. We kept getting afraid that one day some guy would just delete that repo off GitHub, or somebody would end up hacking it, then we can't get an important fix out into prod. I'm not sure if the Go team has any advice regarding this.
> What is the biggest challenge you personally face using Go today? > Issues with tooling 12%
I think Go in general has become very mature. From a tooling standpoint it's almost feature complete. The only thing I would like to see there is better autocomplete and tooling around calling C from Go but I know that's kind of hard to achieve. I frequently work with C libraries that I have to call from Go because Go is simply easier to write than C, but I don't think that Cgo has good integration with gopls at the moment (and I don't think it did in any other tooling that I've used).
RE: modules and vendoring, you should no longer have to worry about a package going away now that proxies have been introduced (the default proxy right now being proxy.golang.org).
You should be able to pull all your modules from a proxy, minus any private repos you control (which you can either setup our own proxy for OR set The GOPROXY var to go direct to vcs for it).
Also, not vendoring should give you a smaller repo and build speed shouldn’t suffer too much (proxy caching and such).
You should be able to pull all your modules from a proxy, minus any private repos you control (which you can either setup our own proxy for OR set The GOPROXY var to go direct to vcs for it).
Also, not vendoring should give you a smaller repo and build speed shouldn’t suffer too much (proxy caching and such).
modules and vendoring is still a pain and I don't want or need a network resource to build my code. If a vendor directory is present, use it!
While things are better in Go 1.14, it is not solved. I do not want to set up a company proxy for our private repos. I can't count how many times some combination of GOPROXY, private repos, vendoring, and modules have been a problem.
While things are better in Go 1.14, it is not solved. I do not want to set up a company proxy for our private repos. I can't count how many times some combination of GOPROXY, private repos, vendoring, and modules have been a problem.
Ah good point about GOPROXY.
So if I have a mix of private and public dependencies that I pull in, can I specify a specific proxy for the private ones? Is it the GOPRIVATE env var?
So if I have a mix of private and public dependencies that I pull in, can I specify a specific proxy for the private ones? Is it the GOPRIVATE env var?
The proxy should maintain a copy of all dependencies (public and private), so only one should be necessary.
This should be clarified, if you setup YOUR OWN proxy it can handle both public and private modules (side note I haven’t been able to verify this yet with artifactory).
You can also just let your GOPROXY fallback go “direct” which will then go straight to vcs (you need to make sure you have a gitconfig setup to redirect https to ssh).
You can also just let your GOPROXY fallback go “direct” which will then go straight to vcs (you need to make sure you have a gitconfig setup to redirect https to ssh).
re: Setting up internal go documentation server - the godoc package has great instructions for doing so!
https://godoc.org/golang.org/x/tools/cmd/godoc
https://godoc.org/golang.org/x/tools/cmd/godoc
> What critical language features do you need that are not avaliable in Go?
==> Generics 79%
> what's the biggest challenge you personally face using Go today?
==> Generics 15%
Really? What a surprise. /s
Still wondering if Go 2.0 will actually happen, or be torpedoed like the error improvements.
Anyway, the work appears to be ongoing here https://go-review.googlesource.com/c/go/+/187317
==> Generics 79%
> what's the biggest challenge you personally face using Go today?
==> Generics 15%
Really? What a surprise. /s
Still wondering if Go 2.0 will actually happen, or be torpedoed like the error improvements.
Anyway, the work appears to be ongoing here https://go-review.googlesource.com/c/go/+/187317
There is no Go 2.0. They kind of decided to introduce non-breaking changes slowly and that's it for now. Nobody (from the team at least) even talks about 2.0 anymore.
Sure there is, even if as concept, or milestone mark of what it is supposed to mean in language features.
The team does speak about it, as the Go 2.0 labels are pretty much still being used, and mentioned in code reviews or occasional emails.
The team does speak about it, as the Go 2.0 labels are pretty much still being used, and mentioned in code reviews or occasional emails.
~60% of respondents have <2 years experience with the language.
I'd really like to see this filtered to developers with >5 years go experience. What do the experienced go devs want from the language? How do they use it?
I've got a little over 9 years of almost daily use and I have little in common with the devs in my org that are earlier in their career and coming to go with a head full of some other language.
I'd really like to see this filtered to developers with >5 years go experience. What do the experienced go devs want from the language? How do they use it?
I've got a little over 9 years of almost daily use and I have little in common with the devs in my org that are earlier in their career and coming to go with a head full of some other language.
Out of curiosity, at what point do you consider someone a seasoned Go developer? Is it 5 years or is it more?
I've been using Go since 2015 and I still feel like I'm not as seasoned as I perhaps should be (I'm not really an enthusiast of the language, I just think it's the right tool to use for 95%+ of the stuff I'm working on right now).
I've been using Go since 2015 and I still feel like I'm not as seasoned as I perhaps should be (I'm not really an enthusiast of the language, I just think it's the right tool to use for 95%+ of the stuff I'm working on right now).
Hard to quantify. Time in language should roughly track. Maybe number of companies/projects developed.
Any of the dimensions you could imagine would be good starting points.
Any of the dimensions you could imagine would be good starting points.
If it is not too much to ask:
Do you still enjoy it? What _your_ biggest pain points with language/community/process etc?
Do you still enjoy it? What _your_ biggest pain points with language/community/process etc?
I am stunned by how many people actually like working with go.
As a language, I've always thought it was horrible. But as an option for tasks like network programming, devops, setting up a web service, it's one of the best.
So I understand it's popularity, and I reach for it frequently as well, but not happily like others seem to.
As a language, I've always thought it was horrible. But as an option for tasks like network programming, devops, setting up a web service, it's one of the best.
So I understand it's popularity, and I reach for it frequently as well, but not happily like others seem to.
Depends on where you come from. From C, it's basically what you did with C with bells and whistles (multiple return types instead of OUT parameters for instance).
From Scala/Java/C#, if you really like working with these languages, I don't think you'd enjoy Go.
And while Goroutines sound nice at first, they come with many issues that languages that had similar concepts (like ADA tasks) did not have.
From Scala/Java/C#, if you really like working with these languages, I don't think you'd enjoy Go.
And while Goroutines sound nice at first, they come with many issues that languages that had similar concepts (like ADA tasks) did not have.
> Problems
Such as? :)
Such as? :)
[deleted]
I’m pretty new to Go, and I recently tried to get delve working with VS Code and it was a pretty rough experience (VS Code in general wasn’t as polished for Go as I’d hoped). Using Delve via the command line was even harder for me to figure out.
My experience debugging in dynamic languages has just been so much easier. Just add a single line anywhere and boom - a repl exactly where you want it. I don’t mind IntelliJ for Java either (a big difference being that it has a free community edition).
I know Go is different than dynamic languages, but I wish the UX of debugging was simpler, or that there’s a free IDE that makes it easy. I’ve also heard you can “replay” easily with Delve, which sounds amazing if it was easy to figure out!
My experience debugging in dynamic languages has just been so much easier. Just add a single line anywhere and boom - a repl exactly where you want it. I don’t mind IntelliJ for Java either (a big difference being that it has a free community edition).
I know Go is different than dynamic languages, but I wish the UX of debugging was simpler, or that there’s a free IDE that makes it easy. I’ve also heard you can “replay” easily with Delve, which sounds amazing if it was easy to figure out!
Would love to hear any feedback you have on what made your experience with Delve more difficult than it needed to be. Feel free to open an issue describing the pain points your ran into, or send mail to the mailing list: https://groups.google.com/forum/#!forum/delve-dev.
If you are a professional programmer then paying $200 for a Goland license could ameliorate some of your complaints.
For individuals only $89:
https://www.jetbrains.com/go/buy/#personal?billing=yearly
https://www.jetbrains.com/go/buy/#personal?billing=yearly
Alas, I’m writing Go for an open source project I’m interested in, not for work
You could apply for a free license for open source.
https://www.jetbrains.com/go/buy/#discounts?billing=yearly
https://www.jetbrains.com/go/buy/#discounts?billing=yearly
I unfortunately don’t qualify
I've had similar experience and eventually had to drop to print-lining for debugging. I do occasionally use gldv[1] which is IDE independent/frontend for delve though which gives me some hope on the debugging side w/o being tied to one IDE.
[1] https://github.com/aarzilli/gdlv
[1] https://github.com/aarzilli/gdlv
I feel like the answer to "what prevents you from better debugging/profile" that's dominant, "lack of knowledge/experience" may be more of a catch-all than actually highlight a problem.
Like, there's always something you can do better, most people don't want to claim they know everything. So in a survey I'd probably check that box/type that answer even if I didn't have an actual problem.
Like, there's always something you can do better, most people don't want to claim they know everything. So in a survey I'd probably check that box/type that answer even if I didn't have an actual problem.
Interesting to see. Been a computer-person all my life, but only started programming with Python like 4 years ago.
Switched from Python to Go after about a year. Go just seemed much easier to work with.
I have still, to this day, not made a single penny with Go. Never been a professional programmer. It's so weird to think that I'm still trying to learn more and more about it and use it for _something_.
Go really pulled me in somehow. I blame Todd McLeod and Jon Calhoun ;)
Ultimately the value of Go for me seemed to be quick-access to lots of buzzwordy things I wanted to make use of. Concurrency, web-apps, internet / online - infrastructure things. (Funnily enough I still don't use concurrency much or properly at all. Like, years in and I still don't.)
There is hardly a greater feeling than to make something work, to figure something out. To know you've learned something. I just hope that one day that will actually turn into money. That seems to be the trickiest part. Hmmmm.
I'm curious what it is that you do for work? You mention not making money from Go (or programming) -- what are your goals? Is it a startup kind of thing, or employment as a developer? I feel like you could probably get a job if you're familiar with Go and Python you can probably start interviewing.
I was a (technical, mostly) project manager for about 10 years and then decided I didn't like that career anymore. I am indeed trying to get a small product out there. If, however, that does not work, I'd be looking into employment as a developer. It's kind of hard to gauge how I might operate in a team environment. I also wonder how to even begin assessing my experience level. I am certainly not shooting for the stars, but also getting stuck in a proto-2-proto role would probably be terrible ;)
When it says "I primarily develop Go on...Linux|Mac|Windows|Etc", is this question referring to the platform the project is intended to run on? Or is it the platform people are actually using their IDE in?
I'm just surprised that Linux only is so high and Windows so low if its referring to the "workstation".
I'm just surprised that Linux only is so high and Windows so low if its referring to the "workstation".
> is this question referring to the platform the project is intended to run on? Or is it the platform people are actually using their IDE in?
I think it's pretty obvious, no? "develop Go on" seems pretty self explanatory.
I think it's pretty obvious, no? "develop Go on" seems pretty self explanatory.
I'm surprised anyone beyond C# and game programmers still code on Windows. It must be constant agony.
Its not that I want to, its what is given to me. I've personally not seen any companies providing Linux workstations which was my surprise.
It isn't that bad to me anyway, developing in containers with vscode or WSL works just fine 99% of the time for what I do. But that adds confusion to the question for me.
It isn't that bad to me anyway, developing in containers with vscode or WSL works just fine 99% of the time for what I do. But that adds confusion to the question for me.
This interpretation makes an obvious mistake at the end of the "Sentiments toward Go" section. The question asked was:
> Rank the following programming languages in terms of your preference
And the blog writes:
> people who responded to the Go Developer Survey tended to like Go. > However, we also wanted to understand which other languages respondents enjoy working with.
For some tasks, I would prefer to work with Python or Bash, though I dislike these languages. I rarely enjoy programming with Python, but I sometimes prefer its environment, especially its universality and some specific libraries. I suppose I'm not a single counter-example where "prefer to use" does not mean "enjoy using".
> Rank the following programming languages in terms of your preference
And the blog writes:
> people who responded to the Go Developer Survey tended to like Go. > However, we also wanted to understand which other languages respondents enjoy working with.
For some tasks, I would prefer to work with Python or Bash, though I dislike these languages. I rarely enjoy programming with Python, but I sometimes prefer its environment, especially its universality and some specific libraries. I suppose I'm not a single counter-example where "prefer to use" does not mean "enjoy using".
Soon Go will have both generics and package management, two things the maintainers really didn't think it needed on Day One. I don't say this to insult anyone, Go has always been a great and unique language. I say this as a plea to any aspiring language designers out there: please don't try to make a modern general purpose language without these things. We really do need them.
Actually, I think the success of Go has proven the contrary. You can make a modern language without those features. In fact for an MVP you want to cut difficult or not absolutely necessary features from the first version. So I think Go did fine here and I encourage other language designers to follow their lead.
One cavaet is if you don't think about at least how generics might work in your language in a backward compatible way, you box in your future options. See java for how this goes poorly. If you look at the generics proposals for Go you see how this has greatly complicated the task. That doesn't automatically mean it was a mistake to do it that way though.
If you try to do everything at the beginning you might take so long that you fail outright or don't get the early adopters who help shape the language. Plus you'd be behind the curve on adoption. So I think Go did the smart thing here.
One cavaet is if you don't think about at least how generics might work in your language in a backward compatible way, you box in your future options. See java for how this goes poorly. If you look at the generics proposals for Go you see how this has greatly complicated the task. That doesn't automatically mean it was a mistake to do it that way though.
If you try to do everything at the beginning you might take so long that you fail outright or don't get the early adopters who help shape the language. Plus you'd be behind the curve on adoption. So I think Go did the smart thing here.
You and the parent are correct. Package management and generics are essentials for any general-purpose programming language. But, they fall lower than many other features (like syntactic consistency and simplicity) ranked by importance for developer productivity and usefulness.
Without Google, Docker and Kubernetes, Go would have been as successful as Limbo and Oberon-2, its two main influences.
There's nothing wrong with Java generics. Reified generics are a design choice. As someone who uses a lot of non-Java JVM languages, I'm thankful interop is easier.
There's a lot wrong with them.
You may like the design choice, but I can find plenty of people who hate it.
You may like the design choice, but I can find plenty of people who hate it.
Those "plenty of people" think they hate it because they don't understand it (especially the problem of variance). The only languages (in relatively common use) that reify generics for variant types are C++ and C#, and both of their variance models are fucked up, albeit in different ways. If reference-type generics were reified, Java couldn't serve as a platform for so many languages. In other words, they might hate it, but they would have hated the alternative even more. Specializing generics for invariant types is another matter, and Java is getting those.
> two things the maintainers really didn't think it needed on Day One
Deep down they know they need these in order for the language to survive in the modern world. I'm guessing that the reason they chose that tone back then was because they wanted to release the language as small as possible so that people can start using, learning, and grow in moderate fashion. And also they can't solve all problems at once.
Deep down they know they need these in order for the language to survive in the modern world. I'm guessing that the reason they chose that tone back then was because they wanted to release the language as small as possible so that people can start using, learning, and grow in moderate fashion. And also they can't solve all problems at once.
Suprised to see Vim usage decreasing every year. Presumably most are defecting to Goland
I doubt anyone is defecting in any numbers, but that the unix die-hards are being diluted by an influx of developers who prefer an IDE.
Even unix die-hards can see the benefits. I stuck to using vim for years and years until I ventured in learning some new languages and explored VSCode. Then I started working with Java and found IntelliJ. The gains when the IDE is actively working with you to autocomplete/point out errors/warnings/code formatting etc are undeniable. Recently I copied a Python script from Linux side to VSCode - the window basically lit up with suggetions/warnings about unused imports etc etc - and this is when the script was working fine in Linux. Cleaning up the code was super easy too. In case it is not obvious, I love *nix and I'm totally for modern IDEs.
PS: I'm aware that a lot of these can be achieved by vim plugins/formatters etc - I do use some. But I can't be pursued to code Java in vim vs IntelliJ; its just not the same.
PS: I'm aware that a lot of these can be achieved by vim plugins/formatters etc - I do use some. But I can't be pursued to code Java in vim vs IntelliJ; its just not the same.
I only read the tl;dr, but I expected some questions centered around most commonly identified missing features in Go (i.e. first class support for enumerations, generics, naked return, compiler generating similar code for named vs unnamed returns, etc.)
They do touch on these issues but only barely. The survey is more about who's using Go the way it is now and how can we help with adoption with what Go is. The survey is not necessarily intended to be a how might we make the Go core language different or "better" sort of thing.
Remember, for a lot of Go developers Go _is_ fine the way it is now. You may get a different set of developers if you add features but you also may lose those who like it the way it is now. There are a lot of applications coded that just don't have a need for the features you mention.
Remember, for a lot of Go developers Go _is_ fine the way it is now. You may get a different set of developers if you add features but you also may lose those who like it the way it is now. There are a lot of applications coded that just don't have a need for the features you mention.
1) Fast adoption of GoLand/IntelliJ (and death of Sublime/Atom)
2) Nearly complete adoption of modules (my company is behind!)
3) "I feel welcome in the Go community" dipped from 82% to 75%. Anecdotally most people in Go are really nice but some people are aggressively pedantic (don't call it the Golang community!)