Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go: Ten years and climbing

commandcenter.blogspot.com

Post reply on HN
Print view View original

111–120 of 193 posts

Re: Go: Ten years and climbing

#111

Post by elgenie »

aaron-lebo wrote: post #104
elgenie wrote: post #96

Earlier quoted context omitted.

That seems to be an intentional misreading. 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.

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…

I personally think Go and Java were developed for the same audience with similar intentions and language designer skill and are going to face the same criticisms.

For natural languages, the research seems to indicate that information is transmitted at the same rate when the languages are spoken (e.g. http://muse.jhu.edu/article/449938/pdf) with faster speaking rates compensating for higher verbosity. In terms of writing systems, though, there's definitely a ton of human potential being frittered away on learning Chinese characters and esoteric English spelling rules, but not much that can be done about it even if the Korean alphabet and German rule-adhering regularity are superior. Programming languages are all faster to learn and are iterated on much more quickly and so the possibility of realistically affecting change leads to ideological arguments.

Re: Go: Ten years and climbing

#112

Post by kjksf »

cutler wrote: post #97

For a language that's been around for 10 years Golang's adoption rate is still pretty low. Searching Indeed.co.uk's API by job title there are currently 25 Golang jobs in London compared with 29 Perl, 188 Ruby and 511 Python. For the UK as a whole it's 34 Golang, 57 Perl, 276 Ruby and 821 Python. Golang has a long way to go yet IMHO.

Your stats seem to be wrong.

https://www.indeed.co.uk/jobs?q=golang&l=London%2C+London returns 194 Go jobs for London area

Re: Go: Ten years and climbing

#113

Post by aaron-lebo »

elgenie wrote: post #111
aaron-lebo wrote: post #104

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…

I personally think Go and Java were developed for the same audience with similar intentions and language designer skill and are going to face the same criticisms. For natural languages, the research seems to indicate that information is transmitted at the same rate when the languages are spoken (e.g. http://muse.jhu.edu/article/449938/pdf ) with faster speaking rates compensating for higher verbosity. In terms of wri…

That was a especially informative reply. Thanks.

Re: Go: Ten years and climbing

#114

Post by e3b0c »

pcwalton wrote: post #106
shurcooL wrote: post #82

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. You talk about giving the developer tools, but those tools can be augmentations on top of the basic building block that is the language. That way, anyone can build tools for their needs, without complicating the lives of others. No need to b…

> 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 same popularity, I think a quality language tool for Rust has more potential to be monetized (just like those for C++) than those for Go, because the former has much higher barrier to entry and hence less competitors.

Re: Go: Ten years and climbing

#115

Post by mathw »

chi18 wrote: post #78
h8liu wrote: post #56

Earlier quoted context omitted.

an army of "toddler" developers can overthrow a single hero in terms of productivity, and using a "toddler" programming language makes sure that newly joined "toddlers" can understand (and also maintain or upgrade) existing code, so that the army can just keep growing.

> an army of "toddler" developers can overthrow a single hero in terms of productivity Depends on what you mean by toddler. Golang devs imo are not toddlers. The point seemed to be that golang devs could just learn to write C, which is valid. So could Rust developers. But if that was the goal, you'd think both groups would only be using C. When I think of "toddler" developers, I think of interns being hired into a co…

And that disaster situation is going to happen regardless of what language they happen to be working in.

Re: Go: Ten years and climbing

#116

Post by makapuf »

kenhwang wrote: post #81
why-el wrote: post #53

Earlier quoted context omitted.

> As a simple language to wire pieces together, Golang is fine, but it really doesn't give you the tools (imo) to be productive for anything more complex than simple apps. It's a great alternative to JS (again imo), but not something I'd like to write. How do you address its popularity in the field of cloud computing then (which I presume you would agree is pretty complex)? This was mentioned in ample detail by Rob i…

The language that appeals to the masses with low barrier to entry in a niche always wins the popularity contest in that domain. I attribute it to herd mentality; assuming skill has a standard distribution, the average developer herd gets a massive head start. You can see the idiot friendly language eclipse in popularity in other domains too even though "better" alternatives exist: - elegant general purpose: python ov…

Some of the dumber but more popular solutions here are just older ones. And please refrain from starting unsubstantiated flamewars. What's next, editors: emacs over vi ? Colors: black over white ?

Re: Go: Ten years and climbing

#117

Post by pjmlp »

aaron-lebo wrote: post #104
elgenie wrote: post #96

Earlier quoted context omitted.

That seems to be an intentional misreading. 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.

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.

Re: Go: Ten years and climbing

#118

Post by mathw »

cutler wrote: post #107
kayoone wrote: 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.

Significance in the job market has never correlated well with how excited people get about things.

Hacker News is about stuff we're interested in, which is not necessarily stuff we get employed to do.

Re: Go: Ten years and climbing

#119

Post by ubercow »

DelightOne wrote: post #85
ubercow wrote: post #42

I love Go for the concurrency and awesome cross platform support, but my biggest complaint about Go is still the forced GOPATH. I know this is super nitpicky, but I like to keep work and personal code completely separate and changing GOPATHs is very frustrating. With the introduction of `vendor` and software like glide and dep tool, you no longer have to store your sources in `$GOPATH/src`. Since dep/glide are also r…

Completely separate = dont allow dependencies between or one is base and second auguments and depends on base or dont allow changes to one of them? How would your ideal system look like? What is your use case? Sidenote if it helps there is a default gopath location if its not defined: https://golang.org/doc/go1.8#gopath

My ideal system is: clone a repo, run `go restore` to fetch dependencies and then `go build` to spit out a binary or `go run` to quickly start the main function.

Nothing from outside the repo can effect that build. Likewise anything inside the repo can’t effect the outside.

Compartmentalizing each project makes builds more reproducible and more obvious. If anyone else clones the same repo and runs the same commands, they should get the same result.

Re: Go: Ten years and climbing

#120

Post by mathw »

pointytrees wrote: post #100
shrumm wrote: post #21

My introduction to Go was pretty recent about 2 years ago and we went all in. We had an internal tool that started out as a test MVP written in python. Demand was growing fast so a year later it was an absolute mess of tech debt. We knew a significant refactoring was needed and figured the best thing to do was to just redesign and build from scratch. One of the guys had played with Go in his spare time so convinced a…

I sometimes feel crummy to force my preferences on other developers I bring on board. For example, most of my work is PHP, so all of our repo's use spaces, and braces on newlines. When a new dev comes on board, they must follow that format. Funny thing is with GO, I don't mind in the slightest that go fmt . is tabs and braces on the same line. What is so much more important to me is consistency. Go has done a stellar…

I have mixed feelings about the language itself, and some of its tooling (GOPATH just makes no sense to me whatsoever, and I've not spent enough time hacking Go projects to understand why it wouldn't be better to just have something like Cargo to handle dependencies), but I firmly believe that go fmt might be the biggest contribution to the language tooling world I've seen for a long time.

We've had autoformatters before, but they were always customisable things, sparsely used. Go shipping a formatter with the core distribution? Go projects routinely adopting it as a requirement for contributors? One standard format defined from the start?

Knockdown stuff. All those pointless arguments about coding style, gone. All that worrying about how to lay things out, gone. Just run go fmt and move on.

I have now become entirely reliant on rustfmt when I'm writing Rust, and I love it. I just write a total horrible mess, press save and it magically becomes neat and lovely.

I wish I had something that powerful operating in my C# environment at work.

Admittedly, at the moment I also wish my C# environment at work wasn't laden with iron-clad layout rules that the tooling isn't capable of fixing for me. All private members must be after the public ones, but static private ones need to be before the instance ones, and all properties go first regardless of accessibility (although remember the private properties have to go after the public properties). And usings must go inside the namespace definition, in alphabetical order except System.whatever, which all come first (in alphabetical order). And you can't split a function argument across multiple lines unless it's a lambda. Microsoft's C# style guide? What's that and why would we care and no it's not prescriptive enough anyway.

It's enough to make your head spin. Good thing I'm only there for six more days.

Give every language a formatter, as standard, and let's just be done with it.

Post reply on HN