Go Developer Survey 2021 Results | Hacker News Reader

Go Developer Survey 2021 Results

go.dev

106 pointsstevekemp96 comments

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.

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.

Same here. The Go approach is easy to read and eye compile. I can't stand exceptions now.

>eye compile

i like this phrase

It still suffers from being returned as a separate value so not easy to chain methods together.

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.

Yes, you would. “Chain all these methods and stop when you get to the first error” is an extremely common idiom. People write it all the time in lots of different languages. Go is unusual in that you have to spell it out.

Right, I know. You’re not wrong. I was meaning you wouldn’t want to do it in Go because it’s not idiomatic (and likely impossible as discussed). I use it all the time in other languages and don’t mind exception patterns, but method chaining feels very out of place when reading Go code.

> As I established a more Go-minded approach, it became much more pleasant.

Could you explain more by any chance?

Here's a good article form rob pike on one way to look at how Go can handle errors https://go.dev/blog/errors-are-values

Extra complexity to work around a shortcoming which ignores the fact that most users of a library only care about errors at the top level. Passing errors around manually when the machine could do it is a waste of time however it's dressed up.

>Passing errors around manually when the machine could do it is a waste of time however it's dressed up.

You, the writer, pass around errors manually so that the reader, who interfaces with the code 10x more than the writer, is able to reason about the code. Go's errors handling sucks, but I don't think everyone has the same opinion on why it sucks; I personally think that sum types should be added to the language making it impossible for errors to be silently ignored.

Exceptions, while convenient, require too much discipline to use cleanly.

Somehow after 25 years of coding I've never seen issues with using exceptions. Java is more explicit, Python gets the job done, and a good IDE helps in most cases anyway

every java team i've worked with handles their exceptions by making them runtime exceptions to bypassing the very thing you're pro-porting.

Unchecked exceptions work fine. Basic stuff like stream.map(f) is unusable when f throws any checked exception, so the Java world largely stopped declaring them. I consider it a miss in Java’s generics when lambdas and method refs were added.

I didn't say unchecked exception don't work. I was pushing against the assertion that 'Java is more explicit'; its not since java developers actively work to avoid using the damn feature being mentioned.

>Somehow after 25 years of coding I've never seen issues with using exceptions

Here is a link to Google's C++ style guide, which discourages exceptions with pros & cons:

https://google.github.io/styleguide/cppguide.html#Exceptions

It's your 25 years of coding, vs the several thousand man-months of Google's C++ codebase. That said, I don't deny that some people use exceptions with little mental overhead. I've been told about very high performance and readable trading software that made use of exceptions. My main gripe is that it they require discipline to use correctly, almost everyone uses them differently, and they make code harder to reason about. I would prefer a language that doesn't need an IDE to locally reason about some piece of code.

"Things would probably be different if we were starting over from scratch"

They concluded against them due to problems integrating into legacy code which is fair enough

Google's style guide is well known in the C++ community for not being that much worth to look into it.

As others mentioned, Google’s C++’s guide is simply not that relevant.

And don’t forget the principle use case of C++ - it is a low level language. While exceptions are pretty cheap overall, they can be expensive in some niche cases which do happen more often in C++ than in python.

I really haven’t heard a good case against exceptions per se — they make it possible to handle every error at an appropriate place. And bubbling the error up to possibly a much higher place is exactly the needed approach many times (e.g. returning a http error code on an unrecoverable mistake)

A lot of people ask this / answer this focusing on how to more easy collect / thread errors.

I think most of the time the real answer is to not have so many errors. You shouldn't return errors when API users make mistakes (as Java does); you should panic. You shouldn't return errors when something is "missing" (as Python does); you should return a zero value, and that zero value should sometimes still be useful.

In general you should be trying to write total functions, and picking your types so you can write total functions, and panicking rather than erroring if your preconditions are violated.

Yeah part of the reason it’s so tedious is that our application architecture is always Handler->Controller->Gateway or Repository->External Client, a pattern we first developed for Python. Errors mostly originate in the external clients and then have to be returned through all the layers.

When I read open source projects there is a lot more “PHP spaghetti” with business logic and storage interactions right inside handlers, which is indeed easier for error handling, but definitely has other problems.

