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

The March Towards Go

zef.me

Post reply on HN
Print view View original

161–170 of 217 posts

Re: The March Towards Go

#161

Post by micro_cam »

cgag wrote: post #62
jamescun wrote: post #45

Earlier quoted context omitted.

It is a rather vauge statement and could have used some clarification; however Go does make writing network protocols very simple, and building something like a gossip protocol based system with a leader election system is doable in a week. Even quicker if you use some of the existing distributed systems libraries for Go.

What does Go do that makes writing network protocols simple?

All of the HTTP, socket, encryption, compression etc libraries have a really clean, consistent design based around stackable reader and writer interfaces. This makes it really easy to combine things, swap out transport layers etc.

Go routines and channels are also nice for handling concurrent requests though I find myself using mutexes more than channels for finer grained control.

Re: The March Towards Go

#162

Post by aikah »

Udo wrote: post #61

This sums up the problem: > Not looking at Go yet? It may be a good time to do so now — everybody else is. That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat". Personally, I thought Node.js was a terrible platform for serving dynamic web…

> That's going to be a large albatross around Go's neck, as it has been around node.js', and Rails before that. Large amounts of developers flocking to a new thing because "this is the thing to use now and if you don't you're dead meat".

TJ's blog post is basically like if DHH ditched Ruby/Rails for Go.

> Personally, I thought Node.js was a terrible platform for serving dynamic web sites. It is, however, a great platform if you need to make a reasonably performant general server with minimal effort (such as a message broker for example).

Totally agree with you,nodejs is not a silver bullet.

Re: The March Towards Go

#163

Post by crawshaw »

bsaul wrote: post #14

I've often heard that Go founder were surprised that Go seemed to replace python more than C++ or C which were the initial targets. By judging from the given examples it seems that it isn't the case : people seem to come to Go when they start looking for performance. Instead of writing C modules and using them from python, they just switch everything to Go. I'd be curious to know how many start ups prototype their fi…

You are probably thinking of Rob Pike's talk, Less is exponentially more:

http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Re: The March Towards Go

#164

Post by aikah »

jgrahamc wrote: post #23
bsaul wrote: post #14

I've often heard that Go founder were surprised that Go seemed to replace python more than C++ or C which were the initial targets. By judging from the given examples it seems that it isn't the case : people seem to come to Go when they start looking for performance. Instead of writing C modules and using them from python, they just switch everything to Go. I'd be curious to know how many start ups prototype their fi…

We, CloudFlare, write a lot of new stuff in Go. It works well for our use model: highly-concurrent networked stuff. I've just been rewriting a thing that was in a monstruous mixture of PHP/Python into a single Go program.

Is your front-end/admin panel/... written in Go too? Because when noobs hear "We use Go",they'll think you're using that to generate webpages,CRUD apps,or write CMSes.

Re: The March Towards Go

#165

Post by randallsquared »

DCKing wrote: post #142
randallsquared wrote: post #108

Earlier quoted context omitted.

Compared to Scala, Go is incredibly simple, both to learn and to use. If you don't have a lot of experience with Java and the JVM, Go also avoids that whole avalanche of complexity, apart from Scala itself.

> Compared to Scala, Go is incredibly simple, both to learn and to use. Probably true. Go has a far more simple language specification, but it's not as if Scala is particularly alien. > If you don't have a lot of experience with Java and the JVM, Go also avoids that whole avalanche of complexity, apart from Scala itself. Why is Java or the JVM an 'avalanche of complexity' for Scala?

I meant only that if you want to use Scala, you'll inevitably have to also know Java. It's two languages for the benefit of one. The JVM comes with its own issues: which JDK do I use[1]? What happens when one library I want to use recommends a different JDK than another library I want to use? Build tools questions: ant, maven, gradle? Oh, I need to learn Groovy, too? Three languages for the benefit of one. Yay.

There's just an enormous amount of stuff to learn, and most of it is required-but-incidental; none of it (except Scala, in our example) is an inherently necessary part of getting from learning to a production system running Scala on the JVM, but you will end up having to become conversant with many of these things, and probably dozens of similar infrastructure and tooling systems.

[1] Haha. I was thinking this was mainly between Oracle's and openjdk, because that's what seems easily available, but it looks like there are four or five currently updated JVMs: http://en.wikipedia.org/wiki/Comparison_of_Java_virtual_mach...

Re: The March Towards Go

#166

Post by bsdetector »

randallsquared wrote: post #138
bsdetector wrote: post #82

Earlier quoted context omitted.

> has things others languages don't - fast compilation Never understood this talking point. What language other than C++ (and C to some extent) doesn't have fast compilation? And compared to these languages Go gets most of its compile speed simply by doing a really poor job optimizing. Compare times for -O0 and -O3 on other languages to see most compile time is dominated by optimizations. Is this supposed to convince…

I think this depends strongly on your development style. If you come from the world of scripting languages, a common style is "write between one and twenty lines of code; run tests; edit three lines; run tests...", where "run tests" might literally be that, or might just be running the code to sanity check that things are not too broken. In this style, even a twenty second delay would become very painful. I think peo…

> the "tomcat stop; ant remove; ant clean; ant install; tomcat start... okay, NOW you can test" was quite difficult to develop against iteratively

Ok this makes even less sense to me. In 10 years when Go has the completeness of these big Java systems it'll be even worse since there won't even be a dynamic loading option and the only choice will be to restart the entire system like that.

If you want to like Go because it has fast basic features and that's all you need that's one thing, but it doesn't have anything to do with compiling speed does it?

Re: The March Towards Go

#167

Post by fauigerzigerk »

marcosdumay wrote: post #159
fauigerzigerk wrote: post #140

Earlier quoted context omitted.

>It seems that having exceptions in the language is a great predictor for libraries/built-ins barfing upon bad input vs silently producing garbage Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. For instance, Python has the StopIteration exception to signal the end of an iteration. Exceptions force API designers to decide whet…

> Maybe so, but having exceptions in a language is also a good predictor for the misuse of exceptions for purposes other than error handling. Is that really a problem? I once hated such uses, but could never point why.

I think it's a problem for two reasons:

First of all, sudden stack unwind comes with a greater mental burden than regular structured code. Something implicit is happening that violates the expectations we have based on what we can see.

Secondly, consistency is always important because inconsistency forces us to think about things that we shouldn't have to think about, which lowers our productivity.

Re: The March Towards Go

#168

Post by marcosdumay »

dccoolgai wrote: post #131

So what comes after Go? I only ask because I figure if I start learning that now, by the time they switch again I will have a fair chance of being competent at it by then...

I'm taking the oposite route. Once all those people live Go for something else, I'll evaluate it and see if it's any good.

Re: The March Towards Go

#169

Post by stcredzero »

skrebbel wrote: post #33

Zef writes this as if it's completely amazing that people are leaving Node for Go. Node is based on JavaScript. There are arguably more things wrong with JavaScript than with any other popular programming language, as evidenced by book titles like "JavaScript, the good parts". This is common knowledge; we're all trying to do good work despite JavaScript, seldom because of it. So Node: it's fast, we can share code wit…

The one big substantive point was about callback hell. Coroutines and channels are exactly what's needed to solve that. Add in a minimalist language design focus on programming in the large, and you have a prescription for what ails Javascript on large projects.

This doesn't make Go a silver bullet. (So don't make that mistake, please!) It just happens to be the right kind of tool for two of the more salient problems right now.

Post reply on HN