Scratching my head, probably it takes an Einstein to figure this out

Could be because of different (or no) rebates here or something, but the Nissan Leaf and similar smaller EV cars are about twice as expensive as the comparable car of the same make. Glad to hear it's different in the US.

Btw. I agree it's just just a wording disagreement about 'the government pays you' part - I assume that the local pollution and higher oil import dependence are more than offset by European fuel taxes; so you can imagine that you as an electric car driver are asked to pay your due share for road maintenance, public education etc. that's funded with fuel tax, and then immediately the government ''pays you" the equal amount as a handout / incentive. That the net is zero doesn't invalidate either side of the transfer (principle of gross reporting).

I like separating the notions of cash transfer from notions of the underlying economics, because, in principle, funding roads and education is a responsibility that's fairly independent of whether you drive an EV or ICE car. Just because the government mixes money pools and justifies taxes through (sometimes real, sometimes just PR palatable) reasons for individual taxation types, does not the economic fundamentals change.

No need to think of economic transfers differently just because governments juggle with different labels for taxation; often a new tax element starts its life as a disincentivizing (e.g. tobacco), or temporary (e.g. bank taxes in Europe), or targeted funding for something noble (e.g. roads or education) in the public's eyes, but once the taxed population gets used to it, the initially specific targets get relaxed and it'll just be a source of money in the big coffer, the rates can even increase, the original justification is history and the economic landscape may shift over the years anyway.

So much so that if there's an effect that the government wanted to achieve in the first place, and that effect is getting realised, the government can start to worry about how to substitute the punitive taxes. E.g. start with high prevalence smoking; add a moderate tax to disincentivize and fund the pertaining healthcare costs; prevalence gets reduced; tax rates are raised, i.e. about the same tax still gets collected. However a further reduction of tobacco consumption might not be wanted by the government (agency problem), because now a much smaller portion of the population pays high taxes that may fund not just the healthcare costs of smoking, but also warfare, police, education etc. - not to mention employment (tobacco farming) and that smoking today has a cost impact spread over future decades, whereas the government likes to spend the money of taxpayers who haven't even been born rather than avoiding the healthcare burden caused by sick parents and grandparents who used to smoke, once they grow up.

It's a fair statement, however, the very high taxes on fuel sold in Europe aren't just there for punitive reasons. While tobacco tax maybe offsets (or more likely, just partially offsets) the negative externalities caused by smoking, such as healthcare costs (which are predominantly a public service in Europe), most of the negative externalities on car use are experienced globally, e.g. global warming. I suspect that taxes on fuel are as much a revenue stream for governments (spent on road infrastructure and all government services, doesn't matter here) as an incentive to use less fuel.

In other words, maybe (IMO: probably) if everyone switched to electric in a country, there would need to be a new tax on electricity, or higher road tolls, or something, to keep things in balance. If this were the case, we could conclude that indeed, the country hands out money for the small, wealthy minority that can afford electric cars - even if no money directly hits the electric buyer's account. Such implicit shifts in public money may occur, even if it's simply not paying 'fuel' tax which is more like just 'tax' which was created in a time when electric was not a policy consideration. Even if such government incentives favor the wealthy, it might be good statesmanship to keep this way, because the psychology of 'cheating' the tax system and evading fossil fuel costs and taxes, and benefitting from rebates, probably has a role in buyer enthusiasm and the establishment of a brand new, possibly local industry faster than without these incentives, and this may ultimately serve the country better than if we just wait out better economies. So it might be like a Kickstarter campaign.

A very accurate model would need to include a lot of uncertainty about technological progress and levels of competition across countries and companies, but the tl;dr is that new taxes are likely introduced once electric cars are widespread, meaning the current policy transfers economic benefits to buyers of electric cars now.

Don't forget the time value of the money, and more importantly, the cash aspect. Most people would not consider prepaying 5-10 years of fuel even if it gave them some 10-20% discount over the net present value of the future gas station stops.

But all things are not equal, and there's the additional savings of not buying junk food at the gas station.

My impeccably logical rational friend, loosen up a bit :-)

Don't forget: location, location, location :-) Speaking of pussiness: if you buy one of those addresses, and happen to look a bit like the guy who lived there, and have three small kids, "courage" is not in the context of your bravery, more like not exposing your children to avoidable risk. If you didn't know, US real estate prices in these - probably - nice areas are impacted by new neighbors who are not of the majority race.

Also, proper notification of these guys by government agencies, and other preparations may also amount to a few millions. US officials probably don't want the type of revenge terrorism that killed most of a journal's staff in France a couple of months ago.

Each of those 100 real estate addresses are worth many ten k less because living in an address where a jihadist can appear for shooting is less desirable. Loss of about 5-10 million USD before doing anything. Since media is their enabler, perhaps censorship doesn't appear avoidable.

Youngsters can Google it.

> Javascript, despite it's popularity, is a terrible language. It's popularity is due to one thing, it is embedded in the browser.

A devil's advocate may answer that if JS were that terrible, it and the browser and the web (or Web 2) wouldn't have taken off. But this also offers no proof or reason.
Admittedly there's lots of dislikeable parts of JS, but we probably agree that for whatever reason it happens to be one of the most popular languages ever.

> There's a 4th reason that gets tossed around that I've never seen actually validated with the idea of "reusing code on the backend and the front-end" but I've never seen a case where that was actually a good idea since it involves exposing so much logic.

I don't understand 'so much logic'. You need to validate user input in the browser (with 'logic') to avoid server round trips for common errors; but you also must validate data on the server side, because you can't trust the incoming POST/PUTdata (it may come from a malicious agent). Why would you program the validation twice? The same goes for aggregations, filtering, sorting, utilities etc. - not to mention prerendering the page on the server side for faster initial load or some other purpose (SEO optimization).

