15 ms·

Go 2018 Survey Results

145 points by wardn 8y ago

ousta 8y ago
unrelated but the charts are very nice what lib is used to render those?
- saagarjha 8y ago
  Given the mix of Arial and Roboto as well as the style, I think they used Google Sheets.
  - minxomat 8y ago
    Or Google Data Studio.
leshow 8y ago
I'm not surprised that the official Go survey showed: "..Go is the top language they'd prefer to use..." It doesn't really say much given the selection bias.
- DC-3 8y ago
  Wow, congratulations for spotting that bias. Really slaying monsters with that sort of statistical insight. Why can't you look for the value in the article instead of picking stupid holes in it?
  - cdelsolar 8y ago
    Who micturated upon your toasted maize flakes?
- ntnn 8y ago
  The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting. Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.
  - zzzcpan 8y ago
    > Go team knows that they aren't covering the needs of This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
  - mynegation 8y ago
    As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter. Go works very well in domains with a well-defined and limited set of entities.
    - chessturk 8y ago
      Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would be useful in that space, is it?
      - mynegation 8y ago
        > What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism. When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation. > If Go! had generics, would that change it's suitability for finance? I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube. > I would think that first-class concurrency would be useful in that space, is it? Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
- zzzcpan 8y ago
  The point is to very roughly quantify that selection bias, no? Obviously, if Go neglects certain areas or doesn't fit well enough, people who consider those areas important don't use Go and are not represented in the survey.
- politician 8y ago
  Asking what languages people use at work or when not at work is an obvious place to start this sort of survey, it should be no surprise that Go is ranked highly among people who found it on the Go website, and it didn't surprise the authors of the survey either who pointed it out and quickly moved on to more meaningful statistics.
zeroxfe 8y ago
I'm a big fan of both Go and Rust, and it's really interesting to see Rust ranked #3 in preference but #17 in expertise. Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)
- pjmlp 8y ago
  Go has not displaced anything around here. Still plain old Java, .NET and C++ as always.
  - deleted 8y ago
    [deleted]
  - Intermernet 8y ago
    I agree with you, but I still think you're going to see Go, Rust and friends eating away at that code base. FYI I'm language agnostic, but I'd like to see c++ eventually replaced. .NET is currently looking good, and I'm ambivalent on Java, but I think there are valid reasons to be looking at go right now,if not rust. They both seem to be tuned to modern hardware design despite the hype.
  - Thaxll 8y ago
    Depends where you work, but if it's related to Kubernetes, service mesh ect ... Go is pretty popular nowdays.
    - dharmab 8y ago
      That's largely because it's the easiest way to deal with Custom Resource Definitions within Kubernetes, and because many of the tools that make writing a Controller or Operator easy are only exposed as internal APIs.
      - Thaxll 8y ago
        It's also because a k8s daemonset or sidecar takes 5 to 10x less memory to run using Go. No one wants to run small pods with JVM and xms / xmx settings to 512MB.
Insanity 8y ago
Moving to Go at work has made me incredibly happy. It really is a fun language and I tend to use it for my side-projects as well Coming from Java, I find that I don't miss generics and exceptions as much anymore as I thought I would :)
alexkavon 8y ago
> VS Code and GoLand are surging in popularity and are now the most popular code editors among survey respondents. I wish the package situation for Go was better for SublimeText. Currently most of the worthwhile golang packages that add vet, goimports, fmt, etc support are either abandoned or buggy. Margo bailed on using Package Control so it's difficult to install, not to mention buggy. I've used VSCode for a while but it chokes sometimes and you can't beat the speed, ease, and power of SublimeText.
- frou_dh 8y ago
  At the end of last year, a great systematic rewrite of Sublime's Go grammar was merged. So at that (admittedly surface-) level, it's doing very well. I just maintain my own on-save hooks, build systems and plugins to integrate various quality-of-life Go tools. With the benefit of being able to tailor any such functionality to exactly the way you like to work and nothing more, it's far less effort than it would be to create the all-singing-all-dancing comprehensive package that is absent.
  - alexkavon 8y ago
    Agreed, this is actually on my todos, just haven't executed yet.
