heijmans

You don't have to be an expert in TypeScript to know that the TypeScript compiler just strips the types from the code and leaves the rest as-is (if you are targeting a somewhat modern JS engine). The runtime performance of a TypeScript program is the same as that of the equivalent JavaScript program.

But of course, a TypeScript program could be much slower than a different JavaScript program, as is probably happening in this case.

I agree with others that the difference in results between JavaScript and TypeScript makes the quality of this paper highly suspect.

We are talking about the benchmark game here. The code for different languages was written by different programmers. For some languages, there were multiple implementations and many iterations. In this case, the researchers used the fastest one.

Some of the implementations are extremely optimized and took a lot of effort. Some implementations are not. So you might be comparing highly optimized JavaScript code with naive, below-average TypeScript code. You cannot compare those.

It would be much better if they used the same level of optimization for each language, but they didn't. Furthermore it is called a "Game" (it used to be called a "Shoot-out") because you shouldn't take it seriously. So it shouldn't be the basis of serious research.

Here is small example of ChatGPT giving a wrong answer without expressing any doubt (aka bullshitting):

https://chatgpt.com/share/69d78ec7-67b0-8395-9fd1-522b760ab5...

GPT-5.4 Thinking, Pro account.

Unfortunately, this will not be open source:

https://github.com/swc-project/swc/issues/571#issuecomment-7...

For more info, look at:

https://github.com/chalk/chalk/releases/tag/v5.0.0

https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...

And for the problems with esm and TypeScript:

https://github.com/microsoft/TypeScript/issues/46452

See also https://github.com/npm/cli/issues/2701

I think this is quite a serious issue which has been open for almost a year. I don't understand why there hasn't been a reaction from the npm developers on the issue (as far as I can see). npm 8.3.1 (the current version) is still vulnerable.

It might not be directly exploitable but it can leave you open for all kinds of security and/or stability issues. It is also a regression from npm 6.

It was actually reported on (or before) Jan 3rd.

See https://security.snyk.io/vuln/SNYK-JS-EXTEND2-2320315 .

It seems that they will release their software as open source. I couldn't find what license famo.us will use.

They are using CSS3 3d-transforms to create visual interfaces with good performance on modern browsers (including mobile). See:

http://famo.us/

(BTW: It took me a while to figure out that if you close the dialog window, you can click the buttons at the bottom for more demo's.)

Unfortunately they are only using the webkit-prefixed properties, so their demo doesn't work in Firefox or IE. I'm guessing they wrote their demo a couple of years ago and never updated it.

There are some problems with CSS3 3d-transforms: 1) Text looks blurry, just look at the dialog window in the demo. 2) Some mobile devices (e.g. old iPads) have limited GPU memory. If you use too much (by setting 3d-transforms on large surfaces), the browser (or your app) will crash.

By the way, the answer to the question in the title is: No. And if they don't open source their code, they won't get a lot of traction.

The documentation is scattered, but the best information can be found at:

https://github.com/cocaine/cocaine-docs-en/wiki

https://github.com/cocaine/cocaine-core#readme

https://github.com/cocaine/cocaine-core/wiki

The docs state that they refer to the 0.9 version, while development is going on in the 0.11 branch, so the docs might be more of less out of date.

It seems that they have already implemented a large part of the Heroku infrastructure, including service discovery, auto balancing, cross-language events (using ZeroMQ) and that they are using it in production. All in all, an impressive feat!

It would be interesting to hear if anyone has experience running/using this outside of Yandex. The source code seems well written, though comments are quite sparse.

As Lazare remarked, it seems to directly compete with flynn.io. It is good to see that different high-level platforms are created based on docker. But it would be nice if these platforms would consist of modules (for example service discovery or messaging) that can be used without using the whole kitchen-sink. I am not sure if this is possible with cocaine.

BTW, the repo cocaine-core is quite a bit older (since 2011) than docker (since early 2013?). The docker-core readme states that docker support is "on it's way" so it is not clear how mature this is.

P.S. As adults and hackers, can we look beyond the name at the technology presented here?

This is very impressive. The code is very readable, even the asm.js based code (which is probably written by hand). You can find the CPU code in js/worker/cpu.

On Chrome I get about 30 MIPS while running scummvm. On Firefox I get about 6 MIPS on the standard core and about 40 MIPS on the asm.js core.

I must say that I am impressed by Chrome performance on the standard core. However, sometime Chrome drops to about 6 MIPS for no discernible reason.

For people like me, who didn't know what OpenRISC is: http://en.wikipedia.org/wiki/OpenRISC

You're probably not serious, but for the OP this was the reason to start Rubunius X, as you can see here: http://rubini.us/2013/10/15/introducing-rubinius-x/

discussion: https://news.ycombinator.com/item?id=6553767

Personally I believe in "the best tool for the job".

While this sounds interesting and a lot of the features are laudable, it seems to me that such a language will no longer be "Ruby". All non-trivial Ruby code (like any library or gem) will not work in Rubinius X.

So why base this on Ruby? Because the syntax is nice? Perhaps it would be better to start with something like elixir, which has a syntax based on Ruby, works with existing Erlang libraries and has good (perhaps excellent) support for concurrency and immutability.

MagStream is hiring in The Hague, Netherlands. We are looking for both Junior and Senior JavaScript developers.

We are currently building an HTML5 / CSS3 / JavaScript based platform for designing and viewing multimedia magazines. We are a small, dedicated company that works for big companies and other happy clients.

For us motivation and team spirit are more important than experience. We are looking for programmers who enjoy creating new products, learning new tech and solving problems. Join us in building the best publication platform!

Contact me at jan at magstream dot com for more info.