> On the frontend, yes, Javascript everything...because you have no other option. That's like saying black was beating green for mind share with the Model T Ford.

> On the backend, you have Java, Go, .NET, Ruby, Python, PHP, Clojure, Groovy, Erlang, Perl, Scala...all of these languages exist with different benefits and different trade offs.

So instead of a zillion competing options with various tradeoffs, just pick the language you already use anyway (JS), which also has various tradeoffs, with the big plus that you don't introduce a language chasm along arbitrary technical boundaries such as some length of wire between a data center and the user.

One can find an interesting niche project for anything... but probably the analogous meteor.js (as in Javascript) has a larger community. It may be to do with social reasons; the JS world could remain nimble while the Java world has matured, consolidated, slowed down and lost its coolness as well as edge. By now, those Java folks who were more ambitious, are testing Clojure, Scala or RxJava.

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

I don't think it follows. Both Java and JS use JVM and both need to compromise some performance in the name of safety. Code fragments that are used once won't be optimized and it won't matter. CPU heavy lifting occurs if you operate on larger memory blocks (typically loops or nested loops). One common example is matrix multiplication. If you worked at Google, you may be familiar with how a Javascript array can hold unboxed integers or floats, if the programmer followed common sense and didn't destroy this optimisation by also storing strings in the array (of course you can use typed arrays too in JS...). If the JIT knows the bounds of the array and the element type, why would a Java MMULT be inherently faster than a JS MMULT?

By the way, even if the JIT cannot guarantee e.g. the type of something: the overhead does not occur because the JIT has to deoptimize something. With well written code, the programmer avoids the circumstances that would lead to such deoptimization. Instead, the overhead occurs because the JIT cannot guarantee it in all circumstances, and by extension, when it is unsure, it is obliged to check first. These instructions are typically low level bit tests and the like, and they add instructions, but they don't typically involve extra memory lookups or some other complex thing that would slow down a modern multiscalar CPU. But again, most performance-critical time would be spent in tigth loops running on typed arrays, where memory alignment, cache hits etc. play a more important role than the language, and neither JS nor Java has the type of control over memory allocation or memory arithmetic that C has.

You clearly seem to be in one of the camps but your post has contained no substance whatsoever other than conveying unsupported second hand sentiment (again with no specifics) and no direct experience.

> assuming Java generally has better run-time performance than Javascript

Java has no speed benefit of any impact over Javascript (e.g. V8). What you propose (node.java) actually exists (e.g. Ratpack); node.js elements such as non-blocking I/O were basically taken, and implemented in Java. Even with this there's no compelling argument for Java, and the developer mindshare and most action is in node.js land. These societal factors easily outweigh the few technical positives of Java.

Java is most commonly used as a simple, synchronous web server, so statistically speaking, JS has the lead over Java (because node.js is non-blocking).

Why PHP or Perl on the backend, if you already need to use JS on the client, AND you can as well use it on the server?

For it is obvious that the modern web experience requires more and more dynamism, with fluid interactions, and this necessitates JS more and more (though with high bandwidth, low latency and high reliability may come dumber terminals which just receive video streams, but that's another 10-15 years).

Interestingly, one of the most important but forgotten part about node.js hides in plain sight - it is that it's a NODE.

More traditional architectures have a strong separation of client vs. server. But node.js is already showing some of what it means that it's a node:
- you can write your code once and run it anywhere :-) be it client, server, middleware etc.
- your server may not be just one server: maybe it's a network of servers (nodes), e.g. with functional separation, domaln object separation or partitioning separation
- you already use node.js on the client side (the developer toolchain contains dozens of node.js based tools, like grunt)
- some client/server lines are blurred; e.g. the use of phantom.js for testing or server side static page prerendering
- the Internet of things is a buzzword, but it's coming

So this highlights the strength of node.js and JS in general: while people with a traditional mindset say node.js is just a server which just happens to use Javascript, the implications are a lot more profound. Check out something like meteor.js to see how it allows a reimagination of data flows.

The summary is not about node.js vs. the browser, but Java vs. Javascript.

The main problem with Java (other than the other major problems others listed) is that it's not Javascript:

1. you cannot realistically avoid Javascript on the client side
2. the client side is only getting richer in functionality (look up something like dc.js, crossfilter.js, d3.js, Google apps, mapping, all web apps...)
3. there is benefit to using one language instead of two, if the feature set is comparable: no context switch for programmers...
4. ... and you can use common data validation (on the client: reject/highlight bad user input without a server trip; on the server: 'never trust the client' principle, infosec)
5. ... and common aggregation analytics (allow your user to sort, filter, aggregate data, product descriptions, events whatever) between client and server
6. ... common domain-specific logic, common utilities libraries, DRY principle, no duplicated testing of logic, common development toolchain, we could go on

So the 'they both have their place' isn't quite true for a very large fraction of deployments which currently use Java on the server (and naturally, JS on the client).

Javascript is not 'only so performant', and, as someone else below assumed, JS isn't fast 'because of concurrency'. Most JS is run on V8 or similarly advanced engine, and in my experience the resulting code is about as fast (or slow) as Java execution (single threaded) even if we ignore the most often cited benefit of node.js, which is non-blocking IO. As JS itself is evolving, with typed arrays and the possibility of programming it without generating garbage, WebGL, Web workers, and low level numeric and bit logic functions coming up in about a year, so it'll only get faster. It's unlikely Java will ever have a performance lead on JS ever again.

Using the same language end-to-end is a more powerful argument than 'the right tool for the job' argument, especially if Java's current lead in some specific server side areas (e.g. finance/reliability/type safety aspects, or machine learning) aren't inherently a consequence of the language, just a consequence of a head start in those areas.

So in my opinion there is a strengthening incentive for using one language end to end at the expense of Java.