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

171–180 of 217 posts

Re: The March Towards Go

#171

Post by marcosdumay »

peterhunt wrote: post #24
dons wrote: post #15

Earlier quoted context omitted.

> full of broken packages. Citation needed. Hackage goes to great lengths to validate packages as much as possible. Other support systems do continuous integration and further validation, if you're looking for well regarded package subsets. Maintaining 6000+ open source packages is a pretty serious task.

I dunno, I tried installing snap, yesod and happstack (the three top web frameworks apparently) about a month ago and after about 20 minutes of compiling all failed to install (some had missing packages, others had the packages but they failed to build). I'm running a no-frills MBP with bash, which I would imagine is a fairly popular dev environment. All I want to do is serve an HTTP request.

If you are using the GHC and Haskell-Plataform provided by your distro, I'd recommend you get the latest version and install it yourself. Both are changing a lot and some distros (Debian, for example) do not keep up. (Also, that'll avoid a few severe bugs GHC had up to a few years ago.)

Re: The March Towards Go

#172

Post by easytiger »

lumpypua wrote: post #135
rdtsc wrote: post #121

Earlier quoted context omitted.

No, pretty fast. Having used it for 10 years. Never had problems with its speed.

No seriously, also having used it for 10 years it's an issue for python. Three quick personal examples, though I've dealt with a number more: 1. Python web frameworks http://www.techempower.com/benchmarks/#section=data-r9&hw=i7... Carefully configured Flask can get up to 1/3rd the speed of other web frameworks. But misconfigure it, use an ORM, or if you're on django, you're serving 1/10th as many requests/sec with si…

I work on bare bones low latency systems. Read from a socket->do some basic work->send on a socket.

I prototype in python and use zeromq so i can simply insert a new piece of code in c++ when the time is right. Throughput generally increases 10x or more for the same algorithm

Re: The March Towards Go

#173

Post by Derbasti »

facepalm wrote: post #42
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…

There are minor details wrong with JavaScript. Normally you don't encounter them in daily use. Apart from that JavaScript is brilliant. Few other languages can match it's simplicity. Python falls through because it doesn't have real lambda.

> Python falls through because it doesn't have real lambda.

True. What it does have though is real closures. Local function definitions with a proper name, capturing lexical state, usable as first class objects. This is a usable replacement for real lambdas, in much the same way functions are used as a replacement for just about everything in Javascript.

There are so many things in Python that have real syntax and language support, and that are lambdas upon lambdas upon lambdas in Javascript.

Re: The March Towards Go

#174

Post by p0nce »

fauigerzigerk wrote: post #140
_yosefk wrote: post #12

Earlier quoted context omitted.

Incidentally, your link includes a great example of Go's error handling - which is inevitably what actually happens in languages without exceptions: errors are silenced and the program marches on, each step making less sense than the previous. It's a good talking point that you can always check error values - but it never really happens, in part because library designers try to avoid putting the burden on themselves…

>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…

Don't worry, you won't see them that much since people will forget them.

That's the entire point of exceptions: never let an error get silenced.

Re: The March Towards Go

#175

Post by artemshitov »

peterhunt wrote: post #24
dons wrote: post #15

Earlier quoted context omitted.

> full of broken packages. Citation needed. Hackage goes to great lengths to validate packages as much as possible. Other support systems do continuous integration and further validation, if you're looking for well regarded package subsets. Maintaining 6000+ open source packages is a pretty serious task.

I dunno, I tried installing snap, yesod and happstack (the three top web frameworks apparently) about a month ago and after about 20 minutes of compiling all failed to install (some had missing packages, others had the packages but they failed to build). I'm running a no-frills MBP with bash, which I would imagine is a fairly popular dev environment. All I want to do is serve an HTTP request.

There is also a known issue with XCode and OS X >10.9, which may cause some packages to fail to compile. Haskell Platform download page includes instructions on how to avoid it: http://www.haskell.org/platform/mac.html

Re: The March Towards Go

#176

Post by bluecalm »

avz wrote: post #81
candl wrote: post #70

Earlier quoted context omitted.

I tried to like Go. I was allured by the native compilation and quite low memory footprint while still being quite high level, but I just can't. I can't stand it forces you to use K&R style. I can't stand the verbose error handling. I can't stand the inconsistency in the built-in types and libraries. I hate that unused variables and imports are a compile error which is just stupid and kills all the fun in programming…

I'd argue placing error handling in a spotlight is a feature, not a bug. Years of hiding error handling resulted in cultural biases that sanction focus on features without sufficient consideration for failure modes and unexpected conditions. Merely throwing an exception when something goes wrong may give you a peace of mind, but often leads to software which isn't robust against simple failures.

Similarly I would argue that lack of many OOP constructs is a feature as you can't over complicate stuff with class hierarchy and what not. As to unused variables being compile error I guess it's good for big project but it would drive me crazy if GCC throws that in C code instead of a warning for my home projects as there is often a lot of tweaking and being forced to remove the imports between quick test runs would be very time-consuming.

Re: The March Towards Go

#177

Post by collypops »

aikah wrote: post #162
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 plat…

It's more like Zed Shaw leaving Ruby for Python.

That happened. So did lots of other stuff. Same as it always was.

Re: The March Towards Go

#178

Post by DCKing »

randallsquared wrote: post #165
DCKing wrote: post #142

Earlier quoted context omitted.

> 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…

Now I don't know if it's intentional or not, but many things you are saying are just FUD. You seem to be assuming that the only way to do JVM stuff is considering all the difficulties that enterprise Java shops with legacy projects put up with. That is far from the truth, as any tutorial for Spray, Play or Akka could tell you.

> Which JDK do I use[1]?

The Oracle JDK (which is the same as OpenJDK FYI).

> What happens when one library I want to use recommends a different JDK than another library I want to use?

There is a 3-month period or so every three years when a new major Java release is done when some developers of enterprisy libraries might want to do some more testing before making a recommendation. It's not a big question in the JVM world at all, and it's definitely not a big problem even for early adopters.

> Build tools questions: ant, maven, gradle?

SBT. You're building a new Scala project.

> 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

You would have been right five years ago. Today, many people run Akka/Spray/Play projects in production just fine without deeper devops knowledge necessary than with other runtimes.

Re: The March Towards Go

#179

Post by skrebbel »

realrocker wrote: post #67
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…

What part of the article did you read as "Go is a silver bullet? I read it as a list of articles about people/companies who are switching to Go with each giving their reasons for adoption.

No part in particular - I don't disagree with Zef or the people he quotes. But the entire article does have this "look, all these smart and influential people are ditching $THING for Go, you should too!" feel to it. They're ditching stuff for Go for the particular kinds of problems that Go is good at. This is a subtle but important distinction that Zef isn't making, so I figured it was a useful addition to the debate.

Re: The March Towards Go

#180

Post by rdtsc »

easytiger wrote: post #170
rdtsc wrote: post #121

Earlier quoted context omitted.

No, pretty fast. Having used it for 10 years. Never had problems with its speed.

You have never done anything requiring high throughput low latency computational pipelines clearly.

So, is that bad? Are my systems inferior because they are not "webscale" or "computational pipelines"? I never said I did that. Python is fast enough for what we do.
Post reply on HN