airless_bar's comments

> We're reimplementing / porting from Apache Harmony all the things we need.

Doesn't that create licensing issues? You already seem to have code from Harmony in the project, but the project's license is neither Apache nor does it mention it.

Additionally, won't that cause trouble with Oracle, considering the lawsuit against Google?

Is there a difference between @extern and @native?

I could have imagined that it would have been more compatible if Scala-JVM and Scala-Native used the same annotations (using JNI behind the scenes on the JVM).

To be more familiar to Java developers.

There are some thoughts about migrating people away from + toward string interpolation. But automated conversion tools are required before this can happen.

These are not minor releases.

And that's perfectly fine! I won't throw a tantrum because I might disagree (which I don't).

Alright. Sorry.

Regarding your question about nulls and Java:

I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability".

As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first.

The approach of supplying external nullability meta data has largely been a failure, because

a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing

b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind

c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions

As soon as Java library authors themselves start using @Nullable/@NonNullable annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim.

The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.

The slides mention that proper tail calls "just work", even mutual ones. :-)

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

People who can't assess statements objectively are probably exactly those people whose opinion I couldn't care less about.

Perhaps this is exactly the filter I want to have.

This sounds like a very US-trigger-warning-safe-spacey stance.

I think most people on this planet are able to consider each point at its face value.

Thanks for the downvote. Let's close this discussion.

Well, then we got different sources.

Scala is developed by the EPFL, Lightbend, and ScalaCenter. That's three, not one.

> Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.

That hasn't been true for more than half a decade.

So what? If you can't tolerate an opinion I can imagine you are having a hard time on the internet. :-)

Ouch.

> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable.

Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release.

> Null

Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null.

> - Type inference

Type inference is not a huge priority, because people think that it's a good thing that declarations require type annotations (just like it's recommended in Haskell, too). One of the last pain-points, higher-kinded unification of type constructors, has been fixed recently which will make type inference "just work" in exactly those cases where the lack of type inference was most annoying.

> - Tooling

I think tooling is pretty amazing. Sure, Java has still some advantages in some places. But the tooling is superior to almost all other languages out there. SBT is amazing. IDE support is getting vastly better, not only have Eclipse and IntelliJ improved vastly, but also IDE support for Emacs, Vim, Sublime, etc. is coming along at a rapid rate, and it's just amazing to use. There are so many tools in the Scala ecosystem which just don't exist in this combination anywhere else.

No, not really.

Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed.

Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate on X and Y!".

The last unhappy company which is commonly mentioned is this social-network company Yammer. That was half a decade ago, and most of the issues mentioned have been addressed in the mean time. (Yammer has been bought by Microsoft, so it also made some sense to use a language that makes getting bought out easier.)

¹ I remember there was some very very bitter Groovy evangelist a while ago.

Scala is a pretty great language on its own.

Have a look at the adoption of Scala.js. The ecosystem of Scala.js is larger than the "compile-to-js" ecosystems of "rust, Haskell, go, c++" combined.

One of main strengths of Scala is that people get things done. It's the only language of the ones you mentioned which has reasonable support across three vastly different platforms.

Not the author:

> - Can this reuse existing Scala code?

I think that's the plan. Would be a pretty pointless exercise without that, right? :-)

> - How does it compare against Rust/GO/Swift? Why use this over them?

Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala is faster to develop.

Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes.

Swift: Scala is more mature, simpler, better designed. Not a knock against Swift, but there is a difference between a language where changes have been tried experimentally for years before either adopting or removing them, and Swift where things get added at a frightening rate.

> - How about libraries?

Libraries without Java dependencies should work, libraries with Java dependencies depend on whether their Java dependency is provided by Scala-Native (just like on Scala.js).

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

Jesus Christ, just get on with times.

Even Node has overtaken Rust.