Same, went back to python and I find it terribly annoying. You want to handle your errors, Go makes that simple, lots of other languages don’t

99.5% of the time I want to return a 500 to the caller. Other languages do that for free. Go makes it very manual.

I would argue that errors per se today are more than sufficient for this, but http.Handler is what's lacking. There's no idiomatic way to abort a multi-handler chain or to signal an error to a parent handler. This is the #1 value I get out of non-http.Handler-based frameworks like Gin.

(RPCs tend not to have a comparable number of layers of middleware and more support for reading "downstream" errors, though I do wish gRPC supported nested interceptors better.)

I sort of get what you're saying, but at the same time I don't. Any logic that depends on what the "next/child" handler returns can get errors either from the response itself or the context, depending on the approach I want to take (context is probably most idiomatic, but its own bag of worms (I say that because values in the context are all empty interfaces/any type, which is a pain when you want a concrete type)).

Unless there's some usecase I'm missing, since I haven't really touched Gin in awhile, and never got too crazy with what I wrung out of it.

> returns can get errors either from the response itself or the context

Not really!

To get errors "from the response" you're going to have to wrap the entire `ResponseWriter` to pass downstream, which is a) a lot of noise, b) can cause some subtle issues (you didn't really need to also implement Pusher, did you? you're sure no one already called Write(Header) on the thing you're wrapping, right? Ever heard of "requestTooLarger"?).

To get errors "from the context", the downstream handler and you need to agree on how to record them. The downstream handler gets your context, you can't get its. So you need to prepare error logging for it, or agree on the same higher-level handler to do it for both of you. You're in trouble as soon as you try to integrate an arbitrary handler - which is the entire point of using the standard handler interface, so why bother?

Or is there some magic pattern for either of these I'm missing?

Fair point. I don’t spend much of my time on middlewares - write once, use forever - but we do have pretty nested and layered architectures between the user-level handler and what it’s ultimately doing. That’s where it’s painful to thread the errors through.

Hold on. I'm still complaining about generics since its still not possible to write a generic map function on a struct.

Can you expand on that? I sort of divorced myself from golang right as the final generics implementation was starting to bake.

https://go.dev/doc/faq#generic_methods

You can't add generic parameters in methods. This means you can't implement a Map method on a slice, unless it's going to either A: return the same type as the slice or B: you explicitly decide at slice creation time what the one destination type you're going to have is and pass that as a parameter. This significantly limits "map" implementations, as well as "reduce". It does leave "filter" as a possible thing you can implement, since that's a hard-coded bool type.

via https://rakyll.org/generics-facilititators/

Example: https://go.dev/play/p/as3rT4fB3cn

  // Invocation:
  strings := []string{"1", "2", "3"}
  
  ints, err := Mapper[string, int](strings).MapErr(strconv.Atoi)

  strings = Mapper[string, string](strings).Map(func(s string) string {
    return s + "_suffix"
  })

  // Definition:
  type Mapper[T, U any] []T
  
  func (ts Mapper[T, U]) Map(f func(T) U) (us []U) {
    us, _ = ts.MapErr(func(t T) (u U, err error) {
      u = f(t)
      return
    })
    return
  }
  
  func (ts Mapper[T, U]) MapErr(f func(T) (U, error)) (us []U, err error) {
    us = make([]U, 0, len(ts))
    for _, t := range ts {
      var u U
      u, err = f(t)
      if err != nil {
        return
      }
  
      us = append(us, u)
    }
    return
  }

Which people like to bring up, and does make it "possible" to do this style, but takes a style I think is already crazily and uselessly verbose and makes it even more verbose, especially once you take that "strconv.Atoi" and try to inline a function there, at which points the types from the earlier generic instantiation get to appear again. Hope you didn't give your types good, descriptive names!

As a potentially useful technique in the general sense it makes good sense to know. As a solution to making map & reduce practical functions to use in Go, it makes me wonder just how much crap it takes for people to notice that just because a pattern is fun to use in one language, it isn't appropriate for another. I mean, how painful does it have to be, exactly?

Also, some people just insist on chaining, which this won't enable. (At least not without even more gymnastics.)

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

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

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.

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/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.

