Yes, async/await is pretty good. The primary problem with writing totally async callback driven code is the mess it makes of the readability. Rewriting code that looks blocking to be totally non-blocking with a smart compiler is a good way to resolve that weakness. Then you just have the issue of old APIs and libraries that aren't non-blocking capable. Microsoft has done a good job of trying to drive async/await through their whole standard library. Java not so much.

8mb! Wow, I didn't realise anyone was going that high. That's a lot.

I didn't know what the JVM used but just looked it up - seems it used to vary haphazardly between platforms but when they moved to 64 bit they standardised on 1mb by default. Still pretty big. I remember when the Linux kernel guys moved to 4k stacks. It broke a whole lot of drivers. 4k is pretty aggressive but still a lot larger than a compactly serialised closure.

Node is slower than a modern typed VM like the Java on the JVM or C# on .NET. Let's get that out of the way right now - Java is faster than Javascript. The reason is that Javascript source lacks a lot of info needed to efficiently map it to machine code, so V8 and other fast JSVM's all have to rely heavily on speculation. That's a fancy way of saying they guess what the code might do, compile that, and then recompile it again if it turns out they were wrong (or if the code actually changes itself at runtime which is not uncommon for dynamic languages).

Now to be clear, Java itself is actually a kind of hybrid static/dynamic language. For example all code is lazy linked and you can generate and load new code at runtime as well, if you want. All method calls are virtual by default etc. The JVM requires tons of complexity and machinery to make all that work with acceptable performance ... but it's still able to do a better job than with Javascript because the code contains more static type info up front.

So why do people think Node is fast? A couple of reasons. Partly it's because the sorts of people who are attracted to Node are the sorts of people who were previously using languages like Python, Ruby and PHP. Compared to the interpreters for those languages, V8 and thus Node really is very fast. Python/Ruby/etc don't speculate or produce machine code at all (though their JVM versions do). So, for people who code in the dynamic languages space, Node is a big step up.

Secondly, Node apps have a nasty habit of being built on NoSQL-ish database layers like MongoDB. These databases were being developed and getting hip around the same time that Node was becoming popular, so there are asynchronous database drivers for them. "Nasty" because they seem to be very frequently applied in cases where they aren't appropriate. BTW I say that as a former professional BigTable administrator, so I'm not a n00b when it comes to NoSQL databases.

In contrast most of the people developing Java/.NET web apps are usually developing business apps of various kinds and have older code bases, so they are using MySQL, PostgreSQL, Oracle, etc ..... more traditional relational databases which have only blocking drivers. That means for any web app that does database work i.e. all of them, the Java web servers will spend most of their time waiting around for the database. Whilst doing so they are holding thread stacks in memory. Thread stacks generally have to be sized at creation time for the worst case scenario, which means they tend to be large. 1mb stacks are not unheard of. Node, in contrast, requires asynchronous code at all times because V8 is not thread safe. It doesn't give you any choice in the matter. A callback closure held on the heap tends to require much less memory than a thread stack, thus, you can suspend many more computations at once when programming in this style.

If you can suspend a lot more computations simultaneously for the same amount of RAM, then you can force more traffic through a single server before it runs out of memory and falls over. And though people tend to talk about tens of thousands or hundreds of thousands of threads not scaling, actually since a bunch of major upgrades many years ago (NPTL, constant time scheduler etc) Linux has been actually able to handle bazillions of threads. The problem is that requires a very unusual programming style to achieve due to the tiny stacks, and Java/.NET aren't really designed with it in mind, so in practice nobody makes servers that work this way.

All this is a long winded way of saying that the programming style Node forces you into is genuinely more memory efficient than the thread-per-request style, and if you can fit more requests into memory at once then it will appear that a single server can "go faster" .... even if technically the code executes slower.

