[HN Gopher] Go Developer Survey 2021 Results
___________________________________________________________________
Go Developer Survey 2021 Results
Author : stevekemp
Score : 83 points
Date : 2022-04-20 13:58 UTC (9 hours ago)
(HTM) web link (go.dev)
(TXT) w3m dump (go.dev)
| svnpenn wrote:
| 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
| throwaway894345 wrote:
| 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.
| ngngngng wrote:
| 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.
| throwaway894345 wrote:
| 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.
| klabb3 wrote:
| 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.
| philosopher1234 wrote:
| > 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?
| throwaway894345 wrote:
| > 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. :/
| zozbot234 wrote:
| 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.
| blaxis wrote:
| surprised they didn't have a 'support ukraine' banner
| throwaway894345 wrote:
| 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/8a86c4a6
| dbe5e8bdf59...
| ratrocket wrote:
| 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!
| svnpenn wrote:
| godoc is not a built-in command, even for Go users. So your
| comment is not especially useful.
| ratrocket wrote:
| 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!
| jerf wrote:
| go install https://pkg.go.dev/golang.org/x/tools/cmd/godoc
| svnpenn wrote:
| thats not a valid URL, in the context of "go install"
| endorphine wrote:
| That would be my only gripe as well - the old docs site was 10
| times better.
| jerf wrote:
| 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.
| morelisp wrote:
| 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 wrote:
| 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.
| closeparen wrote:
| 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.
| eweise wrote:
| Hold on. I'm still complaining about generics since its still
| not possible to write a generic map function on a struct.
| monocasa wrote:
| Can you expand on that? I sort of divorced myself from golang
| right as the final generics implementation was starting to
| bake.
| jerf wrote:
| 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.
| robertsdionne wrote:
| 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 }
| randomdata wrote:
| 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 wrote:
| Same here. The Go approach is easy to read and eye compile. I
| can't stand exceptions now.
| philosopher1234 wrote:
| >eye compile
|
| i like this phrase
| eweise wrote:
| It still suffers from being returned as a separate value so
| not easy to chain methods together.
| threatofrain wrote:
| > As I established a more Go-minded approach, it became much
| more pleasant.
|
| Could you explain more by any chance?
| recov wrote:
| 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
| nprateem wrote:
| 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.
| nemothekid wrote:
| > _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.
| nprateem wrote:
| 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
| jatone wrote:
| every java team i've worked with handles their exceptions
| by making them runtime exceptions to bypassing the very
| thing you're pro-porting.
| closeparen wrote:
| 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.
| morelisp wrote:
| 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.)
| dhagz wrote:
| 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.
| morelisp wrote:
| > 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?
| closeparen wrote:
| 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.
| capableweb wrote:
| > 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.
| lpapez wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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 wrote:
| > 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 wrote:
| 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.)
| nawgz wrote:
| > 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.
| HL33tibCe7 wrote:
| 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 wrote:
| 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 wrote:
| > _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.
| LukeShu wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| cactus2093 wrote:
| 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.
| Philip-J-Fry wrote:
| 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.
| jerf wrote:
| 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.
| sibit wrote:
| > Do people not regularly question what language to use when
| starting a project?
|
| For me, it depends -\\_(tsu)_/-
|
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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?
| sibit wrote:
| 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"?
| randomdata wrote:
| 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.
| Jenk wrote:
| 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?"
| silisili wrote:
| > 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 wrote:
| 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 wrote:
| 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).
| lifefeed wrote:
| 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 wrote:
| 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."
| endorphine wrote:
| 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.
| Zababa wrote:
| 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.
| li2uR3ce wrote:
| 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.
| morelisp wrote:
| 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.
| convolvatron wrote:
| 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.
| todotask wrote:
| 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.
___________________________________________________________________
(page generated 2022-04-20 23:02 UTC)