30 ms·
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 co
by 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 agoYeah 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 agoDefinetly 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 agoCompanies 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.