But here's the catch. Is it worth it? You've been able to do asynchronous programming for a loooooong time, even in Java or C#. The reason most APIs and SQL database drivers in particular don't tend to support this model well is because it imposes high costs and many people feel it isn't worth it, so the demand for better library isn't there. The biggest problem is it results in a spaghetti-like jungle of callbacks which makes for very hard to read code. I used to work at Google and the callbacks-vs-threads debates had been running there a long time. The core web search servers were all C++ and async/callback based, partly because a web search cluster is an insanely expensive thing due to the fact that the index is held in RAM, so having 10,000 queries in flight in a single server was well worth the programming pain. But that sort of thing is rare. Most web apps are not web search or WhatsApp or Facebook thumbnail serving. Most web apps can tolerate requiring more RAM if the gain is straight line code that clearly spells out the order and control flow of what's happening, because ability to debug the code and hire non-wizard programmers is worth more than some incremental throughput gain.

And if you DO want to do entirely async programming, then .NET and the JVM have tools for you to do that. C# has the async/await keywords and the JVM has Quasar. You might have to give up your nice MySQL ORM to get them, or use a simple custom driver, but the same is true in the Node world anyway. Basically Quasar/.NET async perform clever compile-time bytecode rewriting tricks to let you write code that looks blocking and straight-line but is mangled behind the scenes into the necessary callback mess. Then you only suspend the minimal needed state onto the heap instead of having a full blown thread stack per operation, and you can get Node style scalability with better-than-Node style speed.

However lots of people don't know about these options. Hence "epic battles".

Sounds like you don't enjoy Tomcat much. Me neither, though it has a lot of features. But running a Java web app doesn't require Tomcat. There's a whole market of servlet containers out there, and some of them are embeddable resulting in standalone servers if you don't like the "run the app in a big web server" model.

For example, a popular embedded servlet engine is Jetty, which has pretty good performance, easily handling hundreds of thousands of requests per second for a simple plaintext file, and seems to have better scalability than the others as concurrency ramps up.

2) Node.js isn't fast. It's concurrent. You can handle many thousands of simultaneous requests, as long as none of them are working particularly hard.

That makes it sound like some Node.js specific trick. If you define concurrent to mean "has callbacks and non-blocking IO" then basically any language can be described as concurrent, so this doesn't tell us much. Nothing stops you writing Java in a fully non-blocking single threaded style if you want to mimic Node programming, and in Java 8 the syntax for doing so is actually lighter weight than JavaScript.

But mostly people don't do that, because it's a pain in the ass. Node.js doesn't rely entirely on non-blocking operations with tons of nested callbacks because this is such a brilliant way of programming. Node relies on this because it's based on V8, a virtual machine designed exclusively for web browsers and browsers are not thread safe. Indeed one of the reasons V8 is able to get pretty impressive speed for such a dynamically typed language is because it just throws multi-threading out the window entirely. Writing a high performance VM is hard. Writing a high performance thread safe VM is much, much harder. Luckily the V8 guys can ignore it because a thread-safe JavaScript runtime is useless for browsers, and they never anticipated that anyone would love JS so much they'd actually use even if they didn't have to. So, it resurrects the Visual Basic model of concurrency from the 1990's.

The JavaScript world meanwhile has developed a kind of Stockholm syndrome in which obvious weaknesses are spun around to become strengths. No type safety? No threading? Blocking on even a disk seek trashes your performance? You're just doing programming wrong, see, and Node's lack of features is in fact some kind of Zen minimalist wisdom designed to guide you to the light.

This sort of thinking is very common in the world of programming languages because making a good one with all the features of the really big platforms (like the JVM) is really, really hard work, meaning compromises have to be made. Then because you are limited to interop with libraries written in C (again unless you build on .NET or the JVM), those language users realise their only chance for non-crap libraries is to convince the world to join them and rewrite everything in their language - hence the quasi-religious preaching of "simplicity is strength, our way is the high way" etc. The Go world seems to have this problem cubed.

