[skrebbel]

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 with the browser, but it's a bitch to use. We knew that when we signed up.

Conversely, Python is a great language but it's not as easy to make it go fast. It's slow, but it's great to use. We also knew that when we signed up.

It's great that Go is getting more mainstream adoption! Deservedly so. But it's probably still easier to be super-productive developing a CRUD app in Ruby or Python. And it's still easier to share code between backends and web frontends with Node. If you don't need either of that, and you do need performance, then, yes, maybe you shouldn't pick Python or Node.

I agree that Go is a great option to consider, but Zef is framing it a little as a silver bullet, and well, of course it isn't.

[realrocker]

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.

[rdtsc]

Also presumably people who are not switching to Go are not writing blog posts.

"We are still staying with Python"

"Clojure still works great"

"Erlang backend still runs after 10 years"

"Node.js router still runs ok"

Those don't make compelling HN front page article. So if you read HN the impression is everyone and their grandmother is switching to <LatestFad>

[CraigJPerry]

Which is a shame, beautifully simple workflows delivering complex results are without a doubt a more impressive achievement.

[skrebbel]

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.

[realrocker]

In my opinion, this comment is a better addition to the debate.

[stcredzero]

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.

[andrewvc]

I agree that callback hell sucks, and promises are a vast improvement, but still shitty. Coroutines and channels are not obviously 'just what's needed' in my opinion however.

I think they're part of a larger picture. Mature languages should have multiple concurrency models available for different tasks. Clojure, for instance, supports coroutines, threads, and multiple other flavors of concurrent programming.

There is no silver bullet, polyglot concurrency is the future most likely.

[stcredzero]

> polyglot concurrency is the future most likely.

One kind of "polyglot concurrency" was the precisely problem of the past! In fact Rich Hickey says himself: You can do concurrency in Java with semaphores and such, but you end up doing some sentinel-thing that's somewhat specialized for your particular subsystem. Then you have to interface with this other subsystem...implement this new feature...then several months later you have a bug introduced because these weren't put together correctly.

In a large Clojure project, you should pick a particular way of doing things, then maybe allow a wrinkle or two, then be consistent about it throughout your project, or at least in that subsystem. Maybe you make your entire model an Atom and have a few FIFO queues for information coming in and going out? What you don't want to do then is to mix in transactional memory or Agents. Otherwise you can find yourself back in the "polyglot" mode of Java. With Go, you have a few flexible primitives from which to produce concurrent systems, but the same thing goes here too. You need to pick a few patterns and stick with them. Otherwise you can make your life much harder.

However, when you start going parallel, whatever you have chosen can go pear-shaped for some hard to fathom reason. Go is no better in this regard.

[andrewvc]

Agreed that you shouldn't mix concurrency models excessively, but many problems do call for a mix. I don't think Rich was referring to what I am. He was talking about the trouble composing Java concurrency using locks and such, which is just hard.

On the other hand with clojure, a standard mix is to use non blocking IO to multiplex a large number of connections, then delegate work to a threadpool (using clojure refs/atoms etc.). Such a system has a much smaller chance of deadlocks and other issues.

A great example of polyglot concurrency is the clojure reducers framework that lets you delegate work to a fork/join pool. Most people don't need it, but it's nice to have a safe, seamless interface to such an advanced concurrency tool.

[facepalm]

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.

[adamlett]

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

If you really believe that, I can only assume that you either don't have very much experience with Javascript and haven't yet been burned (or haven't yet discovered that you've already been burned), or that you don't have any experience outside of Javascript and therefore are not aware that languages exist that have all the niceness of Javascript but almost none of the bad stuff. I say this as someone who is primarily a Javascript developer professionally.

Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP), but there are many that are much better. It's worth noting that everything that is good about Javascript already existed in other languages before Javascript got invented. In fact Brendan Eich has stated that his intention was to create Scheme for the browser. If only he had just used Scheme as it existed, things would have been so much better!

[flaie]