Groxx 8y ago
I'd be particularly interested in seeing a low-expertise / high-expertise comparison on satisfaction / desired improvements. It takes a while to learn (in every language) what's going to bite you and how to deal with it / how well it works.
- deleted 8y ago
  [deleted]
funkythings 8y ago
Working with go was...fun! Simple as that. I really feel like the authors of the language found a very good mix of expressiveness, speed and ease of use.
ilovecaching 8y ago
Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects. Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C. Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment. Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done. Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.
- rlander 8y ago
  > Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.
  - hu3 8y ago
    I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.
  - ilovecaching 8y ago
    Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo. Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).
qlk1123 8y ago
Off topic but it's quite interesting to see that on HN, a great amount of the comments of a GO post talk about Rust, and vice versa. As a system guy, I am also happy to follow two OS projects in these two: [1] https://github.com/mit-pdos/biscuit https://github.com/mit-pdos/biscuit [2] https://github.com/redox-os/redox https://github.com/redox-os/redox
- pyrale 8y ago
  Probably because these two communities are the most involved in flinging propaganda about their language. Of course, sometimes their courses collide.

145 points by wardn 8y ago

ousta 8y ago

unrelated but the charts are very nice what lib is used to render those?

saagarjha 8y ago
Given the mix of Arial and Roboto as well as the style, I think they used Google Sheets.
- minxomat 8y ago
  Or Google Data Studio.

leshow 8y ago

I'm not surprised that the official Go survey showed: "..Go is the top language they'd prefer to use..." It doesn't really say much given the selection bias.

DC-3 8y ago
Wow, congratulations for spotting that bias. Really slaying monsters with that sort of statistical insight. Why can't you look for the value in the article instead of picking stupid holes in it?
- cdelsolar 8y ago
  Who micturated upon your toasted maize flakes?
ntnn 8y ago
The question on its own is useless given the audience - yes. However if you combine that question with the - e.g. - primary field a person works in it gets interesting. Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.
- zzzcpan 8y ago
  > Go team knows that they aren't covering the needs of This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
- mynegation 8y ago
  As a person who is mostly writing finance software I can tell that Go is not very well suited for any kind of rich application domain (which finance definitely is). OOP and Java + C# in particular have a very strong hold in finance. We can argue whether composition is an adequate substitute for inheritance, but the lack of generics is pretty much a non-starter. Go works very well in domains with a well-defined and limited set of entities.
  - chessturk 8y ago
    Sincere questions, I don't come from a OOP background, and do have plenty of Go! experience, so I feel like I'm missing the nuance of this post. What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? If Go! had generics, would that change it's suitability for finance? I would think that first-class concurrency would be useful in that space, is it?
    - mynegation 8y ago
      > What causes OOP to be well suited for finance's use case? What are the short-comings of structs/interface methods that Go! provides in the financial space? “Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism. When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation. > If Go! had generics, would that change it's suitability for finance? I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube. > I would think that first-class concurrency would be useful in that space, is it? Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
zzzcpan 8y ago
The point is to very roughly quantify that selection bias, no? Obviously, if Go neglects certain areas or doesn't fit well enough, people who consider those areas important don't use Go and are not represented in the survey.
politician 8y ago
Asking what languages people use at work or when not at work is an obvious place to start this sort of survey, it should be no surprise that Go is ranked highly among people who found it on the Go website, and it didn't surprise the authors of the survey either who pointed it out and quickly moved on to more meaningful statistics.

zeroxfe 8y ago

I'm a big fan of both Go and Rust, and it's really interesting to see Rust ranked #3 in preference but #17 in expertise. Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)

pjmlp 8y ago
Go has not displaced anything around here. Still plain old Java, .NET and C++ as always.
- deleted 8y ago
  [deleted]
