10 ms·

Go Developer Survey 2021 Results

106 points by stevekemp 5y ago

capableweb 5y ago
> In the last year, have you or your team at work evaluated Go against another language for a project? No - 42% That strikes me as a shockingly high figure. Do people not regularly question what language to use when starting a project? Of course, I knew that cargo-culting and choosing your favorite language whenever you can was prevailing in programming circles, but I guess I didn't think it was that high (or is that just for Golang). Personally, every time I start a new project, I question what language I should use for it, and weigh multiple of them against each other. Same has been done when freelancing/consulting/working in bigger companies, and never experienced a environment where that question is not raised at all when starting a project.
- Jenk 5y ago
  Honestly I think the technicalities of a language take second place to "How easy will it be to scale the team?" (aka "How big is the candidate pool?") and "How quickly can anyone who leaves be replaced?" (aka "how easy is it to avoid the golden handcuffs?"
- lpapez 5y ago
  It seems to me like you are speaking from the perspective of personal projects (or small teams at least). However, if you are an organization which currently consists mostly of Java or Python devs, then Go might not even be an option for you. You can't just pick whatever seems best, somebody needs to maintain it and maintenance is much more expensive in the long run so going with something familiar and established in your environment pays off.
  - spyspy 5y ago
    Yeah really the only realistic question is, what's (most) everything else written in? Company's don't spend much time debating programming languages unless there's a _really_ compelling reason to switch.
    - capableweb 5y ago
      > unless there's a _really_ compelling reason to switch Agree, if the company is all using Golang for mostly everything, and a new service appears that is supposed to run on embedded devices, a judgement gets made if to still go with Golang or go for something else. What the survey results is saying though is that 42% doesn't even do the bare minimum to figure out if there is compelling reasons.
      - endorphine 5y ago
        > What the survey results is saying though is that 42% doesn't even do the bare minimum to figure out if there is compelling reasons. It doesn't say this necessarily. It may very well mean that "Go worked well for us, while X didn't, and we have no compelling reason to try out Y now. Let's go with Go". Or it may mean that they previously evaluated other languages (e.g. from previous jobs) so they didn't have to do it this time. They were all on the same page that the language is a good fit so they short-circuited the decision. If I spend 1 minute in deciding the language to use for a project, I wouldn't exactly call it that I evaluated other languages. But my decision is based on past experiences with other languages. I think you're jumping to conclusions.
  - capableweb 5y ago
    > It seems to me like you are speaking from the perspective of personal projects No, hence I wrote: > Same has been done when freelancing/consulting/working in bigger companies The organizations I've worked with has usually judged a language based on itself, not what the current developers know, as learning a new language tends to not be overly difficult, compared to hiring new good developers. Maybe I've been lucky that way. Edit: I should add, usually the verdict is to keep with whatever language the current developers do know best, as that language fits with what the new project should cater. But a evaluation is usually done anyways to at least consider other options, even though it usually lands on one of the options for everything.
    - lpapez 5y ago
      Definetly not my experience. My view is that organizations are VERY reluctant to introduce new tech to their stack, and rightfully so in my opinion. For example: moving a Java dev to a different Java project internally is much easier than convincing a Java dev to learn Go (especially seniors who already invested a lot of time in learning it), and is much cheaper than hiring a new Go developer (onboarding etc.)
      - erik_seaberg 5y ago
        Companies are overly cautious about letting experts distinguish ourselves and invest in the learning curves of more powerful tools. Java is improving slowly but as an IC I’d be excited to move to Kotlin, Scala, Clojure, or maybe Rust or F#.
    - nawgz 5y ago
      > The organizations I've worked with has usually judged a language based on itself, not what the current developers know, as learning a new language tends to not be overly difficult Can you say more about these companies, and their long term successes with these tools? For example, I worked in the same place for 5 years now, and we picked a new language for a project someone wrote largely themselves. I supported them on it, they left, and now I am stuck maintaining a deprecated version of a language I don't know, on a program of middling code quality written in a non-idiomatic fashion without many useful comments because the author themself was learning and hacking along the way. I think for someone like you to say something like this and also say "freelancing/consulting" is a red flag, it's really easy to recommend "this language will work for this project", have the prototype work, get paid, leave, and not see the long term effects of throwing another area of required expertise onto the laps of the poor people stuck to maintain your decisions.
- LukeShu 5y ago
  How often do you start a new project? At work, me and my team maintain two existing products, both written (primarily) in Go. It would be bonkers for us to--once a year--consider "what if we threw out all of the existing code and re-implemented it in something else." And if we did launch a new product, because it'd probably be targeting a particular ecosystem, it'd probably be silly for us to choose a language that doesn't have good well-maintained libraries for that ecosystem. I guess you could say that's evaluating Go against other languages; but we know the ecosystem, we know that if we wanted to go with anything but Go we'd be wandering in to the wilderness.
  - capableweb 5y ago
    Yeah, obviously doesn't fit if you have two services running without any new services being written. But as a freelancer/consultant/cross-team employee in bigger organizations, new projects/services do get created probably more frequent than "once-per-year" but less frequent than "once-per-month". Everyone's experience is different I presume.
    - cube2222 5y ago
      If it's the same team developing and maintaining all those services, and those services are creating a bigger whole together, then using a single language for all of them will be very beneficial in the long run. Doesn't really matter which language it is. You can easily reuse libraries, observability tooling, don't have to context switch so often, etc. It's not "Which language is best for this project in a vacuum where nothing else exists?". It's "Is this language really so much better suited for this project that it's worth all the additional cost and mental overhead it will introduce?". Not saying it's never the right choice, but it often isn't.
    - LukeShu 5y ago
      The majority of programmers are not freelancers/consultants/cross-team-employees, they're for the most part "stuck" on just 1 team except for switching jobs. And so sure, while a new project gets started somewhere in the org more frequently than "once-per-year", for most programmers it's not their team. And so their answer is "no". And so that "42%" doesn't seem high to me. If the question had been "did a freelancer/consultant/cross-team-employee involved with your team evaluate Go against another language for a project as part of their involvement with a team other than your own?" then the answer would probably be "yes" for most programmers (well, more likely "not sure, but probably yes"). If the question had been asked only to freelancers/consultants/cross-team-employees, then "42%" would seem high.
- jerf 5y ago
  There could be an interpretation thing going on in the question. I have not at work sat down and formally evaluated my selection of language for a given task. Generally as soon as we so much as sketch out the problem, we know what our answer is. It's not hard to build a portfolio of about 2.5 general-purpose languages that covers pretty much every base you could need, such that you only really need super careful analysis on a very limited subset of problems. So I could easily answer either way on that question depending on where you draw the line for "evaluation". I certainly thought about the language for every single task, and didn't just blindly pick the same language for everything, but I didn't necessarily "evaluate" it in some formal manner.
- silisili 5y ago
  > Do people not regularly question what language to use when starting a project? Nope. We've pretty much settled on Go for backend, js/react for frontend. When you have a team of people all on the same page, randomly picking languages is a nightmare. Johnny wrote service X in Rust/Zig/D before he left for FB, now go fix it. That's a lot of developer time wasted for probably zero gain. Plus we have mountains of old code examples, modules, etc you lose in switching. In fairness, if however I were a solo dev, I probably would more often explore and evaluate new languages.
  - jitix 5y ago
    I generally agree with you, having had to debug nasty Clojure code because somebody thought it was the best fit for the problem (it actually was) but then left the company. I think prescribing languages should be somewhere it between - settle on one RAD tool/dynamic language (Ruby/Python) for quick new projects, one performant language (Go/Java/Rust) for core services, and one UI framework (React/Angular/Vue). It is important to use the right tool for the right project, but from a selected set of options that the company has built workforce competency around. Using the latest and greatest often gives you the best technical solution but often at the cost of maintainability and predictability.
- throwaway894345 5y ago
  I also consider the field of languages, but I’ve worked at places where it’s just Python or bust because the “senior” engineers only knew Python and were intimidated at the prospect of learning other languages. I think they had a C++ class in college and thought that all other languages must be similarly complicated. “Pointer” is a curse word in some circles. These projects did not go well because they were computationally intensive and “rewrite the slow parts in C/pandas/multiprocessing/etc” predictably doesn’t work (spend more time marshaling data than you save from C/parallelism).
- HL33tibCe7 5y ago
  Well, firstly, the wording of the question question includes the possibility that people simply haven't started a new project at all, which isn't unusual. Regardless of that though, in many companies, particularly (although not only) smaller ones, there is one language that is just used for almost everything. It keeps things simpler, allows easier reuse of code, etc. etc...
- Macha 5y ago
  In a corporate environment, it's a seriously uphill battle to bring along an entire team to a project using another language. In my time at a large employer, that language was Java. Go has attracted a similarly enterpise market, that it really doesn't surprise me if Go has ended up in that space in many companies.
- staunch 5y ago
  > Of course, I knew that cargo-culting... You're cargo-culting the phrase "cargo-culting" here, i.e. using the term blindly without understanding it. Using a programming language and related frameworks repeatedly, based on prior first-hand success, is not anywhere near the definition of cargo-culting. > ...every time I start a new project, I question what language I should use for it... Sounds like a waste of time unless the projects are significantly different from each other in terms of environment or requirements. The most productive and efficient choice is very frequently the language/frameworks your team know best. If that's not weighing extremely heavily in your decision-making process, you're doing it wrong.
- randomdata 5y ago
  I would have answered no to the question: 1. I didn't start a new project in the past year. 2. The projects I worked on did not bring a justifiable reason for a rewrite in another language.
- sibit 5y ago
  > Do people not regularly question what language to use when starting a project? For me, it depends ¯\_(ツ)_/¯ If I'm working with a team I'll choose a language that best fits the team/project. For example last year I was working on a project and I used C# since everyone on the team knew the language (and most of the team only knew C#) even though I knew Go would be a better choice. I spent 2 days creating the program and it could process all our files/data in about 40+ minutes. I then spent the next day rewriting it in Go which could process everything in about 1 minute. Whenever possible I'll start with something that the team can help support and I'll refactor/rewrite it if I have time to "do it better". In my experience management/companies are not willing to change the status quo but asking for forgiveness (after providing a significant improvement) hasn't caused any issues (yet). If I'm working on personal projects I always look for the "best" solution/language even if it means I have to extend my timeframe to learn something new.
  - metaltyphoon 5y ago
    Lol 40m vs 1m. Yeah I don’t mean to be rude but you probably didn’t know what you doing using C#. Your first clue that you did something wrong was the time difference.
    - sibit 5y ago
      > you probably didn’t know what you doing using C# Maybe. I was using a NuGet package recommended by the senior dev (that the team was very familiar with) but with Go, I decided to write everything myself. One could argue it's not a great comparison but I think it is. The main point of comparison was using solutions/languages that the team is familiar with versus exploring something new or different. > I don’t mean to be rude No offense take, I don't think I'm better or worse than any other average developer.
      - metaltyphoon 5y ago
        If u don’t mind, it peaked my curiosity, can you share what Nuget library that is? I want to try a sample data with C# and Go. What version of dotnet were you using? Did you try implementing what you did in C# just like Go?
- Philip-J-Fry 5y ago
  Language is rarely something people swap between willy-nilly. What you can do in Java, C, C++, C#, Rust, Elixir, etc. you can do in Go. Some might have strengths and weaknesses, but if your business is a website or a web technology and you're already using Go, then what problems are you likely to face where any other language is a better choice? The only thing I'd reach for a different language than Go is if I wanted to develop a GUI. I'd go for Java, C# or Rust. Management (and other developers) don't look highly on someone suggesting a different technology stack for each problem you encounter. You'd really need good justification to use it. New languages means developer training, potentially harder hiring, some developers won't want to learn it, knowledge can easily be hoarded by a select few individuals and lost easily, etc. It's not a position you want to find yourself in every few months. I was paid to use C# before I was paid to use Go. Everything I do in Go could have been done in C#. We moved to Go because it was a nicer fit for our team in the long run, but it wasn't an easy task to migrate an entire team to Go. I could not imagine having to maintain multiple tech stacks because someone thinks Rust is a better fit for a specific task and another person thinks Java is. It's not cargo-culting, it's called being a developer. I'm not paid to be a jack of all trades. I'm paid to develop Go applications and do it well. I'm not a fan of having to learn new languages each year. Keeping on top of .NET is already a pain, I'm not going to do that for 5 other ecosystems.
- lifefeed 5y ago
  Using a new language for a new project is a risk. Risks need to be weighed, and new languages rarely offer such a huge benefit that it's worth taking that risk over others. [0] Also, it takes years to get fluent in a language. I know every programmer likes to believe they can learn a language in a week or so, but that's really just the syntax and semantics. Becoming fluent means inhaling best practices and reading through years of PIPs and forum posts and pull requests, and watching other people struggle to solve weird problems and seeing how small choices in development impact future maintenance. Turning all of that into "unconscious competence" takes time, and it's obvious when people haven't put in that time. Basically, I've spent a lot of time debugging Perl/Python/Go code written by people who only knew the bare syntax, and were obviously C/C++/Java programmers, and it was not a happy time. [0] - Two exceptions I've seen were switching from PHP to Ruby on Rails back in 2005, and switching from Perl to Java for its typing and IDE support.
  - dhagz 5y ago
    Not only that, but the chances of having more than one developer at a company who already know $LANGUAGE_NOT_USED_AT_COMPANY is slim. There's maybe like two or three other people at my company who know Rust, and none of them are on my team or even close to my team in the org chart. So me proposing we write a new service in $LANGUAGE is basically me saying, "If I ever leave, you will have to literally move heaven and earth to maintain this thing. Or worse, you'll have to build institutional knowledge of $LANGUAGE as an insurance policy against me leaving."
- Zababa 5y ago
  We have ~20 millions lines of code at work, shared between C++, C#, JavaScript and some TypeScript. Whenever we start a new project we use one of those, as they cover all of our use cases. Except for the small ML/AI team that's using Python. This is not about cargo-culting or having a favorite language, that's just being pragmatic. I wish the same could be said about our databases.
- endorphine 5y ago
  Not shocking at all to me. If we're building a new web service, at the scale we're at, we _know_ Go is a good fit. We already chose it for our other 3 web APIs and it turned out a good choice. Why should we spend time and effort re-evaluating our decision when we're perfectly fine with the language? Instead, we prefer to spend that time for building the actual product.
svnpenn 5y ago
Overall I am happy with Go, as it lets me get stuff done quickly. The worst aspect of Go for me, is the documentation. Specifically, whoever designed the current site: https://pkg.go.dev/io https://pkg.go.dev/io I hate the fixed top bar. I hate the fixed side bar. I hate that the page does a backflip any time you resize your window. Its unfortunate, as the site was fine, and they broke it for no reason. As a workaround, I have been using this alternate site: https://godocs.io/io https://godocs.io/io
- jerf 5y ago
  You can also still run godoc locally. It's deprecated but they at least upgraded it to work with generics. It still does a couple of things better locally than the replacement does, which can also be run locally. godoc provides an index of all your packages within a project, which can be helpful rather than having to remember what it's called (browser find is very helpful), and if you change the godoc for a given package, godoc updates upon refresh whereas pkgsite either requires a restart or the passage of some timeout I've never waited for. There is also certainly something to be said for godoc producing just... a page. No expand/collapse type hierarchy, nothing that interferes with browser find, nothing that breaks your spatial intuition about where things are. Just a page.
- throwaway894345 5y ago
  At least they got rid of the BLM advert (or I’m not seeing it on mobile anyway). EDIT: Looks like they quietly pulled the banner back in November https://github.com/golang/website/commit/8a86c4a6dbe5e8bdf59f9d68538cf0fc5852be5a https://github.com/golang/website/commit/8a86c4a6dbe5e8bdf59... EDIT: People are downvoting this, so presumably I’ve offended someone. For what it’s worth, my grievance isn’t that I disagree with the advertised politics (although I emphatically do) as much as I disagree with advertising any politics on programming language websites.
  - blaxis 5y ago
    surprised they didn't have a 'support ukraine' banner
closeparen 5y ago
With generics landed, errors are what remains to complain about. Go’s error handling story actually strikes me as a very good fit for daemons, which should generally never crash and have no particularly good place to catch an unhandled exception. On the other hand for RPC and web services - which are indeed major use cases of Go! - the most common error handling strategy is to fail the RPC you’re in. Having to unwind the stack by hand in order to do this (and write all the associated tests) is a level of tedium that I get paid for at work but can’t quite bring myself to do at home.
- randomdata 5y ago
  The tedium of errors irked me for a long time until I realized that it was my poor abstractions inherited from what I learned in other languages that lead to that state. As I established a more Go-minded approach, it became much more pleasant. To the point that I now find it desirable. I have been on Typescript/Javascript projects of late. Now that's a tedious error handling experience. I notice my colleagues have given up on error handling entirely due to how difficult it is.
  - powerslacker 5y ago
    Same here. The Go approach is easy to read and eye compile. I can't stand exceptions now.
    - philosopher1234 5y ago
      >eye compile i like this phrase
    - eweise 5y ago
      It still suffers from being returned as a separate value so not easy to chain methods together.
      - robotastronaut 5y ago
        Method chaining, while possible, isn’t something I’d say is really encouraged in Go. Returned values should be handled explicitly. There are plenty of cases where it could be fine, but if a function can error, you wouldn’t want to chain anyways.
li2uR3ce 5y ago
I wish the number of "GopherCoins" put into "Dependency Management" was broken down into more pieces. Seems like dependencies are stupidly easy everywhere as long as you don't care about any kind of quality assurance. It's easy to get unvetted code running on your machines. Seems like I spend all my time trying to figure out if it's safe to depend on something while dependency management is usually purely a function of will it build/run. And yes, this is an everywhere problem and therefore Go can't be faulted. And yes everyone's pet language has solved it anyway. Thankfully no one uses anything but silver bullets today. /s Hard problems are still hard, I suppose.
- convolvatron 5y ago
  unless you can describe the properties you care about and build a machine to automatically verify them, then its not clear what you're asking for or how it could possibly be solved.
- morelisp 5y ago
  Does any other language's (common) dep tooling have something like the module proxy+sumdb? This is not sufficient but it's been a huge step forward for me to get some basic assurances that a) our upstreams are following at least base-level release practices, b) our team can't get spearphished, c) if we need to vet/blacklist/whatever, we have a single place in the infrastructure to do it.