Well, you can easily lose a lot more than a few milliseconds inside malloc or free. So systems that are harder real time than that just can't allocate at all, normally, and of course you can build allocation free systems in a GC'd environment too. The GC will just never trigger.

No, you didn't understand. I probably didn't explain well, but if you read the blogs then it's clear. They're talking about Ruby objects being manipulated from C. Memory allocated inside the C program is still manually managed.

The GC becomes a scaleability bottleneck; the parallel processing eventually being throttled by that GC that can only run as a single thread (more or less). So systems that need high performance, large scalability and distributed networking etc are invariably written in C++.

Which collector are you using? Modern collectors like HotSpot G1 are parallel and concurrent, that is, they can collect using multiple threads simultaneously whilst the application is running. Give them more CPU cores and they will collect faster. The way to start tuning them is to specify how much CPU time you are willing to spend on collection and how short your pause times need to be. Allocate more time and the heap will be smaller. Allocate less time and the heap will waste more space (i.e. be larger) but the application will be faster.

As I mentioned in my post, it's not true that systems which need high performance and large scalability are always written in C++. I've heard of multiple cases where large Java applications have GC'd heaps of several hundred gigabyte heaps and need a-few-milliseconds-or-less pause times. These tend to be apps in the financial industry for some reason. As another example I used to work at Google and they have quite a few very large, scalable systems written on the JVM, like the Gmail frontend web server.

The whole concept of threads and data ownership has exactly zero level built in conceptual support, and that sucks. It sounds as though Rust has been designed to resolve these issues for systems programmers. Which is a great idea.

Depends what you mean by resolve. Rust does static checking that data is only owned by one thread at once. If you need shared state then you are back to manual memory management again, as far as I know (Rust is a rapidly moving target so anything I say today might be out of date tomorrow).

Yes, that has been a persistent problem for speeding up dynamic languages for years. You can make a better runtime but then can't provide the interpreter API used by the C extensions.

The Oracle Research JVM team has a totally crazy solution for this. They have implemented an extended version of HotSpot that is capable of actually JIT compiling interpreted source code of Ruby C extensions such that the end result is much faster than the Ruby interpreter using GCC compiled versions of those same extensions.

The whole blog post is worth a read, but to summarise, what they've built is capable of actually inlining C into Ruby and vice-versa at the compilation level. So for example if a C extension function returns an array of three elements using the C extension API and then Ruby code unpacks it, it can actually compile down to returning those values in registers because the code is inlined together and then compiled in the normal way. Additionally, interpreting the C source code means that the JVM garbage collectors can still compact the heap and do other things that traditionally you cannot do with C.

Graal/Truffle are unfortunately still research projects. This technology doesn't ship in the regular JVM yet and won't do so for some time. But it's an interesting glimpse at the future of high performance dynamic language runtimes.

Wow, it sounds like you've certainly done your research, and are very familiar with what Rust is doing and how. I especially like your examples, and convincing arguments that Rust is unnecessarily complex. I mean, who even uses RAII anymore, or wants to have their code statically-verified at compile-time except by marking the unsafe bits as unsafe? Thanks, now I'm completely sold that you know what you're talking about, and that Rust is a badly designed language!

I think he spelled out why he thinks Rust is badly designed. I haven't reached a conclusion on Rust yet ,but I certainly wouldn't be so bold as to say it's well designed, at least not yet. At best you can say it's an open experiment.

First off, I'm not sure why you think RAII can't be done in a garbage collected language. For historical reasons C++ overloads the allocation of memory with the management of scoped resources hence the "resource acquisition is initialisation" name, but there's no reason that these tasks have to be joined together. Virtually all languages I know of have ways to do scoped resource management. Java has try-with-resources, C# has the using keyword, etc. The semantics are identical to RAII.

