4 ms·

> just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Most Scala libraries never used reflection, so most of the ecosyste

> just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. I think quite a few things in scala-native are there to show the possibilities of this platform, but in the mid- to long-term those improvements will be supported everywhere: - @struct and AnyVals: As soon as AnyVals can support more than one value on the JVM (as soon as Oracle finally gets some things done) @struct can go away, because it's equivalent to AnyVal. - @extern and @native could also end up being the same. - @inline and @noinline are already supported across platforms.

brianwawok 10y ago
> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked. I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc. It wasn't impossible, but it was a lot of work.
- Negative1 10y ago
  You're talking about Play Framework, I assume. They did some fancy work with Macros (i.e. Scala Reflection) which causes a lot of headaches for Scala.js. The reality is most of the reflection it does is nice but not necessary and I really wish they offered a "switch" to turn it off.
  - brianwawok 10y ago
    Ya play is where I started, then I moved my app into Scala.JS land. Had some cool parts to it, but not sure I was sold on the overall experience. I hate JS so bad and want to avoid it, but I kind of felt like I was mostly trading evils. Maybe if I worked at it enough it would finally get better? Not sure
    - grogs 10y ago
      When did you try it out? What didn't you like? I ported a site written in vanilla Javascript. I decided to faithfully port it without any changes before introducing scala specific libraries. That was pretty painful. A bunch of manual casting for UndefOr and js.Function. Since then I've started using some of the scalajs libraries/frameworks straight away on projects. It has been a much more pleasant experience!
  - nothrabannosir 10y ago
    Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference? If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect? Or am I looking at this the wrong way?
    - airless_bar 10y ago
      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).
      - acjohnson55 10y ago
        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.
        jfoutz 10y ago
        I've got at least 30 enterprise applications that disagree with your "nonstarter" assertion. Dead code can only exist in real world code.
        acjohnson55 10y ago
        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.
        deleted 10y ago
        [deleted]
- bad_user 10y ago
  It's not because of reflection. Most Scala libraries are reflection free. Exceptions are Scala libraries wrapping Java ones, or Scala libraries that are doing Java serialization / deserialization, which many times depends on reflection. For example JSON parsing in Scala many times piggybacks on Jackson, THE Java library for JSON parsing. However there are JSON parsing libraries that are pure Scala and that do not require reflection like Jackson does. But reflection isn't usually an issue for Scala as Scala code does most of the same tricks at compile-time. Scala libraries that have problems are those libraries dealing with multi-threading. Do you block threads anywhere, waiting for a Future, or on a CountDownLatch? Any await/notify anywhere? Sorry, that won't work on top of Scala.js. That doesn't mean that you can't work around it though and it does take effort on the part of library authors. My own library (sorry for the shameless plug :)) is completely cross-platform: https://monix.io https://monix.io BTW, Scala.js is very new, but the whole ecosystem wants to support it, every major library is being ported if not ported already and everybody is talking about it ;-)

brianwawok 10y ago

> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked. I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc. It wasn't impossible, but it was a lot of work.

Negative1 10y ago
You're talking about Play Framework, I assume. They did some fancy work with Macros (i.e. Scala Reflection) which causes a lot of headaches for Scala.js. The reality is most of the reflection it does is nice but not necessary and I really wish they offered a "switch" to turn it off.
- brianwawok 10y ago
  Ya play is where I started, then I moved my app into Scala.JS land. Had some cool parts to it, but not sure I was sold on the overall experience. I hate JS so bad and want to avoid it, but I kind of felt like I was mostly trading evils. Maybe if I worked at it enough it would finally get better? Not sure
  - grogs 10y ago
    When did you try it out? What didn't you like? I ported a site written in vanilla Javascript. I decided to faithfully port it without any changes before introducing scala specific libraries. That was pretty painful. A bunch of manual casting for UndefOr and js.Function. Since then I've started using some of the scalajs libraries/frameworks straight away on projects. It has been a much more pleasant experience!
- nothrabannosir 10y ago
  Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference? If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect? Or am I looking at this the wrong way?
  - airless_bar 10y ago
    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).
    - acjohnson55 10y ago
      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.
      - jfoutz 10y ago
        I've got at least 30 enterprise applications that disagree with your "nonstarter" assertion. Dead code can only exist in real world code.
        acjohnson55 10y ago
        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.
      - deleted 10y ago
        [deleted]
bad_user 10y ago
It's not because of reflection. Most Scala libraries are reflection free. Exceptions are Scala libraries wrapping Java ones, or Scala libraries that are doing Java serialization / deserialization, which many times depends on reflection. For example JSON parsing in Scala many times piggybacks on Jackson, THE Java library for JSON parsing. However there are JSON parsing libraries that are pure Scala and that do not require reflection like Jackson does. But reflection isn't usually an issue for Scala as Scala code does most of the same tricks at compile-time. Scala libraries that have problems are those libraries dealing with multi-threading. Do you block threads anywhere, waiting for a Future, or on a CountDownLatch? Any await/notify anywhere? Sorry, that won't work on top of Scala.js. That doesn't mean that you can't work around it though and it does take effort on the part of library authors. My own library (sorry for the shameless plug :)) is completely cross-platform: https://monix.io https://monix.io BTW, Scala.js is very new, but the whole ecosystem wants to support it, every major library is being ported if not ported already and everybody is talking about it ;-)