Live data from Hacker News

Eleven Years of Go

blog.golang.org

71–80 of 170 posts

Re: Eleven Years of Go

#71
post #66

I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

Marketing & branding -- esp to enterprise IT -- is really not in the Go team's wheelhouse.

A third party could take it on, but that would require a different governance structure for the project. Outside entities have little influence now.

Re: Eleven Years of Go

#72

Earlier quoted context omitted.

> The most frustrating thing about Go isn't even the language, it is the community for me. It is very business/corporate focused. Everything is all about Kubernetes/cloud. I apply for conferences/meetups non-stop, but never have any luck. It is always the same company reps. I am envious of the Rust community here, but maybe grass is always greener on the other side? As someone who's been writing Go full-time for over…

I think you hit on something that so many miss and it's the tooling for the job, as it were. Go and Rust are fundamentally different tools designed for fundamentally different tasks. While it's possible to use them for the same tasks, it's much more difficult. I would HATE writing a full and secure operating system in Go, while writing back end systems in Rust is doable, but at an unnecessarily slower pace than Go.

Agreed. Comparing them does a disservice to both languages—they're tools with separate niches. It's fair to compare their package management strategies or communities, but the languages themselves are too different.

Re: Eleven Years of Go

#74
post #66

I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

There's a big gap in trends between new-wave "tech companies" and "enterprise companies". It's hard to cleanly define these categories aside from culture, but Go is plenty popular in the former (along with lots of other languages), and Java remains prevalent in the latter. Sounds like maybe Python spans both.

Re: Eleven Years of Go

#75
post #3

I had different opinion than guy who joined the Go team in 2019 (Ian Lance Taylor). I was banned from their github repo, my AdSense sites were removed from Google's index, my AdSense CPC dropped by 2/3. My github account was "flagged" aka disabled from being seen in public. I was on github for 7 years. I received nonsensical "not in accordance to policies" messages from AdSense all of a sudden when that happened aka…

You may find this useful

https://en.m.wikipedia.org/wiki/Delusional_disorder

Re: Eleven Years of Go

#76

Earlier quoted context omitted.

Looked for codegen utils on Github a while back -- but found nothing useful. Any public utils you'd recommend?

I love using text/template directly for codegen. Its really easy in my experience to create sophisticated tools using it + some go functionality. The trick is learning what gen problems are best solved in text templates and whats best solved in go functions. A big advantage of using text/template for codegen is you can just write the code you want to generate and it looks like real go code. Really easy to maintain co…

Sounds similar to my use case. Two snags to work around when generating Go source:

1. The {{}} pairs confuse editor syntax coloring (in emacs, anyway).

2. Expansions that introduce or drop line breaks will cause the runtime/dlv to report line numbers that disagree with the pre-gen source you need to correct.

Re: Eleven Years of Go

#77

Earlier quoted context omitted.

Next on the list: error handling. Which is absolutely not a problem, and works very very very well as is. Then again, one can hope that maybe by 2025 :) https://github.com/golang/go/issues/32437 https://github.com/golang/go/issues/32437#issuecomment-51203... https://github.com/golang/go/labels/error-handling

My opinion on this is not popular but I absolutely love the way go handles errors. I love that errors are returned by functions and then immediately handled. I prefer it to the try/catch paradigm where the error is maybe handled somewhere up the call stack

Well, the point is not that "handle errors immediately" is bad. It's that "tuples are a poor way to do it". A Result type makes you handle errors immediately, but also precisely models what you need (i.e. you don't even get the choice to use an invalid returned value).

Re: Eleven Years of Go

#78
post #66

I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

There's a big gap in trends between new-wave "tech companies" and "enterprise companies". It's hard to cleanly define these categories aside from culture, but Go is plenty popular in the former (along with lots of other languages), and Java remains prevalent in the latter. Sounds like maybe Python spans both.

[deleted]

Re: Eleven Years of Go

#79
post #66

I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

There's a big gap in trends between new-wave "tech companies" and "enterprise companies". It's hard to cleanly define these categories aside from culture, but Go is plenty popular in the former (along with lots of other languages), and Java remains prevalent in the latter. Sounds like maybe Python spans both.

If I look for golang jobs in NYC I see just one job in the whole city. Sure a few more in the surrounding area and a bunch remote, but just one job.

https://www.dice.com/jobs?q=golang&location=New%20York%20Cit..., NY,%20USA

Re: Eleven Years of Go

#80
post #66

I love Go, but the lack of adoption in business world is a huge problem. Seems to be a niche for infrastructure and utilities. 99% of the jobs I see are Java or Python.

My last two jobs were in Fortune 500 and were 100% Go ( backend services / API ).
Post reply on HN