Secondly, I'm not sure what you mean with the statement about unsafe. Yes Rust requires you to mark unsafe regions of code with the unsafe keyword .... exactly like C#. Java has the sun.misc.Unsafe class that lets you do manual memory management and arbitrary unchecked memory reads/writes, albeit without any native language syntax. This doesn't seem like anything fundamental to Rust.

Now let's revisit silfen's criticism:

Rust makes trivial memory allocation, the kind other languages simply optimize quietly for you, unnecessary complex, while failing to work in complex scenarios.

Rust has a very complex set of rules that you must satisfy to make a program compile. "Fighting the borrow checker" is actually a thing in Rust. In some cases, the obvious way of writing a function that would work in any other language violates the language rules and requires workarounds. So let's not argue about this point specifically - Rust is a complex language and the lifetime management intrudes into even the most basic of programs.

What about failing to work in complex scenarios? This one is arguable. Rust can express the semantics of any program, I do not believe there is any case where you cannot write a program in Rust that could be written in another language. So "failing to work" is perhaps a bit extreme. However it is undeniably true that for quite common design patterns the Rust lifetime/borrow checking infrastructure cannot apply and Rust programmers must either spend time thinking carefully about ownership design or fall back on the equivalent of reference counting smart pointers. My experience of reading online discussions is that Rust programmers tend to see this as a virtue and everyone else isn't quite so sure.

The argument for Rust would be far stronger if it had been designed, say, 15 years ago, when garbage collectors were still very primitive. The problem Rust faces is that the key selling point of its design, the one that is used to justify all this unusual complexity, is "you can avoid garbage collection". But if you're working on a platform with modern garbage collector designs like the JVM or (to a slightly lesser extent) the .NET CLR, many of the old disadvantages of GC have been optimised away with time. On a properly tuned GC pause times are now very short even with large heaps, and some GC's like Azul or the new Red Hat developed Shenandoah GC don't actually have any pause times at all .... even with 200-300 gigabyte heaps. Google's ART runtime has shown that you can implement a concurrent compacting garbage collector on phones and get responsiveness that's basically as good as the iPhone. At least I don't perceive any obvious responsiveness difference on my Lollipop Nexus 5.

There have even been projects that applied garbage collection to places that conventional wisdom say should not work. The Unreal Engine is written in garbage collected C++ yet can still hit a reliable 60 frames per second. Even a very basic mark/sweep GC can easily sweep the core game state heap quickly enough to avoid frame rate stalls. Microsoft implemented an entire research OS kernel using an old version of .NET (Singularity).

This leaves Rust targeting applications where the developers either can't use even very basic GC, or believe that they can't. Undoubtably there are some applications like that. But many programming tasks won't find the Rust complexity/performance tradeoff worth it.

If I were to create a new language, I would not focus on creating the most beautiful syntax or the best built-in functionality. Instead, I would make damn sure it plays well with other languages and that it is trivial to use software packages already written.

Nim looks syntactically a little bit like Kotlin, which compiles to either JVM bytecode or JavaScript. If you compile to the JVM then you can not only use libraries written in Java, but also JavaScript, Python 2.x (via Jython), Ruby, Scala, C (via JNA), there's even a Haskell for the JVM called Frege.

The really neat trick, though, is that despite looking not much like Java at all, it compiles down to code that is binary compatible with Java and there is a Java-to-Kotlin rewriting tool, meaning you can convert existing Java codebases one file at a time whilst still having a fully compilable project. Thus you can not only leverage existing codebases written in many languages, but also slowly convert legacy codebases too.

Kotlin has some syntactic features that look similar to nim, like if being an expression not a statement, ranges, type inference, compile time inlining control, operator overloading, generics etc. Kotlin also has a a variety of features that focus on creating DSLs, but doesn't do it using a full blown macro system.

Nim has some things Kotlin doesn't and vice versa. I can write a more complete comparison (based on reading the docs) if anyone is interested. But the reason I mention it, is Kotlin's focus on interop with existing code.