todotask 5y ago
Didn't participate in the survey, I have previously used Swift, Ruby, Javascript, hesitate to use Crystal language (<1.0) since we need to iterate fast and less error prone, it's nature that Go is production-ready and fast built speed is important.
morelisp 5y ago
One surprising thing for me is that far more people use delve (a complex, third-party tool) than the race detector (one flag to tests you're already writing/running). I wonder if people just don't know they're running it?
- Philip-J-Fry 5y ago
  The second you run in debug mode with breakpoints in VSCode or Goland you're using Delve. I actually think VSCode uses Delve by default. It's the standard debugger. And it's not complex, most people are interacting with it though their IDE/Editor UI. Most people actually don't know about the race detector. It's not surprising at all that Delve is used more often.

106 points by stevekemp 5y ago

> In the last year, have you or your team at work evaluated Go against another language for a project? No - 42% That strikes me as a shockingly high figure. Do people not regularly question what language to use when starting a project? Of course, I knew that cargo-culting and choosing your favorite language whenever you can was prevailing in programming circles, but I guess I didn't think it was that high (or is that just for Golang). Personally, every time I start a new project, I question what language I should use for it, and weigh multiple of them against each other. Same has been done when freelancing/consulting/working in bigger companies, and never experienced a environment where that question is not raised at all when starting a project.

Jenk 5y ago
Honestly I think the technicalities of a language take second place to "How easy will it be to scale the team?" (aka "How big is the candidate pool?") and "How quickly can anyone who leaves be replaced?" (aka "how easy is it to avoid the golden handcuffs?"
lpapez 5y ago
It seems to me like you are speaking from the perspective of personal projects (or small teams at least). However, if you are an organization which currently consists mostly of Java or Python devs, then Go might not even be an option for you. You can't just pick whatever seems best, somebody needs to maintain it and maintenance is much more expensive in the long run so going with something familiar and established in your environment pays off.
- spyspy 5y ago
  Yeah really the only realistic question is, what's (most) everything else written in? Company's don't spend much time debating programming languages unless there's a _really_ compelling reason to switch.
  - capableweb 5y ago
    > unless there's a _really_ compelling reason to switch Agree, if the company is all using Golang for mostly everything, and a new service appears that is supposed to run on embedded devices, a judgement gets made if to still go with Golang or go for something else. What the survey results is saying though is that 42% doesn't even do the bare minimum to figure out if there is compelling reasons.
    - endorphine 5y ago
      > What the survey results is saying though is that 42% doesn't even do the bare minimum to figure out if there is compelling reasons. It doesn't say this necessarily. It may very well mean that "Go worked well for us, while X didn't, and we have no compelling reason to try out Y now. Let's go with Go". Or it may mean that they previously evaluated other languages (e.g. from previous jobs) so they didn't have to do it this time. They were all on the same page that the language is a good fit so they short-circuited the decision. If I spend 1 minute in deciding the language to use for a project, I wouldn't exactly call it that I evaluated other languages. But my decision is based on past experiences with other languages. I think you're jumping to conclusions.
- capableweb 5y ago
  > It seems to me like you are speaking from the perspective of personal projects No, hence I wrote: > Same has been done when freelancing/consulting/working in bigger companies The organizations I've worked with has usually judged a language based on itself, not what the current developers know, as learning a new language tends to not be overly difficult, compared to hiring new good developers. Maybe I've been lucky that way. Edit: I should add, usually the verdict is to keep with whatever language the current developers do know best, as that language fits with what the new project should cater. But a evaluation is usually done anyways to at least consider other options, even though it usually lands on one of the options for everything.
  - lpapez 5y ago
    Definetly not my experience. My view is that organizations are VERY reluctant to introduce new tech to their stack, and rightfully so in my opinion. For example: moving a Java dev to a different Java project internally is much easier than convincing a Java dev to learn Go (especially seniors who already invested a lot of time in learning it), and is much cheaper than hiring a new Go developer (onboarding etc.)
    - erik_seaberg 5y ago
      Companies are overly cautious about letting experts distinguish ourselves and invest in the learning curves of more powerful tools. Java is improving slowly but as an IC I’d be excited to move to Kotlin, Scala, Clojure, or maybe Rust or F#.
  - nawgz 5y ago
    > The organizations I've worked with has usually judged a language based on itself, not what the current developers know, as learning a new language tends to not be overly difficult Can you say more about these companies, and their long term successes with these tools? For example, I worked in the same place for 5 years now, and we picked a new language for a project someone wrote largely themselves. I supported them on it, they left, and now I am stuck maintaining a deprecated version of a language I don't know, on a program of middling code quality written in a non-idiomatic fashion without many useful comments because the author themself was learning and hacking along the way. I think for someone like you to say something like this and also say "freelancing/consulting" is a red flag, it's really easy to recommend "this language will work for this project", have the prototype work, get paid, leave, and not see the long term effects of throwing another area of required expertise onto the laps of the poor people stuck to maintain your decisions.
LukeShu 5y ago
How often do you start a new project? At work, me and my team maintain two existing products, both written (primarily) in Go. It would be bonkers for us to--once a year--consider "what if we threw out all of the existing code and re-implemented it in something else." And if we did launch a new product, because it'd probably be targeting a particular ecosystem, it'd probably be silly for us to choose a language that doesn't have good well-maintained libraries for that ecosystem. I guess you could say that's evaluating Go against other languages; but we know the ecosystem, we know that if we wanted to go with anything but Go we'd be wandering in to the wilderness.
- capableweb 5y ago
  Yeah, obviously doesn't fit if you have two services running without any new services being written. But as a freelancer/consultant/cross-team employee in bigger organizations, new projects/services do get created probably more frequent than "once-per-year" but less frequent than "once-per-month". Everyone's experience is different I presume.
  - cube2222 5y ago
    If it's the same team developing and maintaining all those services, and those services are creating a bigger whole together, then using a single language for all of them will be very beneficial in the long run. Doesn't really matter which language it is. You can easily reuse libraries, observability tooling, don't have to context switch so often, etc. It's not "Which language is best for this project in a vacuum where nothing else exists?". It's "Is this language really so much better suited for this project that it's worth all the additional cost and mental overhead it will introduce?". Not saying it's never the right choice, but it often isn't.
  - LukeShu 5y ago
    The majority of programmers are not freelancers/consultants/cross-team-employees, they're for the most part "stuck" on just 1 team except for switching jobs. And so sure, while a new project gets started somewhere in the org more frequently than "once-per-year", for most programmers it's not their team. And so their answer is "no". And so that "42%" doesn't seem high to me. If the question had been "did a freelancer/consultant/cross-team-employee involved with your team evaluate Go against another language for a project as part of their involvement with a team other than your own?" then the answer would probably be "yes" for most programmers (well, more likely "not sure, but probably yes"). If the question had been asked only to freelancers/consultants/cross-team-employees, then "42%" would seem high.
jerf 5y ago
There could be an interpretation thing going on in the question. I have not at work sat down and formally evaluated my selection of language for a given task. Generally as soon as we so much as sketch out the problem, we know what our answer is. It's not hard to build a portfolio of about 2.5 general-purpose languages that covers pretty much every base you could need, such that you only really need super careful analysis on a very limited subset of problems. So I could easily answer either way on that question depending on where you draw the line for "evaluation". I certainly thought about the language for every single task, and didn't just blindly pick the same language for everything, but I didn't necessarily "evaluate" it in some formal manner.
silisili 5y ago
> Do people not regularly question what language to use when starting a project? Nope. We've pretty much settled on Go for backend, js/react for frontend. When you have a team of people all on the same page, randomly picking languages is a nightmare. Johnny wrote service X in Rust/Zig/D before he left for FB, now go fix it. That's a lot of developer time wasted for probably zero gain. Plus we have mountains of old code examples, modules, etc you lose in switching. In fairness, if however I were a solo dev, I probably would more often explore and evaluate new languages.
- jitix 5y ago
  I generally agree with you, having had to debug nasty Clojure code because somebody thought it was the best fit for the problem (it actually was) but then left the company. I think prescribing languages should be somewhere it between - settle on one RAD tool/dynamic language (Ruby/Python) for quick new projects, one performant language (Go/Java/Rust) for core services, and one UI framework (React/Angular/Vue). It is important to use the right tool for the right project, but from a selected set of options that the company has built workforce competency around. Using the latest and greatest often gives you the best technical solution but often at the cost of maintainability and predictability.
throwaway894345 5y ago
I also consider the field of languages, but I’ve worked at places where it’s just Python or bust because the “senior” engineers only knew Python and were intimidated at the prospect of learning other languages. I think they had a C++ class in college and thought that all other languages must be similarly complicated. “Pointer” is a curse word in some circles. These projects did not go well because they were computationally intensive and “rewrite the slow parts in C/pandas/multiprocessing/etc” predictably doesn’t work (spend more time marshaling data than you save from C/parallelism).
HL33tibCe7 5y ago
Well, firstly, the wording of the question question includes the possibility that people simply haven't started a new project at all, which isn't unusual. Regardless of that though, in many companies, particularly (although not only) smaller ones, there is one language that is just used for almost everything. It keeps things simpler, allows easier reuse of code, etc. etc...
Macha 5y ago
In a corporate environment, it's a seriously uphill battle to bring along an entire team to a project using another language. In my time at a large employer, that language was Java. Go has attracted a similarly enterpise market, that it really doesn't surprise me if Go has ended up in that space in many companies.
staunch 5y ago
> Of course, I knew that cargo-culting... You're cargo-culting the phrase "cargo-culting" here, i.e. using the term blindly without understanding it. Using a programming language and related frameworks repeatedly, based on prior first-hand success, is not anywhere near the definition of cargo-culting. > ...every time I start a new project, I question what language I should use for it... Sounds like a waste of time unless the projects are significantly different from each other in terms of environment or requirements. The most productive and efficient choice is very frequently the language/frameworks your team know best. If that's not weighing extremely heavily in your decision-making process, you're doing it wrong.
randomdata 5y ago
I would have answered no to the question: 1. I didn't start a new project in the past year. 2. The projects I worked on did not bring a justifiable reason for a rewrite in another language.
sibit 5y ago
> Do people not regularly question what language to use when starting a project? For me, it depends ¯\_(ツ)_/¯ If I'm working with a team I'll choose a language that best fits the team/project. For example last year I was working on a project and I used C# since everyone on the team knew the language (and most of the team only knew C#) even though I knew Go would be a better choice. I spent 2 days creating the program and it could process all our files/data in about 40+ minutes. I then spent the next day rewriting it in Go which could process everything in about 1 minute. Whenever possible I'll start with something that the team can help support and I'll refactor/rewrite it if I have time to "do it better". In my experience management/companies are not willing to change the status quo but asking for forgiveness (after providing a significant improvement) hasn't caused any issues (yet). If I'm working on personal projects I always look for the "best" solution/language even if it means I have to extend my timeframe to learn something new.
- metaltyphoon 5y ago
  Lol 40m vs 1m. Yeah I don’t mean to be rude but you probably didn’t know what you doing using C#. Your first clue that you did something wrong was the time difference.
  - sibit 5y ago
    > you probably didn’t know what you doing using C# Maybe. I was using a NuGet package recommended by the senior dev (that the team was very familiar with) but with Go, I decided to write everything myself. One could argue it's not a great comparison but I think it is. The main point of comparison was using solutions/languages that the team is familiar with versus exploring something new or different. > I don’t mean to be rude No offense take, I don't think I'm better or worse than any other average developer.
    - metaltyphoon 5y ago
      If u don’t mind, it peaked my curiosity, can you share what Nuget library that is? I want to try a sample data with C# and Go. What version of dotnet were you using? Did you try implementing what you did in C# just like Go?
Philip-J-Fry 5y ago
Language is rarely something people swap between willy-nilly. What you can do in Java, C, C++, C#, Rust, Elixir, etc. you can do in Go. Some might have strengths and weaknesses, but if your business is a website or a web technology and you're already using Go, then what problems are you likely to face where any other language is a better choice? The only thing I'd reach for a different language than Go is if I wanted to develop a GUI. I'd go for Java, C# or Rust. Management (and other developers) don't look highly on someone suggesting a different technology stack for each problem you encounter. You'd really need good justification to use it. New languages means developer training, potentially harder hiring, some developers won't want to learn it, knowledge can easily be hoarded by a select few individuals and lost easily, etc. It's not a position you want to find yourself in every few months. I was paid to use C# before I was paid to use Go. Everything I do in Go could have been done in C#. We moved to Go because it was a nicer fit for our team in the long run, but it wasn't an easy task to migrate an entire team to Go. I could not imagine having to maintain multiple tech stacks because someone thinks Rust is a better fit for a specific task and another person thinks Java is. It's not cargo-culting, it's called being a developer. I'm not paid to be a jack of all trades. I'm paid to develop Go applications and do it well. I'm not a fan of having to learn new languages each year. Keeping on top of .NET is already a pain, I'm not going to do that for 5 other ecosystems.
lifefeed 5y ago
Using a new language for a new project is a risk. Risks need to be weighed, and new languages rarely offer such a huge benefit that it's worth taking that risk over others. [0] Also, it takes years to get fluent in a language. I know every programmer likes to believe they can learn a language in a week or so, but that's really just the syntax and semantics. Becoming fluent means inhaling best practices and reading through years of PIPs and forum posts and pull requests, and watching other people struggle to solve weird problems and seeing how small choices in development impact future maintenance. Turning all of that into "unconscious competence" takes time, and it's obvious when people haven't put in that time. Basically, I've spent a lot of time debugging Perl/Python/Go code written by people who only knew the bare syntax, and were obviously C/C++/Java programmers, and it was not a happy time. [0] - Two exceptions I've seen were switching from PHP to Ruby on Rails back in 2005, and switching from Perl to Java for its typing and IDE support.
- dhagz 5y ago
  Not only that, but the chances of having more than one developer at a company who already know $LANGUAGE_NOT_USED_AT_COMPANY is slim. There's maybe like two or three other people at my company who know Rust, and none of them are on my team or even close to my team in the org chart. So me proposing we write a new service in $LANGUAGE is basically me saying, "If I ever leave, you will have to literally move heaven and earth to maintain this thing. Or worse, you'll have to build institutional knowledge of $LANGUAGE as an insurance policy against me leaving."
Zababa 5y ago
We have ~20 millions lines of code at work, shared between C++, C#, JavaScript and some TypeScript. Whenever we start a new project we use one of those, as they cover all of our use cases. Except for the small ML/AI team that's using Python. This is not about cargo-culting or having a favorite language, that's just being pragmatic. I wish the same could be said about our databases.
endorphine 5y ago
Not shocking at all to me. If we're building a new web service, at the scale we're at, we _know_ Go is a good fit. We already chose it for our other 3 web APIs and it turned out a good choice. Why should we spend time and effort re-evaluating our decision when we're perfectly fine with the language? Instead, we prefer to spend that time for building the actual product.

svnpenn 5y ago

Overall I am happy with Go, as it lets me get stuff done quickly. The worst aspect of Go for me, is the documentation. Specifically, whoever designed the current site: https://pkg.go.dev/io https://pkg.go.dev/io I hate the fixed top bar. I hate the fixed side bar. I hate that the page does a backflip any time you resize your window. Its unfortunate, as the site was fine, and they broke it for no reason. As a workaround, I have been using this alternate site: https://godocs.io/io https://godocs.io/io

jerf 5y ago
You can also still run godoc locally. It's deprecated but they at least upgraded it to work with generics. It still does a couple of things better locally than the replacement does, which can also be run locally. godoc provides an index of all your packages within a project, which can be helpful rather than having to remember what it's called (browser find is very helpful), and if you change the godoc for a given package, godoc updates upon refresh whereas pkgsite either requires a restart or the passage of some timeout I've never waited for. There is also certainly something to be said for godoc producing just... a page. No expand/collapse type hierarchy, nothing that interferes with browser find, nothing that breaks your spatial intuition about where things are. Just a page.
throwaway894345 5y ago
At least they got rid of the BLM advert (or I’m not seeing it on mobile anyway). EDIT: Looks like they quietly pulled the banner back in November https://github.com/golang/website/commit/8a86c4a6dbe5e8bdf59f9d68538cf0fc5852be5a https://github.com/golang/website/commit/8a86c4a6dbe5e8bdf59... EDIT: People are downvoting this, so presumably I’ve offended someone. For what it’s worth, my grievance isn’t that I disagree with the advertised politics (although I emphatically do) as much as I disagree with advertising any politics on programming language websites.
- blaxis 5y ago
  surprised they didn't have a 'support ukraine' banner

closeparen 5y ago

With generics landed, errors are what remains to complain about. Go’s error handling story actually strikes me as a very good fit for daemons, which should generally never crash and have no particularly good place to catch an unhandled exception. On the other hand for RPC and web services - which are indeed major use cases of Go! - the most common error handling strategy is to fail the RPC you’re in. Having to unwind the stack by hand in order to do this (and write all the associated tests) is a level of tedium that I get paid for at work but can’t quite bring myself to do at home.

randomdata 5y ago
The tedium of errors irked me for a long time until I realized that it was my poor abstractions inherited from what I learned in other languages that lead to that state. As I established a more Go-minded approach, it became much more pleasant. To the point that I now find it desirable. I have been on Typescript/Javascript projects of late. Now that's a tedious error handling experience. I notice my colleagues have given up on error handling entirely due to how difficult it is.
- powerslacker 5y ago
  Same here. The Go approach is easy to read and eye compile. I can't stand exceptions now.
  - philosopher1234 5y ago
    >eye compile i like this phrase
  - eweise 5y ago
    It still suffers from being returned as a separate value so not easy to chain methods together.
    - robotastronaut 5y ago
      Method chaining, while possible, isn’t something I’d say is really encouraged in Go. Returned values should be handled explicitly. There are plenty of cases where it could be fine, but if a function can error, you wouldn’t want to chain anyways.

li2uR3ce 5y ago

I wish the number of "GopherCoins" put into "Dependency Management" was broken down into more pieces. Seems like dependencies are stupidly easy everywhere as long as you don't care about any kind of quality assurance. It's easy to get unvetted code running on your machines. Seems like I spend all my time trying to figure out if it's safe to depend on something while dependency management is usually purely a function of will it build/run. And yes, this is an everywhere problem and therefore Go can't be faulted. And yes everyone's pet language has solved it anyway. Thankfully no one uses anything but silver bullets today. /s Hard problems are still hard, I suppose.

convolvatron 5y ago
unless you can describe the properties you care about and build a machine to automatically verify them, then its not clear what you're asking for or how it could possibly be solved.
morelisp 5y ago
Does any other language's (common) dep tooling have something like the module proxy+sumdb? This is not sufficient but it's been a huge step forward for me to get some basic assurances that a) our upstreams are following at least base-level release practices, b) our team can't get spearphished, c) if we need to vet/blacklist/whatever, we have a single place in the infrastructure to do it.

todotask 5y ago

Didn't participate in the survey, I have previously used Swift, Ruby, Javascript, hesitate to use Crystal language (<1.0) since we need to iterate fast and less error prone, it's nature that Go is production-ready and fast built speed is important.

morelisp 5y ago

One surprising thing for me is that far more people use delve (a complex, third-party tool) than the race detector (one flag to tests you're already writing/running). I wonder if people just don't know they're running it?

Philip-J-Fry 5y ago
The second you run in debug mode with breakpoints in VSCode or Goland you're using Delve. I actually think VSCode uses Delve by default. It's the standard debugger. And it's not complex, most people are interacting with it though their IDE/Editor UI. Most people actually don't know about the race detector. It's not surprising at all that Delve is used more often.