> Yes, there are languages that are worse than Javascript to work in (I'm looking at you Java and PHP)

Java has an enormous ecosystem, is fast, is stable, has static typing, has more tooling than anything else, is easier to learn, does not have all the gotchas that Javascript has. I don't consider Java a worse language at all.

I use Java since a decade, and frankly I don't understand that rage against it while it is a totally valid option to start a project with, even a startup. If you want to get RESTful and all there's everything you need, etc.

Take it from a guy doing some Golang since more than one year and enjoying it a lot, also well versed in Python, Javascript, and even OCaml.

In fact, the time it took me to write this comment, I decided that I don't care anymore. Use what you need for the job and be prepared to change when something new is out and have a real impact on what you do.

[adamlett]

I agree that Java has relatively few WTF-level language design flaws. So on that count it wins against Javascript. But Java also doesn't have the expressive power of Javascript that comes from having 1st-order functions. Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement. I respect that there is a humongous ecosystem surrounding Java, but that doesn't really speak to whether the language is pleasant to work with or not.

[stcredzero]

Static typing is nice in principle, but the verbosity of Java's type system makes programming in Java feel like running in wet cement.

So then programming in Java with a powerful IDE is like running in wet cement with bionic stilts? I think this is actually an apt analogy, especially for when things don't work quite right or when things get a bit laggy.

[dccoolgai]

I've been working with JS professionally for the last 3 years...priorto that, spent many years with C++/SQL/etc...the statements that people get "burned" by JS (pesumably because of the weird coercion or floating-point comparisons?) I've never understood...maybe I just write my code in a weird way that insulates me from those things...I've never experienced more than a "minor surprise" in dev - certainly never been "burned".

[adamlett]

> maybe I just write my code in a weird way that insulates me from those things

Maybe you do. I certainly strive to. But don't you sometimes have to work with other people's code too? I recently inherited a 10 years old codebase written by people who had not heard of implied global and didn't use the var keyword.

In my previous job I had to educate several frontend developers about the dangers of using parseInt without a radix parameter. The ones that already knew did so because… you've guessed it: They had previously gotten burned.

I worked on a project in which the backend had a rest API that served json data. Among the data were some rather long integer IDs. But since javascript doesn't have integers but only floats (of all things), the IDs got rounded off in weird ways. Not very useful as IDs after that! If all everyone ever used was javascript, this would perhaps not have surprised anyone, and it would be known by all that you shouldn't use a Number as an ID, but always only Strings. The problem is that most back-end developers are not Javascript experts and in their world it is only natural that you should be able to use a number as an ID (as it should be IMO).

As time goes by and you get experienced, you begin to learn all of these little 'quirks' of the language, and maybe you start to adopt a defensive style of programming that insulates you from the worst of them. And if you've never experienced anything else, it's easy to tell yourself that this is just the way things are, and that it's probably the same for everyone. But I'm here to tell you, that this is not the case! Sure, other (better) languages have surprising behaviours too, but they are mostly good surprises that empower instead of restrict.

[dccoolgai]

> But don't you sometimes have to work with other people's code too?

Yes, I suppose I have gotten "burned" by other people's JS quite a bit...but not any more than I've been burned by other people's bad SQL or C++ or C#, to be honest.

> Sure, other (better) languages have surprising behaviours too, but they are mostly good surprises that empower instead of restrict.

I am assuming that by "better" languages you are meaning type-safe ones... I know this is not a popular opinion, but I honestly just prefer dynamic typing. When I code, there is only room for one whiny child in the equation: me. Not the language I code in. I would rather not have my language throw a temper-tantrum and break down because I gave it something a millimeter different than what it was expecting. If the object is supposed to have "thing" and it has "thing" then shut your mouth and use it, language. Where JS gets weird is that it tends to put "thing" there in some cases where you didn't expect it, but honsetly after learning the few cases where it does that, I've never had a huge problem with it - I think, like everyone, I bumped into some mild surprises (ya the radix thing with parseInt and [] == false and soforth), but they were never more than just mild surprises in development. I know it drives people insane - and some people will swear that there is no way to build large systems with it. I suspect those people are the same ones who asked the teacher for extra homework for the whole class when they were kids. That was just never me, and I would just respectfully disagree. To me JS is just a ton of fun and there are too many people making too many awesome things with it to ignore. Apparently TJ got tired of it - maybe I will one day, too.

Until then, I just wish people would recognize that the reason JS "won" the language wars of the mid-late aughts was specifically because of the "get-out-of-the-way-and-let-coders-code" dynamic built into it - IMHO the modern web could not have been built with anything else. If you have any recos for "better" languages that share that dynamic, I would be very interested in hearing them.

[facepalm]

How do you "get burnt" by parseInt without radix? Yes, I made that mistake before, too. But it's usually in a situation where you detect your error immediately. Then I add the radix, problem solved.

I don't know the libraries of other programming languages by heart either. I would be making lots of mistakes in other languages if I wouldn't look up the correct API all the time.

[Demiurge]

It's probably because c++ is arguably even worse (harder, with speed advantage to be fair). I haven't seen anything worse than MFC/boost 300 level underscore filled template stack trace, in any language.

[pjmlp]

Do you work with large teams? This is usually where such problems surface.

[BrendanEich]

> In fact Brendan Eich has stated that his intention was to create Scheme for the browser

No. Read https://brendaneich.com/2008/04/popularity/. "Come to Netscape, do Scheme in the browser!" was the bait. When I got to Netscape, it "had to look like Java". And given timing both internal and due to MS coming after Netscape, it had to be done really, really quickly.

/be

[rdtsc]

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

No it doesn't. Been using it for about 10 years can't remember being bothered by lacks of "real lambdas"

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

If there would be minor detail we wouldn't have had the "Good Parts" book. And trying to deals with variables in Javascript is pain, var vs no var, what does this do. Really strange weak typing rules.

Adding [] to {} should not produce some random value (what is it NaN or Object), it should throw an exception.

> Few other languages can match it's simplicity.

Wait, were you being sarcastic?

[Karunamon]

I assume you're referring to the "Wat" talk by Gary Bernhardt, here.

My question is why does it matter? It's funny and notable behavior, but why is this a problem that a real programmer will face dealing with a real problem?

(For reference, [] + [] = "", [] + {} = Object, {} + [] = 0, {} + {} = NaN)

[marcosdumay]

It matters because it shows how incoherent is the Javascript type system, and how easy it is to get biten by it.

About Python lambdas, I miss them a lot. But one can not have everything...

[rdtsc]

Because it hides errors instead of helping the developer find them

[Karunamon]

Are JS developers often adding empty arrays and empty objects together? This seems more like a corner case than a real issue.

(Not snarky - I don't know JS)

[rdtsc]

As often as any programmers deliberately insert bugs in their code ;-)

Those values are usually in variables that and have been set maybe from a backend reply or from the UI at some point.

That is just one instance of the sloppy mess of weak typing. Instead of writing a long list of it I just used an example to illustrate.

[tokenizerrr]

No. You generally only add numbers and strings together.

[gtirloni]

Extreme nonsense behavior from the language you're using. People see that and think "that's just the tip of the iceberg".

[adamors]

If you normally only do a couple lines of jQuery per day then I agree that you don't encounter the warts very often.

If however you want to do even some OOP you cannot miss the world of hurt that is coming your way. Then there's the horrible weak type system which makes maintenance of anything needlessly complex, not to mention the global variables, unused reserved words, anything that has to with numbers etc.

[nawitus]

TypeScript solves JavaScript's type problems pretty well, it's worth a look.

[adamors]

Does it play nice with Javascript frameworks like Angular?

[nawitus]

Yes, there are type definitions for most popular JavaScript libraries.

https://github.com/borisyankov/DefinitelyTyped

[aidos]

As already stated, it depends on what you're doing. I have to calculate lots of numerical things, javascript isn't brilliant for that at all (I'm not against js, I was an early advocate and have used it for years).

Python doesn't have real lambda, who cares? That may or may not matter to you, it mostly doesn't matter for me, most of the time.

You've directly commented on a post about how understanding the context in which you use your tools is the crucial factor by totally ignoring the point.

[_pmf_]

> There are minor details wrong with JavaScript. Normally you don't encounter them in daily use.

Defaulting to doubles and not having native integral types is not a "minor detail".

[mappu]

Doubles do have 53 bits of int precision at least. Did you know libcurl uses doubles to represent file sizes? File sizes that are always integral? Don't ask me why they did that, guess it had better platform support than int64's a hundred years ago.

[lucian1900]

Having to name a function in Python annoys me a lot less than basically more than half of JavaScript that is entirely batshit crazy.

[Derbasti]

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

[cycrutchfield]

Your username is very apt

[easytiger]

Python is also slow.

[rdtsc]

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

[lumpypua]

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 significantly higher latency than other languages.

2. Templating

https://stackoverflow.com/questions/1324238/what-is-the-fast...

Template rendering takes an appreciable amount of time. I had to replace django's (slow as shit) stock templates with jinja2 on a project because it was taking tens of seconds to render a very large page. Jinja is far faster, but it's still slow enough that I had to add a caching layer to a website that shouldn't need one.

3. Numerical shit

I implemented a video processing algorithm from a paper for a computer vision class. Python's scientific and numeric libraries were sick and made prototyping delightfully easy--then the final runs on the full dataset took forever. What I re-implemented in C++ was >10x faster. Vectorization and other tweaks can make python numerics go faster, but it's a pain in the ass. One of the goals of the Julia scientific programming language is to make loops fast enough that code doesn't have to be manually vectorized.

[easytiger]

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

[bpicolo]

Yeah, there are tradeoffs. SqlAlchemy is by far the most pleasant and thorough ORM to work with, for example. For any language. Full transactional support + every other feature you can dream of.

[tankenmate]

http://c2.com/cgi/wiki?PythonProblems

http://www.jeffknupp.com/blog/2012/03/31/pythons-hardest-pro...

[easytiger]

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

[rdtsc]

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.