HN Theater @HNTheaterMonth

I have such a feeling of tragedy about Python. I wish it had migrated to BEAM or implemented something similar, instead of growing all this async stuff. Whenever I see anything about Python asyncio, I'm reminded of gar1t's hilarious but NSFW rant about node.js, https://www.youtube.com/watch?v=bzkRVzciAZg . Content warning: lots of swearing, mostly near the end.

⬐ rogers12

That's a blast from the past. Incredible that 10 years ago people thought using a thread per request is a good idea because anything else is too hard.

⬐ gpderetta

thread per request doesn't imply kernel threads. And I'm pretty sure even a kernel thread per request in a faster language is going to be better than asincio in python.

⬐ throwaway81523

BEAM has user level processes and can run millions of them in a not too huge VM.

⬐ icedchai

I'd argue that thread-per-request is even a better idea now, given the massive number of cores and memory in modern servers.

⬐ mrfox321

Hybrid?

Request passed to a thread pool. Each thread is juggling coroutines representing in flight requests

⬐ icedchai

Is that worth the complexity? I like the way Go does it. The runtime is managing the actual threading and async IO as it schedules go routines, but to the programmer it all looks like normal synchronous code.

> Make it web scale.

Oh god whenever I read/hear that it reminds of the ridiculously funny video about nodejs and Apache servers. [1]

[1]. https://youtu.be/bzkRVzciAZg

⬐ usrbinbash

This video is just gold.

asyncio is probably one of the worst things that happened to programming in the last 2 decades. It's essentially a step backwards, to the technology of the 90s (cooperative multitasking), when a badly written text editor could cause an entire OS to freeze.

⬐ joconde

Curious why you think that. We have an app that does computation using thread pools, and moving from manually-created threads to asyncio has made it much more efficient and robust.

Some advantages: cancellation and error handling are trivial, there's no need for error-prone thread coordination, threads don't have to waste time waiting on locks (because we use asyncio sync primitives instead, so we don't submit work to a thread pool unless it's doable right now with no wait).

Of course, it depends on the tasks being written correctly. But "don't block the event loop" is a much easier rule to follow than "don't deadlock these 10 different threads that share queues and locks".

We didn't write an entire OS with it, but I don't think that was ever the point of asyncio, was it?

⬐ xcambar

Glad you liked it! The reference to this series of videos was intended of course.

The specific video I had in mind was actually https://youtu.be/b2F-DItXtZs

Enjoy!

⬐ fzil

Oh yes! I’ve seen this before as well. Should’ve guessed it’s this considering we were talking about sql.

reminded me of https://www.youtube.com/watch?v=bzkRVzciAZg

> What specifically is the problem with asyncio?

Watch the very NSFW (lots of swearing) but hysterically funny video "node.js is bad ass rock star tech" on youtube sometime ;). https://www.youtube.com/watch?v=bzkRVzciAZg

https://www.youtube.com/watch?v=b2F-DItXtZs

https://www.youtube.com/watch?v=bzkRVzciAZg

This debate reminds me on "Node.js Is Bad Ass Rock Star Tech", from 2012: https://www.youtube.com/watch?v=bzkRVzciAZg

Those videos (that being the most infamous) will never stop being hilarious. The node.js one is also pretty amazing:

https://www.youtube.com/watch?v=bzkRVzciAZg

The most important video I've ever watched for my career and sanity: https://www.youtube.com/watch?v=bzkRVzciAZg

> ... you don't have to think about 'long running things need to be futured/awaited', you just do things in a straightforward way in the thread

https://www.youtube.com/watch?v=bzkRVzciAZg

Six years later, very little has change in the arguments about events vs threads.

Check https://www.youtube.com/watch?v=bzkRVzciAZg

⬐ johnhenry

I agree with the video's title, but not necessarily for the reasons outlined in the conversation.

⬐ always_good

If you find yourself nodding along with that 2012 video, you need to try modern Javascript with promises and async/await.

I haven't written a callback API in quite some time.

https://www.youtube.com/watch?v=bzkRVzciAZg

More seriously Node.js has some pretty major performance problems, like the fact that it's single threaded. You'll make excellent use of one core, but that's about it. It looks great on I/O bound request/second benchmarks, but as soon as your code needs to do meaningful work it doesn't scale anymore. The solution to that is to spawn multiple node instances to make use of the actual machine resources, but now you're on your own and why did you bother with node.js then in the first place?

"If you're willing to suffer complex code for performance, why not just write an nginx module in C?"

"node.js is is the most bad-ass rock star tech to come out since Ruby On Rails"

https://www.youtube.com/watch?v=bzkRVzciAZg

...

"What was that last part again? I could have sworn you just said Lisp"