- Intermernet 8y ago
  I agree with you, but I still think you're going to see Go, Rust and friends eating away at that code base. FYI I'm language agnostic, but I'd like to see c++ eventually replaced. .NET is currently looking good, and I'm ambivalent on Java, but I think there are valid reasons to be looking at go right now,if not rust. They both seem to be tuned to modern hardware design despite the hype.
- Thaxll 8y ago
  Depends where you work, but if it's related to Kubernetes, service mesh ect ... Go is pretty popular nowdays.
  - dharmab 8y ago
    That's largely because it's the easiest way to deal with Custom Resource Definitions within Kubernetes, and because many of the tools that make writing a Controller or Operator easy are only exposed as internal APIs.
    - Thaxll 8y ago
      It's also because a k8s daemonset or sidecar takes 5 to 10x less memory to run using Go. No one wants to run small pods with JVM and xms / xmx settings to 512MB.

Insanity 8y ago

Moving to Go at work has made me incredibly happy. It really is a fun language and I tend to use it for my side-projects as well Coming from Java, I find that I don't miss generics and exceptions as much anymore as I thought I would :)

alexkavon 8y ago

> VS Code and GoLand are surging in popularity and are now the most popular code editors among survey respondents. I wish the package situation for Go was better for SublimeText. Currently most of the worthwhile golang packages that add vet, goimports, fmt, etc support are either abandoned or buggy. Margo bailed on using Package Control so it's difficult to install, not to mention buggy. I've used VSCode for a while but it chokes sometimes and you can't beat the speed, ease, and power of SublimeText.

frou_dh 8y ago
At the end of last year, a great systematic rewrite of Sublime's Go grammar was merged. So at that (admittedly surface-) level, it's doing very well. I just maintain my own on-save hooks, build systems and plugins to integrate various quality-of-life Go tools. With the benefit of being able to tailor any such functionality to exactly the way you like to work and nothing more, it's far less effort than it would be to create the all-singing-all-dancing comprehensive package that is absent.
- alexkavon 8y ago
  Agreed, this is actually on my todos, just haven't executed yet.

Groxx 8y ago

I'd be particularly interested in seeing a low-expertise / high-expertise comparison on satisfaction / desired improvements. It takes a while to learn (in every language) what's going to bite you and how to deal with it / how well it works.

deleted 8y ago
[deleted]

funkythings 8y ago

Working with go was...fun! Simple as that. I really feel like the authors of the language found a very good mix of expressiveness, speed and ease of use.

ilovecaching 8y ago

Go and Rust are actually a great combo with only a little overlap. What’s great is that they are both C family and have some shared principles and flow. When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects. Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C. Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment. Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done. Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.

rlander 8y ago
> Your company should be pivoting or have a strategy to get on deck with these languages. That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.
- hu3 8y ago
  I don't think your parent meant that a language broadly replaces another but rather that Go and Rust lend themselves well for some types of projects typically done in other languages.
- ilovecaching 8y ago
  Not C++, but definitely the other languages outside of some non standard SWE domains like ML, where Python is going to be an obvious winner. Otherwise Go beats them by having a type system but still supporting duck typing through interfaces, having a modern concurrency story, being easier to learn (the Go spec can be read in one evening), having less features to abuse, faster development loops with lightning fast compile times and catching more errors at compile time, and just generally being faster and having a garbage collector that is tuned for low latency (a good fit for web services). We can also start faster which is really important for container workloads, idle with less memory which is important for horizontal scaling, and use less CPU which means smaller machines and more colo. Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).

qlk1123 8y ago

Off topic but it's quite interesting to see that on HN, a great amount of the comments of a GO post talk about Rust, and vice versa. As a system guy, I am also happy to follow two OS projects in these two: [1] https://github.com/mit-pdos/biscuit https://github.com/mit-pdos/biscuit [2] https://github.com/redox-os/redox https://github.com/redox-os/redox

pyrale 8y ago
Probably because these two communities are the most involved in flinging propaganda about their language. Of course, sometimes their courses collide.