Live data from Hacker News

Go: Ten years and climbing

commandcenter.blogspot.com

121–130 of 193 posts

Re: Go: Ten years and climbing

#121
post #114

Earlier quoted context omitted.

> What about tools that statically analyze your code and allow you to be more productive? It may be possible to build more sophisticated and useful tools if the language is simple. This is a thing that's commonly repeated, but it's not that, well, simple. Having a simple syntax doesn't matter that much for tools once you have a reusable parser library. More important for tools is having a simple semantics . Do all bu…

But given the reality I observe, Go has already the top-tier tooling regarding IDE support and we are still waiting for the first production-ready RLS. Not that Go has the fanciest IDE products in the market or those tools have been invested heavily for Go, but it is obvious to me that such tools are abundant in the Go ecosystem that can be readily employed by every editor vendor. To put it in an ironic way, assuming…

We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs.

That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semantics like C++ does) can support autocompletion with comparable levels of implementation effort.

Re: Go: Ten years and climbing

#122
post #102

Having dealt with enough spaghetti code over the years (just a few of industry experience, and some more years of academia), I understand what Go's strengths are. It's an opinionated language that stops users from being too clever or writing code that's too complex. That said, I've always hated the trends that have brought Golang into popularity. The engineers I've felt who could benefit from Golang the most could al…

> I'm a much bigger proponent of languages such as Rust or Haskell which give the developer the _tools_ to ensure their own data integrity As a big Rust proponent, I don't think it makes sense to invoke Rust here. The goal of Rust is to provide a more secure low-level foundation for software; any tools it provides to "ensure data integrity" are in service of that end, and pale in comparison to the sort of correctness…

Kudos for this insightful comment on the respective merits of Go, Rust and Haskell.

Re: Go: Ten years and climbing

#123
post #117

Earlier quoted context omitted.

And that's an intentional misreading of the Go devs. Read the Go Programming Language or any number of discussions by the guys behind Go and it's obvious that they care about their craft and care about writing real, working applications, while at the same time having a better understanding of what your application is doing. In their view the way to do that is through simplicity, but it's not a design decision intende…

> Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons? It was Pike himself that stated that as a goal for Go at one of the early Goconfs, because new Googlers aren't skilled enough to pick up C++, Java or Python. If you wish I can track it down for you.

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

That's the quote people like to jump on. You could read it as humility or a nod to other languages, but it probably wasn't intended to be read as "we've designed a stupid language", and even if Pike agreed with that reading, he probably wouldn't agree that keeping programmers mediocre is a goal or a side-effect of a non-brilliant language. Don't mean to put words in his mouth, but the above quote obviously isn't meant to support anything like:

The criticism of Go being presented is that it's intentionally underpowered so as to make it possible for poor developers to verbosely muddle their way through to developing working real applications without actually becoming better.

Which is an extreme criticism, but it's a pretty common assumption in most of these discussions. I mean, look at the most upvoted posts in this thread.

Re: Go: Ten years and climbing

#124
post #70

I evaluated Go a few months ago for a web project, but it seemed as if there was a lot of manual work involved in mapping objects in and out of a MySQL database and in and out of JSON (basically, 50% of my day-to-day back end work). It just seemed too arduous. The second thing that bothered me was that an edge-case bug in one of my HTTP handlers paniced the app. If that had happened in production while under load, ma…

Go's HTTP server handles each request in its own goroutine, and any panics encountered are automatically recovered from. Nothing special needs to be done to prevent a panic from taking down the server.

Interesting. I had a panic take down my service,but I think I was trying fasthttp.

Re: Go: Ten years and climbing

#125
post #114

Earlier quoted context omitted.

But given the reality I observe, Go has already the top-tier tooling regarding IDE support and we are still waiting for the first production-ready RLS. Not that Go has the fanciest IDE products in the market or those tools have been invested heavily for Go, but it is obvious to me that such tools are abundant in the Go ecosystem that can be readily employed by every editor vendor. To put it in an ironic way, assuming…