What I am wondering is WHY all the articles (not just about Google) on how "businesses are ""failing"" " when all these businesses are posting 10-20% growth, yet some analyst says it's "bad" and so stocks get hit on that

Not all analysts are idiots, you know.

GOOG needs to post massive and ever increasing growth to be worth what it is. The reason is, Google pays no dividends. What's more they have never paid dividends and show no signs of paying dividends. Anyone who has studied Larry Page for even a few minutes knows that this guy doesn't want to pay dividends, any more than Steve Jobs did. Page wants to launch rockets to the moon and wire the matrix directly into people's brains. He is happiest when creating new technologies that are crazy expensive. Which is great for him and his employees ...... but less great for investors who need to make ROI for their pension/hedge/whatever fund.

There's another problem that weighs on Google's stock. Their revenue continues to grow very healthily. They make more money than ever before. But they also spend far more money too. Google has almost always been increasing its costs, through datacenter construction and hiring. There appears to be no limit to this spending and Page has never articulated any theory of how big his company needs to be. But it always gets bigger.

Final problem is that though Google spends massively on R&D most of its successful products make no money. They are at best small businesses compared to its main ads business (e.g. enterprise apps), at worst massive money toilets like Google Glass.

So stock analysts see two problems. Spending growth that matches or exceeds revenue growth, and almost total cultural inability to think about dividends. Just like it took Steve Jobs dying for Apple to pay dividends, it's not clear that Google will ever pay dividends until Larry Page/Sergey Brin are no longer at the helm. So if you own GOOG your only real option is to sell it on to someone else, or wait a veeeeery long time.

And that's why Google needs to see even more spectacular growth than it already has to support the share price.

EU has made it clear that avoiding conflict with Russia is worth the sacrifice of nations on the periphery of Europe.

Ukraine is only "in Europe" in some technical geographical sense that would also include Russia. Meanwhile the EU is trying to avoid being dragged by USA/UK into what is quite clearly a civil war, not an invasion by Russia regardless of what the talking heads would like us all the believe. Invasions aren't the sort of thing you can do quietly. Just ask the Iraqis.

Plus other bits of code actually required to make it run.

They also say that they think the same findings would hold for C++. So whilst it's a bit hard to know if this technique is useful without reading and pondering the paper, it isn't saying much about Java specifically.

That said - we all know Java is a very simple and verbose language. That has some advantages like ultra-fast compiles, but lots of disadvantages too. So here I'm gonna point out Kotlin, which is a new JVM language with transparent Java interop (in both directions). It's a lot more concise and expressive than Java, whilst simultaneously having a stricter type system. The neat thing about Kotlin is, it's developed by JetBrains so you get completely seamless integration with their refactoring IDE. Also there is a Java-to-Kotlin converter feature that lets you turn a Java file into a Kotlin file instantly, and you can convert a codebase on a class-by-class basis. So you can start using the features of the new language right away. Also, it runs on Java 6, so it's Android compatible.

Bad analogy. Anonymous Cowards on Slashdot have two attributes that make them unlike hidden services:

1) Slashdot can reveal their IP address at will

2) What they do can be either modded down by the community (if they're just posting garbage) or simply deleted if they're posting stuff that is outright illegal or deeply unethical (SSN dumps or whatever)

So Slashdot provides a limited form of anonymity with controls on it to prevent excessive abuse, and this is a good thing - although there's a lot of crap posting by AC's that gets modded down, I've been reading /. for 15 years now and many of the best comments have been anonymous. It's a clear net win.

Hidden services on the other hand are NOT a clear net win for the Tor community. There are zero controls on them, even though Tor is not alien technology or a force of nature ... it's a network run by a small group of people who can and do enforce rules on it, rules like "exit nodes may not engage in SSL stripping". Although Tor and the EFF like to claim there are tons of great social uses for hidden services, clear examples with real world impact are sorely lacking.

So I don't think you're arguing what you think you're arguing. Not all forms of anonymity are equal.