(Yes, performance and scalability are complicated. Different solutions will be appropriate for different situations.)

https://youtu.be/bzkRVzciAZg

> Node ... popularized the event-loop

Tcl was doing event loops quite successfully in the late 90ies and was fairly popular, back in the day.

These days, I'd use Erlang (Elixir).

This is kind of ranty, but also makes me laugh: https://www.youtube.com/watch?v=bzkRVzciAZg

⬐ PeCaN

That and the “MongoDB Is Web Scale” always get a kick out of me. Server-side-JS has some weird ideas about performance.

⬐ hyperpape

This is exactly what the word popularized means. It doesn't mean invented, it just means exposed it to a large number of people who hadn't previously encountered it.

I don't know if you can claim definitively that Node introduced more people to event loops than any other technology, but it certainly is one major popularizer of the idea, and the one that's had the most impact in the past decade.

⬐ davidw

So basically people who knew nothing of what had come before, despite it being a fairly widespread technology. I think that's kind of proving the video's point.

⬐ hyperpape

People are constantly learning how to program, and they pick up ideas in different orders from different sources at different times in the history of a discipline. Every idea anyone has ever known was something they didn't know until they were introduced to it.

The fact that you knew it first doesn't give you a reason to be snide.

If you haven't seen it, you might find this entertaining: https://www.youtube.com/watch?v=bzkRVzciAZg

I really wish gar1t would make some new videos, I love them.

⬐ TickleSteve

Excellent! someone in this world has their head screwed on right!

