sjrd

22 ms·

181.
by sjrd 9y ago
The Scala.js compiler, thanks to its static types, precisely knows which property accesses refer to "internal" properties (defined in Scala code, which can be renamed) and which ones refer to external JavaScript code (which cannot
182.
by sjrd 9y ago
That's a surprisingly positive result. Usually I expect most JavaScript libraries to be destroyed by Closure's Advanced optimizations, unless they've been written specifically with Closure in mind (which they're not). An
183.
by sjrd 9y ago
Direct link to the announcement: http://scala-lang.org/blog/2017/07/12/second-dotty-milestone...
184.
Simple Command Line Tools with Scala Native(spantree.net)
3 points by sjrd 9y ago|0 comments
185.
by sjrd 9y ago
In the standard types for the DOM [1], only types for standardized browser APIs are made available. Browser inconsistencies wrt. standards are dealt with polyfills, either written in JS because they already exist, or you can write them in S
186.
by sjrd 9y ago
Amazing :-D
187.
by sjrd 9y ago
Sure, you can just use `js.Dynamic`, or write `trait`s describing the "schema" of your JSON, and of you go. Let's say you have have an array of Persons with a name and age, you can type it as: @ScalaJSDefined trait
188.
by sjrd 9y ago
Thank you. No I wasn't there this year. I was furiously preparing this release :-p See you probably in London for Scala eXchange ;)
189.
by sjrd 9y ago
As I said in the parent, in the case of Scala.js, I believe we lose more performance because of the loss of static types than we would if we lost the JIT. Performance measurements in Scala Native, which has no JIT and is still quite young (
190.
by sjrd 9y ago
I read that article. They do not say anything wrong . But if you read between the lines, the article assumes your source language has types and does not have managed memory. Under those conditions, wasm will beat the JIT every time. But if
191.
by sjrd 9y ago
Ah ah!
192.
by sjrd 9y ago
Unlikely. I love compilers too much.
193.
by sjrd 9y ago
I'm not sure what you mean by "deep-copied" in this case. But I suspect it would involve losing the identity of the objects, which is unacceptable for correctness. Moreover, typical Scala.js code constructs cyclic dependencie
194.
by sjrd 9y ago
Better interoperability, definitely not. Scala.js already has the best interoperability out there, excluding languages with the same run-time semantics as JS (such as TypeScript). In fact, it is the lack of good interoperability in wasm t
195.
by sjrd 9y ago
Hopefully the new design means less interdependencies between all the collections. That would mean that the reachability analysis of Scala.js could be more aggressive in its dead code elimination.
196.
by sjrd 9y ago
Thank you for your kind words :) It's always nice to see that one's work is appreciated!
197.
by sjrd 9y ago
That would not solve that essential part: > it needs to integrate with JS objects, which means with the JS GC Otherwise we would have done it already.
198.
by sjrd 9y ago
> not so sure how WebAssembly does that Basically: badly. That's the number one reason we're not trying to compile Scala.js to wasm at the moment. For wasm to get the level of JS interop that Scala.js has, it needs to integrate
199.
by sjrd 9y ago
GC support can hardly be on Chrome's roadmap when the design of the spec has hardly anything more than "we want to have it, and here are some vague goals". So yes, we'll grow beards, but it will happen. Remember though t
200.
by sjrd 9y ago
You are mostly accurate wrt. the "financial" situation of Scala.js. Except that the Scala Center has an explicit Recommendation to "ensure the continuity of Scala.js" [1]. At least that means that, should I (the Ph.D. st
201.
by sjrd 9y ago
Scala.js author here. Ask me anything ;)
202.
by sjrd 9y ago
WebAssembly will most likely eventually provide a GC, at which point we'll do what we can to support compiling to wasm. See also: https://github.com/WebAssembly/gc/pull/1#discussion_r1109978...
203.
Announcing Dotty 0.1.2-RC1, a major step towards Scala 3(scala-lang.org)
13 points by sjrd 9y ago|0 comments
204.
by sjrd 9y ago
I don't think WebAssembly will become more common than JavaScript anytime soon. And even when it will be, it means the tooling will have become so good that you won't even have to think about WebAssembly. That will be left to the
205.
by sjrd 9y ago
No, it isn't the same confusion. The article describes a different problem (worse, IMO). Read it again, or read the following comment in this HN thread: https://news.ycombinator.com/item?id=14445829
206.
by sjrd 9y ago
No that's true for Scala. Scala has, in fact three kinds of "properties": * `val foo: Int`: always immutable , really. Every access always returns the same value * `var foo: Int`: mutable * `def foo: Int`: "getter&quo
207.
by sjrd 9y ago
I had exactly those two ideas, even before looking at the solution proposed in the article :)
208.
by sjrd 9y ago
True, and Scala is exactly the same. It uses Java APIs.
209.
by sjrd 9y ago
Dude, I'm the lead developer and maintainer of an OSS project with roughly 120 kLoC in Scala, and I probably break the build more often than not. (Of course commits don't make it into master until they're green.) In fact, I&#
210.
by sjrd 9y ago
Since you mention NetLogo, note that it has a Web version whose compiler is written in Scala.js. (The Scala.js compiler itself does not run in the browser, though.)

More ›