We aren't talking about autocompletion. The post upthread describes "the tools to ensure...data integrity": i.e. type system or static analysis features to prevent bugs. That said, if you're trying to argue that autocompletion is more difficult to implement for Rust compared to Go because Go is simpler by some metric, then I disagree there too. Any static language (well, one that doesn't intertwine parsing and semant…

Then I am curious about what makes RLS or the alike so hard to onboard? Common IDE features like reliable and responsive "jump to definition", "Find all references" and "Renaming symbols" are 90% of all I would ask for. Do Rust devs have less attention to the area?

Re: Go: Ten years and climbing

#126
post #107
post #99

Earlier quoted context omitted.

Which language released in the last 10 years is more popular then ? Golang is arguably niche and does not offer the huge flexibility and ecosystem of say Python, so i am pretty sure it will never come close to that, but there are a good number of usescases where it arguably is the best choice.

Scala, with 164 jobs in London and 225 nationwide, has been around for about the same time as a production-quality release. I raised the point because I think Golang's coverage on HN is disproportionate to its significance in the job market.

London is about 'fintech', so Scala is in great demand. SF Bay Area is about 'webscale' so Go is popular, as it established as The Cloud Automation language. And HN crowd is mostly leaning to SF. OTOH you wouldn't find a great demand for Oracle DBA or C# skills in The Valley, and that's not because they are not in great demand somewhere else - maybe even basically everywhere else like C#.

Places lean to some niche or other, and vice versa. Apple places its growing hardware teams in Texas despite new campus in The Valley and all that. Why? Because Austin is very much hardware place.

Re: Go: Ten years and climbing

#127

Earlier quoted context omitted.

>I will say though, dependency management in Go is hell. I wish Go had something like Cargo. This is the number one thing that has kept me from going full on Go. The killer feature of Node was NPM, not Javascript. Unless Golang comes up with something comparable it will forever remain niche.

(NOTE: I am not a gopher) I thought godep was that? It's marked as suitable for production now, and I think official as of their next release. https://github.com/golang/dep

First a note, godep is a different tool then the one you mean [1], that does the same.

> dep still has nasty bugs, but in general these are comparable or fewer to other tools out there.

(From the Github readme)

I started a project about two months ago and wanted to use Dep, however there were a few show stopping issues for that. Most prominently Go has issues with upppercase/lowercase repositories, meaning if one of your dependencies imports github.com/Sirupsen/logrus, and you or another dependency imports github.com/sirupsen/logrus your code won't compile, no matter if you are on a case sensitive system or a case-insensitive system. [2] The aforementioned logger made a switch in the naming which caused problems while most were migrating the import. The docker distribution in its latest stable version still uses uppercase, while others use the lowercase.

Dep follows the Go specifications and at the moment just throws an error, before, they didn't handle it at all.

So I had to resort to a different dependency management for now, which did some linking to fix the situation.

[1]https://github.com/tools/godep [2]https://github.com/golang/dep/issues/1010

Re: Go: Ten years and climbing

#128
I love Golang, but I'll just comment on that:

> It's worth stating that the language is called Go; "golang" comes from the web site address (go.com was already a Disney web site) but is not the proper name of the language.)

You already have a hugely popular game called Go (WeiQi/Baiduk). It just adds confusion to queries to call the language Go instead of Golang. Even the #go channel on freenode has a disclaimer that it's not about the language. It's like calling your language football.

Re: Go: Ten years and climbing

#129
post #117

Earlier quoted context omitted.

And that's an intentional misreading of the Go devs. Read the Go Programming Language or any number of discussions by the guys behind Go and it's obvious that they care about their craft and care about writing real, working applications, while at the same time having a better understanding of what your application is doing. In their view the way to do that is through simplicity, but it's not a design decision intende…

> Do people really believe that individuals such as Rob Pike, Ken Thompson, and Brian Kernighan are just trying to propagate Blub, the language, so that all devs are lowest common denominator morons? It was Pike himself that stated that as a goal for Go at one of the early Goconfs, because new Googlers aren't skilled enough to pick up C++, Java or Python. If you wish I can track it down for you.

He didn't say they weren't skilled enough to learn those languages - in fact he explicitly said they likely would know those. There's clearly a ton of evidence showing that Googlers can learn them, but having a short learning curve for the new language they're introducing still seems useful.

Re: Go: Ten years and climbing

#130
post #128

I love Golang, but I'll just comment on that: > It's worth stating that the language is called Go; "golang" comes from the web site address (go.com was already a Disney web site) but is not the proper name of the language.) You already have a hugely popular game called Go (WeiQi/Baiduk). It just adds confusion to queries to call the language Go instead of Golang. Even the #go channel on freenode has a disclaimer that…

To be fair many simple names are overloaded. Amazon, Rust, C, Python, ... even football. It's normal.
Post reply on HN