Live data from Hacker News

Why the New V8 Is So Damn Fast

nodesource.com

131–140 of 237 posts

Re: Why the New V8 Is So Damn Fast

#131
post #12

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

Personally, having developed in both Rails and Node, I now believe that trying to recreate Rails in JS is a foolish effort. Rails is a huge project with a ton of weight behind it and unless you can generate a massive amount of corporate investment, you won't ever be able to really catch up. I'm not saying that there's no room in the JS ecosystem for another web framework, what I'm saying is that if your design goal i…

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.

Re: Why the New V8 Is So Damn Fast

#132
post #9

I 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…

JITs aren't a panacea for everything. As the blog post said, if you want to avoid falling off a performance cliff you must write "CranskshaftScript" instead of Javascript. And the only way to be sure that the optimizer is content through a specialized profiler.

Re: Why the New V8 Is So Damn Fast

#133
post #15

Earlier quoted context omitted.

I would insanely choose ruby rather than javascript for the major advantages that has to offer. Performance in most of cases is not a real needed over consistency. Also Ruby 2.6 has jit, would be great to see some bench tests. :P

Isn't there a Ruby->JS transpiler?

Opal: https://github.com/opal/opal

Re: Why the New V8 Is So Damn Fast

#134
post #116

As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.

Don't be too jealous. My main concern with Node and its ecosystem is maturity and security. It loses hands down on both those points compared Ruby / Rails especially in the area of dependencies. This keeps me happily in Rubyland.

> security ... Rails

One bad default setting and [0]BOOM! [0]https://github.com/rails/rails/commit/b83965785db1eec019edf1...

Re: Why the New V8 Is So Damn Fast

#136

As an internet user, I really enjoy reading about all these performance improvements in V8 / javascript. As a ruby developer, I'm insanely jealous.

You say "Ruby developer" as if you were born like that and stuck with it. There's an entire world out there!

Re: Why the New V8 Is So Damn Fast

#137

I speculated recently that TypeScript might _de facto_ help V8 optimizations, and the post seems to confirm that. https://clipperhouse.com/does-typescript-make-for-more-perfo...

Yeah, I've always wondered this too. It would be cool to be able to extract typings in a separate file, like source maps, and send over the wire along with the JavaScript bundle (for compatibility).

It would definitely help moving sections of the code up the tier ladder, not unlike Web Assembly.

I even predict that future typescript versions would include stricter typings optimized for an browser to solve problems like others have mentioned in the thread.

Or just a TypeScript engine in the browser, like ehm Dartium. I guess someone at Microsoft already did this on IE in a hackathon or something.

Re: Why the New V8 Is So Damn Fast

#138

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

The compiler can also perform optimizations that are impossible for a JIT because they're too expensive. JITs have to balance execution speed with compilation time. It's not so clear cut which approach in theoretically superior. I also don't know any languages where a JIT and an AOT compiler have gotten equivalent amounts of engineering hours so that we could have a fair comparison.

Re: Why the New V8 Is So Damn Fast

#139

Earlier quoted context omitted.

I researched this yesterday against Crystal. Seems people won’t touch it because of oracle. Which is a real shame. Truffle is a 9x improvement in speed over Ruby. But because Oracle is a patent nightmare and a dying organization. People aren’t interested.

Uh, how is oracle a dying organization?

I went to go look for evidence of oracle dying and actually came up empty handed. I was also under this impression. I think it has waned significantly in popularity in the developer community over the years, but their stock isn’t bad at all and they seem to have diversified quite a bit in the time they’ve existed.

Re: Why the New V8 Is So Damn Fast

#140

Earlier 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…

Wouldn't it be good if JavaScript also starts supporting python like type annotations (completely optional, but unlike python used to guide the optimizer. Given that some non trivial amount of JS is already generated after type checking (typescript, flow, and all the statically typed languages compiling to JS), all this compile time type info could be made available to the optimizer.

That's basically what asm.js was, just less friendly to human readers.
Post reply on HN