Earlier quoted context omitted.
I'd much prefer that optional type annotations make it into the spec, like they did for Python and PHP.
Typescript being a superset of javascript does allow optional type annotations. RTFM.
RTF-OP
Why the New V8 Is So Damn Fast
201–210 of 237 posts
Re: Why the New V8 Is So Damn Fast
#202I used to believe that javascript was slow, C was fast and that there was no way to change this because of the way that javascript is interpreted and not compiled. But the more I've learnt about the benefits of "on the fly" / "just in time" optimising compilers, the more I'm convinced this is the future of computing. Being able to use multiple threads and hence multiple cores simultaneously to optimise what is actual…
What's funny to me is how JavaScript has gone from something of a joke to a very well regarded, performant, and heavily used programming language. I can clearly remember the days when proposing any significant programming in JavaScript would get a developer laughed out of the room. Is there another example of a language that has had such a 180 degree turn around in respect and popularity?
It's just tolerated, not respected, including by many JS developers.
It's not that performant either, it's just that it's getting closer to Java-class performance which is enough for many types of workloads.
JS is living proof that throwing enough money at a problem can go quite a long way.
Re: Why the New V8 Is So Damn Fast
#203Earlier quoted context omitted.
IMO The problem as it stands now is that when developing typescript you have a compiler running on your machine doing the typechecking. It will error out and simply not compile when you try to pass a string to a fn expecting a number. What if there is a bug (or even a misconfiguration in your project)? Or typescript changes over time (and now there are different versions all needed to be supported)? Or what if the ty…
I quite disagree. Look at JVM performance, there’s been huge improvements over time and a Java program compiled 20 years ago will get the same improvements as one compiled today. Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler.
> because the JIT can perform optimisations which are impossible for the compiler
Is there an example of at least one such optimization? As JIT is not magic, it also compiles things ahead of time, but a little bit ahead of time and it is very constrained on how much time and resources it can waste. It also can't afford to slow down interpreter too much, can't do excessive profiling, can't do big changes to the code that touch half of all the functions and data structures for example, etc. While AOT can do that and I can't think of anything JIT does that AOT can't do.
Re: Why the New V8 Is So Damn Fast
#204Earlier quoted context omitted.
> Not only that but you can expect to get better performance from the JIT than AOT because the JIT can perform optimisations which are impossible for the compiler. I can’t help myself, but the JVM performs at par with managed AOT languages (Go, Haskell, OCaml, etc) and strictly slower than the unmanaged AOT languages (C, C++, Rust). The JVM does outperform various AOT Java compilers, but that’s probably an artifact o…
Lots of people believe this but it's false. JVM vs C++ depends very much on the code shapes and what the code is doing. C++ that's very heavy on virtual function calls can be faster written as Java. On the other hand if you use a lot of SIMD intrinsics and things like that, C++ can be a lot faster. W.R.T. AOT vs JIT, as others are pointing out, Graal is a compiler that can execute in both modes, i.e. it's a comparabl…
You make it sound like Java is neck-and-neck with C++ in general. There are definitely cases where naive Java is faster than naive C++, but those cases are infrequent. Java is generally in the ballpark of 1/2 C++ speed alongside Go and C# in the general case.
> W.R.T. AOT vs JIT, as others are pointing out, Graal is a compiler that can execute in both modes, i.e. it's a comparable compiler. JITC is about a 20% win for relatively static languages like Java and can be massively larger (like 4000%+) for other languages like JavaScript or Ruby. In fact the nature of very dynamic languages like Ruby or Python or JavaScript mean there's little point trying to AOT compile them at all because there'd be almost no optimisations you could safely do ahead of time.
It seems like you mistook my point for "AOT makes things fast and should be used everywhere" or "JIT is fundamentally slower than AOT"; my only point was that the JVM specifically isn't faster than AOT languages nor is it faster than AOT Java because of JIT specifically (which was how I interpreted jahewson's comment above). It sounds like I agree with you--Graal seems really promising and JIT is pretty great, especially for dynamic languages. :)
Re: Why the New V8 Is So Damn Fast
#205Earlier quoted context omitted.
As for the second half of your comment, it sounds like you haven't used JavaScript in awhile. ES6 introduced syntax for classical inheritance, and a bunch of other nice features.
I use ES6 at my job, daily. There are some things about it that make me really hate it. First, no, it doesn't introduce classical inheritance. It introduced syntax that looks like classical inheritance. It's still prototypal inheritance under the hood. I'm not entirely sure what this means yet from the standpoint of building things with it, but I'm not enthused at the prospect. What I find happens fairly frequently w…
Indeed, JS does not have classical inheritance. IMO introducing a class syntax that looks so much like the classes from other languages and yet behaves differently was a mistake.
The rest of your comment sounds a bit misinformed to me. You seem to have decided that prototypical inheritance is somehow inherently worse than classical inheritance, but don't mention why that would be. I have found very little practical difference between the classes in JS and other languages in everyday use, and can't quite imagine what the problems with it might be.
Furthermore, ES6 (ES2015) is not a "transpiled language". I think it's obvious that if you take a very new language, say, ES2018 and want to run it on your toaster that doesn't have support for such new languages, you are going to have to do some kind of precompilation step. That is true for ES2018 today and it will be true for ES2019 next year and for ES2020 the year after that.
ES2015, however, has been around for several years. All the modern browsers (that is, all major browsers except IE) support it already. Node 10 even supports the new module loading syntax (behind a flag), or you can use a very lightweight transformer like esm[1] for older Node versions.
And if you do end up using and having problems with, say, Babel, it would be more constructive to give concrete examples of the issues you've had. I personally have never faced a syntax problem where the issue would've been due to a bug in Babel instead of just my incorrect understanding of the language feature.
Re: Why the New V8 Is So Damn Fast
#206Earlier quoted context omitted.
I use ES6 at my job, daily. There are some things about it that make me really hate it. First, no, it doesn't introduce classical inheritance. It introduced syntax that looks like classical inheritance. It's still prototypal inheritance under the hood. I'm not entirely sure what this means yet from the standpoint of building things with it, but I'm not enthused at the prospect. What I find happens fairly frequently w…
Indeed, JS does not have classical inheritance. IMO introducing a class syntax that looks so much like the classes from other languages and yet behaves differently was a mistake. The rest of your comment sounds a bit misinformed to me. You seem to have decided that prototypical inheritance is somehow inherently worse than classical inheritance, but don't mention why that would be. I have found very little practical d…
I didn't intend to argue that prototypal inheritance was bad, just that I didn't relish the prospect of building something in it, in the context of a discussion about reinventing Rails in Javascript. The argument is that with the amount of time and effort that went into Rails, the new framework has to offer something a lot more unique than just "Rails in JS" if it wants to be relevant, because you'll never even get remotely close to the maturity of Rails.
The problem is that I can't give concrete examples because we're under the gun of a deadline and I can't afford to spend the time to troubleshoot down to root causes rather than just work around the problem and move onto another feature.
I'd love to be able to tell you why the spread operator didn't work in that case. But it didn't, and I made sure to get the whole team around me to tell me I wasn't being crazy. The syntax simply didn't create the needed semantics, and that means that something got messed up in the design of the language. I'm pointing to Babel because that's the only thing I can point to as a root cause.
Rails is nowhere even close to this level of broken. You can rely on the syntax and semantics of Ruby, sometimes gem authors play nasty games with metaprogramming, I saw an example where someone monkey-patched Symbol to get a more declarative method for describing SQL Where Conditions, but at least that crap wasn't in ActiveRecord.
Rails, as a stack, fits together and experience with the framework will allow you to trust it.
Syntax is the foundation of a programming language. If it doesn't work, if it doesn't produce precisely the input that's being described, your language is broken. We're not talking standard library here, we're talking about `{...object}` not being the same as `object`. I don't have time right now to dive into why, but that's the kind of shit I run into when I deal with ES6. When syntax breaks, you can't trust the language anymore. It's a pile of hacks and I wish it had never been invented. Coffeescript was better.
Re: Why the New V8 Is So Damn Fast
#207Earlier quoted context omitted.
But go has an imprecise GC (in reference implementation) or stack maps (in gccgo), so the GC overhead is rather huge. It also lacks of compaction, so cache misses are not that good too.
Not sure what you mean by imprecise, but Go’s GC does trade throughput for latency. The overhead still isn’t huge if only because there is so much less garbage than in other GC languages. I’m also surprised by your cache misses claim; Go has value types which are used extensively in idiomatic code so generally the cache properties seem quite good—maybe my experience is abnormal?
>Not sure what you mean by imprecise
It's a rigid term:
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Pre...
perf shows how much time does GC eat, and that's quite a lot. Thus in the majority of benchmarks go lags behind java or on par with it at best.
>there is so much less garbage than in other GC languages
That is not true since strings and interfaces are heap allocated thus the only stack allocated objects are numbers and very simple structs (i.e. which contains only numbers), so you would have a lot of garbage unless you are doing a number crunching, which could be easily optimized by inlining and register allocation anyway.
Re: Why the New V8 Is So Damn Fast
#208Earlier quoted context omitted.
why would or should it?
One can argue that PHP is the least suitable language to write web servers in, no standard async or multithreading, tones of leaks, and so on. Node asynchronous model is quirky but given js world's "isomorphism" it should have squeezed PHP out of existence by now
PHP is roughly the hardest language to experience the effects of memory leaks in because of it's one process per request model.
Re: Why the New V8 Is So Damn Fast
#209Earlier quoted context omitted.
why would or should it?
One can argue that PHP is the least suitable language to write web servers in, no standard async or multithreading, tones of leaks, and so on. Node asynchronous model is quirky but given js world's "isomorphism" it should have squeezed PHP out of existence by now
You don't write web servers in JS, either. You use Node.
Re: Why the New V8 Is So Damn Fast
#210Earlier quoted context omitted.
Does that mean there's still room in the JS ecosystem for a Rails-alike? Maybe one that could become very popular? Because I am looking for a major open source project to create and spearhead, something that could get hundreds of thousands of active users and a thriving subcommunity, but I've been holding off until I find just the right project.
It sounds like you're looking for Ember. https://www.emberjs.com
Ember is a front-end framework, Rails is back-end.