Why Go is doomed to succeed • Hacker News Board

Re: Why Go is doomed to succeed

#101

Post by fauigerzigerk » Sat, Jun 13, 2015, 6:14 PM UTC

>TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community.

I think this premise could not be more wrong. The open source community is not a project team, and open source project teams are very likely much more homogenous and stable than teams working on commercial software.

Yes there may be non core contributors, but if contributions are not up to standard, they are simply rejected. If that means slower progress an open source project can live with that. A commercial project can not, because it has deadlines.

Re: Why Go is doomed to succeed

#102

Post by vorklerta » Sat, Jun 13, 2015, 6:15 PM UTC

Dewie3 wrote: post #74

pron wrote: post #31

Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…

When pron posts on a thread about lang X, it tends to be 30% about lang X and 70% raving about the JVM platform.

More like 90% blindly advocating the superiority of Java. Does he ever sleep?

Re: Why Go is doomed to succeed

#103

Post by aaggarwal » Sat, Jun 13, 2015, 6:17 PM UTC

aaggarwal wrote: post #32

masklinn wrote: post #26

Earlier quoted context omitted.

> it looks like Go hits a sweet spot between C and Java? If your sweet spot is 90~95% java and 5~10% C.

That's not really my sweet spot, but if it have such a strong inclination towards Java, then would it be much easier for Java programmers to move to Go compared to C programmers? And, what about python programmers, how would Go be for them?

I found this discussion very helpful. Thanks!

Re: Why Go is doomed to succeed

#104

Post by garfij » Sat, Jun 13, 2015, 6:22 PM UTC

rwmj wrote: post #18

sapek wrote: post #7

Whether you like Go or not depends on whether you think of software development as engineering or as craft.

More like "... whether you've used any more modern languages than C" (such as ML and many other functional and research languages).

I like how ML is more modern than C, but they were both released in the early 70s.

Re: Why Go is doomed to succeed

#105

Post by microtonal » Sat, Jun 13, 2015, 6:23 PM UTC

tptacek wrote: post #90

bkeroack wrote: post #8

Earlier quoted context omitted.

I would word it slightly differently--in Go you are free to express yourself in exactly one way: the idiomatic Go way. Anything else will be painful (a good clue is if you find yourself using reflection frequently).

That's true, but it's also (sometimes) liberating. In extremely flexible languages, you can find yourself burning lots of time finding the most "elegant" way to express simple concepts, like "how am I going to write this SQL column to this series of DIVs". Not coincidentally, Golang sucks at this problem. But there is something about writing in Golang that makes it easier to dive into meatier code. For instance: I've…

With Ruby, I kept refining the assembler until the DSL looked identical to normal X86 assembly (I even hooked the bracket operators to make them behave like dereferences). With Golang, I quickly moved past the assembler into an IR and a compiler.

Same experience here. I am working on a neural net dependency parser and pretty much started C++ and Go implementations in parallel, because this was one of my first larger Go projects and I had my doubts about using Go for this.

In the meanwhile, the Go implementation is a complete and fast parser (the number crunching is done using OpenBLAS via gonum), which I now use for research. In C++ I am still tweaking the abstractions for the basic stuff (word embeddings, transition systems). Of course, I could make a simple, straightforward implementation in C++, but the language encourages you to finetune the abstractions and you have to the choice between template-heavy/light code (with its respective downsides).

I also found that Go encourages me more to break stuff up more in different packages. In C++, every separate library means new build machinery, some way to roll it out on systems, etc. In Go it's as simple as creating a new repository and adding imports.

Re: Why Go is doomed to succeed

#106

Post by Skunkleton » Sat, Jun 13, 2015, 6:24 PM UTC

ilurk wrote: post #86

I'm curious about two things. (1) where does Rust fit in this? (2) and if Go is lacking in the concurrency department and loses to Erlang in latency. Why don't people use Erlang/Elixir for servers and Python/etc for client side?

In reply to your first question, I don't think it does. Go and Rust were both initially marketed as "systems" languages, but in reality they make very different design trades. I would say that Go lines up more with Java or C# than it does with C or Rust. I would guess that having both Rust and Go in your toolkit will be a benefit in the future.

Re: Why Go is doomed to succeed

#107

Post by meatysnapper » Sat, Jun 13, 2015, 6:25 PM UTC

api wrote: post #71

modulus1 wrote: post #61

Go's success has me confused. My team enjoys using Go, but to me it feels like i'm a prisoner. The designer's slavishly followed opinions are laser focused on reducing variation across go codebases. There's definitely less to learn than most languages. Unfortunately, sometimes the blessed way of doing things doesn't work well for your problem and not only are you left with a hammer to cut the wood, but making a saw i…

The article hits on this but doesn't bring up Google's high turnover rate. Google is a resume tick box. Go over to AngelList and look at lists of startups. Take a drink every time you see 'worked at Google' listed as a qualification. You'll be destroyed in an hour or so. Thus people get jobs at Google, put in a year or two, and go off for a higher paying and/or sexier job or a startup of their own. Go is laser focuse…

For any big company, you end up with hordes of lazy or worse, very bad programmers. You need a COBOL-like language to allow them to produce things and not mess up things too badly.

GO fits the bill.

Re: Why Go is doomed to succeed

#108

Post by yo-code-sucks » Sat, Jun 13, 2015, 6:27 PM UTC

latch wrote: post #36

I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems. I really like it. To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic langu…

Thumbs up!

Re: Why Go is doomed to succeed

#109

Post by vorklerta » Sat, Jun 13, 2015, 6:29 PM UTC

pron wrote: post #73

vorklerta wrote: post #58

Earlier quoted context omitted.

Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. Since switching away from Java we don't miss any of the features you've listed. The problem with Java is the mountain of bloated frameworks which have become standard over the last 10+ years - things like Spring, Hibernate etc. which new developers are expected to learn. With Go new developers which join the team a…

> Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. That's not true. All JVM libraries expose a ton of monitoring information through the standard JMX interface at every level of the stack, from deep inside the JVM, through logging framework, DB drivers, schedulers etc., and all the way through the application. And I can only guess that you've yet to encounter Go'…

> A new Java project is as pristine as a new Go project

The problem is that most Java developers have become so familiar with and attached to bloated frameworks that they simply aren't interested in trying any other way. They have a lot of time and effort invested into mastering these frameworks. "Let's use Spring for that", and endless talk of the "persistence layer" for even the most basic apps.

Re: Why Go is doomed to succeed

#110

Post by microtonal » Sat, Jun 13, 2015, 6:31 PM UTC

scriptproof wrote: post #48

gamesbrainiac wrote: post #6

> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community. Very true. This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but ra…

But you are lucky if your project has a large group of programmers. There is more probably a large group of projects with a small group of programmers. There are also some large projects: Linux, KDE, LibreOffice, VLC, LLVM, etc... and none is written in Go.

This is a weird argument to make, since Go was first introduced in 2009 and the first stable version was released in 2012. All those projects precede Go by a decade or more.

Also, despite Go's short existence, there are already a surprising number of large Go project (Docker, Syncthing, etcd).