(you're getting downvoted unfairly I think, probably a bit politically incorrect in this neighbourhood).

⬐ davidw

I don't care about downvotes, I thought that video was hilarious and enjoy sharing it. He's the same guy behind "MongoDB is web scale" and "Erlang the Movie II", which I'd also highly recommend:

http://www.mongodb-is-web-scale.com/

https://www.youtube.com/watch?v=rRbY3TMUcgQ

⬐ Roboprog

Love me some Erlang, er, "OTP".

I'm pretty sure the video would violate the "code of conduct" at our local JS user group, though.

"it's because of you, motherfucker, that we're not all using lisp" @ 5:00 https://www.youtube.com/watch?v=bzkRVzciAZg

⬐ qwertyuiop924

No, that's actually the fault of Netscape.

Anyways, that video is awful and totally wrong. Node code can be clean, threaded code can be ugly. Both can be fast, but the perf characteristics are different (for OS threads, anyways).

It's remarkably difficult to find anything approaching hard numbers :-) However, I am going off:

* http://redmonk.com/sogrady/2015/01/14/language-rankings-1-15... (Haskell slightly ahead in their numeric ranking) * http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... (Golang slightly ahead in their ranking) * Slightly more published books on Haskell that I can find (although obviously it's been around a lot longer)

I have no doubt that Go will eventually surpass Haskell in terms of popularity, and may even have a slight edge, but suggesting that Go popularized typeclasses smacks of fanboyism, and reminds me - in no small measure - of: https://www.youtube.com/watch?v=bzkRVzciAZg

⬐ codygman

> suggesting that Go popularized typeclasses smacks of fanboyism

I'm not exactly a fan of Go nor am I a fanboy, quite the opposite these days. I don't have to like go to mention that the way interfaces are used kind of accomplish the same thing as typeclasses.

I also feel that (sadly) Go is more popular than Haskell. Partially because of the number of Haskell programmers I've encountered in real life is much lower than the number of Go programmers I've encountered.

https://www.youtube.com/watch?v=bzkRVzciAZg

⬐ timbuchwaldt

:D Yeaaaah..I'd actually much prefer ruby or python... but it just doesn't perform :(

You're most welcome.

> try writing anything in Node.js without a callback!

I wouldn't even try writing anything in Node. Server side javascript is not an option I would consider. http://www.youtube.com/watch?v=bzkRVzciAZg

Hazelcast on it's own is pretty useful if you need a distributed data grid in Java although it's not without its quirks. Unfortunately it's much less useful in Vertx because of the classloaders.

Callbacks as an antipattern is one of the main points of this HN post.

Luckily, Javascript is always allowed in PHP projects and it can do a lot more today than it could a decade ago. Also, using it will often lead to having NodeJS on the server even if it's just for compiling assets initially.

And NodeJS is bad ass rock star tech: http://www.youtube.com/watch?v=bzkRVzciAZg

https://www.youtube.com/watch?v=bzkRVzciAZg

Folks, why are you upvoting this?

It only talks about CPU usage, Node not being Unixy enough, and Javascript being terrible.

A better critique would have included talks about callback hell, or the general philosophical issues of non-block/evented work versus synchronous programming: see the classic http://www.youtube.com/watch?v=bzkRVzciAZg .

This isn't even that great a rant.

(I appreciate my fellow Rails devs probably upvoting it out of spite, but c'mon...)

⬐ LaGrange

It’s Ted Dziuba, a minor network celebrity and generally annoying dude with sensible technology competence and otherwise usual libertarian blabbing tendencies, including „get a life” style comments as evidenced in the post (if you tell people to get a life, you should get a life, and no, I don’t have a life). And this post actually got deleted, which is why you’re getting it from Google Cache. Consider that an art statement on the condition of Hacker News existence.

⬐ JonnieCache

I dunno...

"I know there's a closed form solution. Shouldn't you be in front of a mirror somewhere, figuring out how to introduce yourself to her?"

is pretty great.

⬐ LaGrange

If you’re a teenager then yes. Otherwise, it’s an ad persona towards an expected legitimate complaint: „hey, maybe a lot of work actually isn’t CPU-bound?” Seriously, if you can’t discern between solution for CPU-bound and IO-bound problems, you should consider a different career.

⬐ JonnieCache

Calling me a teenager, and then accusing the article of ad hominem six words later. Superb.

⬐ GhotiFish

I think the author didn't spell out the issue with that useless bit of trivia because the issue is obvious. Whether the implementation of the function is inefficient or not is immaterial to the argument. Most things arn't CPU bound, some things are. So the complaint stands.

⬐ anonymoushn

It's also two years old. I don't get it.

⬐ maratd

> Folks, why are you upvoting this?

Mostly, because it's funny. What's even funnier is how people take this sort of stuff personally.

I use Node, I know its limitations. I also use PHP. And Ruby. And Python. I use everything. I like having a full toolbox.

These languages are just that. Tools. If you went up to a carpenter and made fun of his hammer, do you really think he'll be pissed? He knows what his hammer is capable of and doesn't need anyone else to tell him.

A better question would be why this sort of commentary starts flame wars?

⬐ jepsen

I use node, .net, java, php, python, ruby, different horses for different courses. Sounds like this guy just loves to argue, bet he's fun to work with....

⬐ WoodenChair

This is not directed at your comment individually, nor is it anything about your content in particular... but IF I HAVE TO HEAR THE TOOL/TOOLSET ANALOGY ONE MORE TIME to describe programming languages, I think I will... be disappointed in your lack of creativity. Really, don't you guys have any other analogies in your "toolbox"?

⬐ GhotiFish

Yes! I have the car analogy in my toolbox as well!

⬐ d0m

It's not really an analogy though.. Languages, technologies and frameworks are just tools to build stuff. Said differently, to build stuff, you need tools. Programming languages are programmers' tools..

⬐ WoodenChair

It is though, because they're usually referring to woodworking tools or car fixing tools - not the generalized term "tools".

⬐ maratd

> because they're usually referring to woodworking tools

Says the guy with the wooden name!

⬐ jiggy2011

It's not even that great an analogy. If I use a particular hammer to build a table then I could throw it away at the end because it is no longer important as long as the nails are in the right place. I could even use a different hammer to drive every single nail if I wanted to and it wouldn't matter.

Languages , libraries , frameworks and runtimes on the other hand literally become a part of the end product. In many (maybe most) programs the total LOC count for the project is dominated by third party code vs original work.

So in this case they are not the tools, they are the nails.

⬐ Double_Cast

Some analogies are more robust than others. But all analogies snap when stretched too far. I think this is one of those cases where you unfairly stretched it too far.

hammer : painting :: tool : finished_product

Though cliche, it's not like the analogy is misleading. Nails might not be "tools" since they can't normally be used on the next project, like a hammer can. But nails are still a means to an end, e.g. "hang painting on wall". If we really wanted to, we could stretch the analogy ad infinitum. "What's the nail represent? What's the room represent? Who bought the painting? etc." But the purpose of an analogy isn't to draw parallels between the objects' irrelevant particulars. Its purpose is to abstract from the objects an equivalency of relationship (i.e. means/end). In this case, I think the equivalency is preserved even after we extended our analogy in ways it was never intended to be.

⬐ bradleyland

At some point in any rational discourse, all analogies become tortured analogies. The trick is in not focusing on how the analogy is wrong, but in what can be improved about the underlying idea. By all means, cast the analogy aside, for it is worthless on its own. It is only a means to relate to or understand the underlying idea.

Any time you feel inclined to dig-in and tear apart an analogy, it's wise to consider whether you're contributing to the refinement of the underlying idea, or just bikeshedding.

⬐ jiggy2011

It depends on the point that you are using the analogy to support. The tool analogy often gets trotted out to make an argument about something like language or framework choice not being important to the success of a project, but I think that the analogy becomes very brittle here for the reasons stated.

Deciding to switch something like a hammer (or text editor) mid project is likely not a big deal but switching to another language or framework can be an ordeal that requires planning. Since software projects are almost never "done" until they are obsolete the choice of language can have significant implications down the road that you wouldn't have if it was simply a "tool".

⬐ Double_Cast

I think I understand what you're saying now. My mistake was reading "the tool analogy is undeservingly cliche/popular because it's rarely accurate" vs "the tool analogy is doesn't apply in this instance (to programming languages) because hammers don't have lasting side effects".

"I don't know much about Spring, but In Vert.x 1.x each Verticle that is deployed has its own classloader, so it's hard to share a context across verticles." -- Tim Fox (Vertx creator)

"A vert.x instance guarantees that a particular verticle instance is always executed by the exact same thread. This gives you a huge advantage as a developer, since you can program all your code as single threaded. Well, that won't be a big deal to you if you are coming from JavaScript where everything is single threaded, but if you're used to multi-threaded programming in Java, Scala, or even Ruby, this may come as a huge relief" -- lol

http://www.youtube.com/watch?v=bzkRVzciAZg

I agree; it reminded me of this, in a bad way: http://www.youtube.com/watch?v=bzkRVzciAZg

⬐ voidlogic

Wow- That is great. Thanks for sharing!

http://www.youtube.com/watch?v=bzkRVzciAZg

⬐ None

None

i thought node.js was fast as hell bad ass rock star tech that would never melt.

http://www.youtube.com/watch?v=bzkRVzciAZg

⬐ taf2

well it's still pretty bad ass and rock star that you can measure server load by looking at "event loop lag", that's actually really neat... how do you do that with threads?

⬐ charliesome

by using system load averages

⬐ tbatterii

"how do you do that with threads?"

how should I know? :)

Perhaps this can help: http://youtu.be/bzkRVzciAZg

(Unless you were being double-sarcastic, in which case this post is a fail)

Again posted a link to get redirected to the HN discussion on it but there was none. :(

Why would a company that uses Java even consider Node.js?

Java is hands down faster.

I have never seen a benchmark that showed Node coming even close to Java performance.

http://www.youtube.com/watch?v=bzkRVzciAZg

⬐ heroic

It is because Java is like PHP. it is synchronous. If your app is doing a lot of non-cpu stuff, it makes complete sense to use an async programming model.

⬐ cynwoody

Nice little zing about Eratosthenes. http://www.youtube.com/watch?v=bzkRVzciAZg#t=238s

⬐ Ygg2

It's funny, but I find it ironic you are using that video opposite to what it is intended. Saying "Java is hands down faster" without proof isn't any different than saying "Node.js will run circles around Java" without any proof.

⬐ bluestix

https://github.com/jbrisbin/node-vs-java-shootout

http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-...

http://www.olympum.com/java/quick-benchmark-java-nodejs/

http://stackoverflow.com/questions/6645796/node-js-performan...

>We know the java libraries are there for lots of things, but Node is all about async and handling thousands of connections. It does this by forcing the entire ecosystem to be async too (including things like database drivers). By using a Java JDBC database driver you're completely losing any async support. Same presumably goes for redis or Mongo drivers. You can do some of the work with threads and pooling, but it's still not the same, and makes this another useless micro benchmark.

Sounds like you're quoting from the "Node.js Is Bad Ass Rock Star Tech" satire video ( http://www.youtube.com/watch?v=bzkRVzciAZg ).

Nothing inherently special about "forcing the entire ecosystem to be async too", especially since Node is more or less FORCED to do that, because javascript is single threaded.

Add the bad callback spaghetti implementation of async, and the main benefit of Node is easy deployment, and accessibility to the millions of javascript programmers.

As an async environment it doesn't offer anything either new or too compelling.

⬐ baudehlo

> As an async environment it doesn't offer anything either new or too compelling

That isn't strictly true.

If you focus on the traditional scripting languages as your competition: Ruby, Python, PHP, Perl: Then you start to realise that Node.js does offer a similar language structure (dynamic, no compilation, etc), with the benefits of thousands of concurrent connections (which those languages will do with certain modules) but while forcing all the libraries to also be async (which those languages DO NOT do).

At my last job I had to build an SMTP server capable of scaling to 50k concurrent connections. Building this in Perl was fine, except for any library I wanted to use - all of the libraries were synchronous. So now I wrote Haraka, which Craigslist are now using as their incoming SMTP server.

If you compare all that to Java you get slightly less performance but probably lower memory requirements. And that's OK. Different strokes for different folks.