News for hackers. Stuff that matters.

A comment on Scala Native. Parent comment

Re:Scala Native by airless_bar on Wednesday May 11, 2016 @06:06PM (#11679732)
Scala macros are compile-time. The Scala reflection library (that works at runtime) share most API with macros.

Macros should always work, reflection is harder as some information needs to be retained at runtime (either via Java reflection or additional data – which can both be problematic in Scala.js).

[ Parent | on HN ]
Re:Scala Native by acjohnson55 on Wednesday May 11, 2016 @10:36PM (#11680965)
And as the original author of Scala.js pointed out in a Scala Days talk today, unrestricted reflection means that it's impossible to do dead code elimination, which is a non-starter for real-world use.
[ Parent | on HN ]
Re:Scala Native by jfoutz on Wednesday May 11, 2016 @11:30PM (#11681135)
I've got at least 30 enterprise applications that disagree with your "nonstarter" assertion. Dead code can only exist in real world code.
[ Parent | on HN ]
Re:Scala Native by acjohnson55 on Thursday May 12, 2016 @02:07AM (#11681646)
I'm talking about within the main use case, which is front-end web development. I guess some folks might be cool with 10MB+ JS apps, but I don't think that would be terribly popular, and certainly not popular enough to bother with imitating Java reflection in JavaScript.
[ Parent | on HN ]
Re:Scala Native by paulddraper on Wednesday May 11, 2016 @11:43PM (#11681174)
Well, Proguard does whole program optimization.

You have to specify the symbols to preserve explicitly.

[ Parent | on HN ]
Re:Scala Native by grogs on Thursday May 12, 2016 @02:51AM (#11681816)
I believe that works against jvm bytecode, which you don't get for scalajs. Instead the compiler has a JS specific intermediate representation which the optimizations occur on.
[ Parent | on HN ]