surprised they didn't have a 'support ukraine' banner

In their defense, they didn’t post a banner for every cause du jour, it was just the BLM banner. It could have been much more toxic.

Also, I see that they did quietly pull the banner back in November: https://github.com/golang/website/commit/8a86c4a6dbe5e8bdf59...

Great opportunity for a "current thing" banner service. Pop some javascript in your site and we'll add a banner to the top of any page for whatever you should be supporting at the moment.

I mentioned this in the sibling thread, but (to their credit) the Go maintainers didn’t post banners for the current thing, it was just BLM.

This is an excellent idea, both ironically and unironically, depending on where you stand.

Of course we'll have geo targeting to cater to a global user base and not stir up any unnecessary feelings. Kinda like when Bethesda put rainbows on their Western Twitter accounts but not their ME+Russia accounts.

> although I emphatically do

As someone who's gained a lot of clarity from what you've written on HN in the past, I was saddened to read this. Could you explain more about what your disagreement is?

> As someone who's gained a lot of clarity from what you've written on HN in the past

Flattering that you can even identify my handle (I don't even have it committed to memory).

> Could you explain more about what your disagreement is?

Sure.

1. The BLM organization (that the banner was asking people to donate to) seems shady. Leaders lead lavish lives (alliteration not intended) while it's unclear how these funds are actually benefiting the people they purport to advocate for.

2. The BLM movement is predicated on a false narrative: racist police are disproportionately killing black people. This is only true if you fail to account for obvious factors like crime rates and rates of police interaction. This is all propped up by cherry-picked and often highly-editorialized examples. America does have a problem with police killings, but it doesn't appear to be racist contra the BLM narrative, and 90+% of Americans already support police reform.

3. The BLM movement appears to have done far more damage than it has saved (and I'm not even talking about property damage). The BLM movement succeeded in pressuring police departments to minimize killings of black people, but the anti-police pressure is also very likely a primary driver in the violent crime surge which has resulted in an enormous net loss of both black lives and American lives more generally.

4. The ideologies that shroud the movement (which are variously called "critical race theory" or "wokeness" or "antiracism" or etc) reject what we might call "colorblind egalitarianism" in favor of "race consciousness" which invariably results in the reification of race. E.g., a translator is fired because he's white and the author he was to translate is black, or a white man is prohibited from volunteering on a board because there's already a white woman. Or the various strictures about who is allowed to open an Asian restaurant, host a geisha party, wear a Chinese-inspired prom dress, etc. Or the various associations of math, objectivity, literature, etc with "whiteness" or "white supremacy". I can go on and on. Of course, I this sort of "BLM racism" has also "legitimized" and animated right-wing racism, so I think we see a rise in racism on both sides of the aisle. I'm passionate about a post-racist world, and I think we're a lot worse off as a result of BLM and adjacent ideologies than we were 10 years ago.

Obviously I would support these points better if it were a longform post, but this is already very long for HN. Also, this is pretty terse (for sake of brevity), but I don't mean this to come across as combative. I'm happy to talk more about this, although given the controversial nature I'm not sure if this is the appropriate forum. :/

It's worth noting that there are several reputable efforts pursuing criminal justice reform independently of the problematic BLM organization or movement. https://www.openphilanthropy.org/focus/us-policy/criminal-ju... has a useful overview of groups you could look into.

Thanks for the link, I’ll look into them!

I just hated the banned because it was large and took away even more vertical space on my already limited screen. At some point about a full quarter of the screen was these fixed banners(!!) I userCSS'd it out, but they kept changing the HTML/CSS all the time so it kept breaking.

I also don't especially like BLM as an organisation or movement because I think they're ineffective at best and contra-productive at worst, but that's okay: I don't mind seeing messages I disagree with, including on programming sites – everyone is free to use their site to promote whatever message they wish. But it's unfortunate that any conversation on this topic tend to very devolve to "against BLM = against Black people = literally Hitler!!11" or even "against banner that makes the actual page to use = against Black people = literally Hitler!!11" Well, no: I criticise BLM because I broadly agree with their goals, and am frustrated with them they are, in my opinion, not doing the right things to address them.

It's that part that I find the most annoying: it's one thing if you put up a banner and we can have a conversation about whether this is the best way to address this, whether we should address it at all, and things like that. But if that's not possible things get pretty frustrating pretty fast.

Re (4), it seems to me like in order to change the existing influence of race on society you must first recognize it. I don’t see how everybody claiming to be colorblind when the systems and cultural institutions are structured to perpetuate racism could change anything. It seems like real color conscious changes must be made before color blindness is achievable.

I’m skeptical that there is much in the way of structural racism these days, but moreover, you can acknowledge a racist system while remaining colorblind. You can recognize that society racializes people without racializing people yourself. I don’t see how race conscious changes are helpful in the first place, much less are a prerequisite for colorblindness—if you have a racist system, it means the system isn’t colorblind, so just go straight to making it colorblind—why pass through a “color conscious” state (I also don’t understand the distinction between “color conscious” and “racist” except for connotations).

That said, I would be curious to understand what systems and cultural institutions you believe to be structurally racist and how they operate and so on.

I don’t have a developed enough view to argue this well. I’ve just been listening to a lot of Ezra Klein and engaging with a lot of leftist sources for a bit now and it’s made me much more sympathetic to these views, which previously seemed pretty empty and useless to me.

So, yea, I can’t really do it justice. It was sad for me because I’ve engaged with you in the past in defenses of Go and you made some really insightful points, so I began to count you as one of my HN heroes, and all my HN heroes (and other online heroes of mine) have left leaning politics from what I gather, so learning that you perhaps don’t required me to do some reconciling.

But yea, I can’t give a specific accounting of racist institutions.

I’m flattered, but I stay away from partisan politics as they’re often tribalistic and devoid of principle. I have a handful of left-wing positions (e.g., universal healthcare, environmentalism, etc) and I remain open minded about left-wing positions, but mostly I’m a liberal in the philosophical sense—free speech, equality, human rights, democracy, etc (I have a few right-wing positions as well, like a general preference for market-based solutions). The BLM adjacent ideologies conflict with my liberal values.

I share your opinion of the new official doc site, and also use https://godocs.io when I need online docs for something.

But as another alternative, a sibling comment mentions running the docs locally, which is my main way to access the docs now. For anyone else wanting to try it:

> godoc -http 127.0.0.1:6060 -play

(the "-play" makes the examples runnable)

Works like a charm!

godoc is not a built-in command, even for Go users. So your comment is not especially useful.

    go install https://pkg.go.dev/golang.org/x/tools/cmd/godoc

thats not a valid URL, in the context of "go install"

Yeah, good point. Still, it's not a hard install.

Apologies for forgetting that `godoc` isn't built in (and looks like jerf has fixed you up). I'd argue about what's "not especially useful", but "reasonable people will disagree", as they say!

That would be my only gripe as well - the old docs site was 10 times better.

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.

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.

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.

> 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.

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?"

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.

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.

> 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.

> 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.

> 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.

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.)

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#.

> 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.

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.

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.

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.

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.

I shudder to think at the wake of destruction left behind by all these freelancers that come in, implement a brand new service in their own language of choice without much regard to the tooling and ecosystem that the rest of the company is invested in, and then bounce, leaving everyone else to figure out how to support it in the future.

As an EM that strikes me as a very bad model to engage with contractors on, I'm surprised that it's such a common gig for you. But hey, more power to you, it must be fun getting to do a lot greenfield projects without the long-term responsibility.

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.

> 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.

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.

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).

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...

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.

> 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.

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.

> 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.

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.

> 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.

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?

The package was called iText on .NET 5.

The goal of the project was to read millions of PDFs (something like 9.7 million) and pull some of the text content from every other page.

> Did you try implementing what you did in C# just like Go?

No, but I'd be willing to be that it would be about the same. In hindsight, I created a strawman argument benefiting Go since I've only used C# occasionally for the last 7(ish) years and I'd never used iText before. Regardless of whether people thought Go was "better" (which wasn't my intention) the team opened up to the idea of looking at other tools/languages. Not long after when we started a new projects people asked questions like "would this be better if we used C++ or Rust"?

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.

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.

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."

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.

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.

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.

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?

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.

Reply on news.ycombinator.com