airless_bar

11 ms·

31.
by airless_bar 10y ago
Android integration works fine, and the SBT builder is so much better and faster than Google's Gradle one. In fact SBT + ProGuard is faster than Gradle + no ProGuard.
32.
by airless_bar 10y ago
The C++ comparison is great because it tells readers that that the person making it has no idea about C++, Scala or both.
33.
by airless_bar 10y ago
What Oracle does is cute, but I will put my bet on people who have a solid track record at shipping.
34.
by airless_bar 10y ago
Oh come on Cedric. You managed to troll better in the past. As you surely know it already, the deprecate-remove cycle is pretty much how a) Scala works and b) C# doesn't work.
35.
by airless_bar 10y ago
There are worlds between Java 8 and Scala and the gap is widening with every release. Of course you can write Java in Scala and then the benefits over Java aren't that high (but are still there), but Scala is so far ahead in terms of l
36.
by airless_bar 10y ago
Not parent, but I would reduce it down to - C# with VisualStudio + JetBrains addon - Java with IntelliJ Why not the others you mentioned? - IDE support for F# is not very good. - VB is too dynamically typed to be reliable. - C++ IDEs seem t
37.
by airless_bar 10y ago
The difference is that Scala devs didn't push for immediate adoption while they were still working things out. Apple's Swift message is more or less "Stop writing Objective-C if you can and start using Swift – oh and by the w
38.
by airless_bar 10y ago
Scala has been vastly improved since 2.8. If the experience you stated comes from Scala 2.8 I think you will love the way things are working currently. I wouldn't want to go back to 2.8 even if people paid me a ton of money. I love ML,
39.
by airless_bar 10y ago
Scala's versioning scheme is publicized and well-understood. Are you trying to blame Scala for not adopting SemVer before SemVer even existed? Very silly.
40.
by airless_bar 10y ago
How do you plan to deal with the large amount of metadata required for some stuff? Like the timezone database for calendars, the CLDR for formatting stuff, or various Unicode tables for handling case folding/comparions/etc.? Will
41.
by airless_bar 10y ago
> 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
42.
by airless_bar 10y ago
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).
43.
by airless_bar 10y ago
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.
44.
by airless_bar 10y ago
These are not minor releases.
45.
by airless_bar 10y ago
And that's perfectly fine! I won't throw a tantrum because I might disagree (which I don't).
46.
by airless_bar 10y ago
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 value
47.
by airless_bar 10y ago
The slides mention that proper tail calls "just work", even mutual ones. :-)
48.
by 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
49.
by airless_bar 10y ago
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.
50.
by airless_bar 10y ago
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.
51.
by airless_bar 10y ago
Thanks for the downvote. Let's close this discussion.
52.
by airless_bar 10y ago
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&#x2
53.
by airless_bar 10y ago
So what? If you can't tolerate an opinion I can imagine you are having a hard time on the internet. :-)
54.
by airless_bar 10y ago
Ouch.
55.
by airless_bar 10y ago
> 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
56.
by airless_bar 10y ago
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
57.
by airless_bar 10y 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
58.
by airless_bar 10y ago
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:
59.
by airless_bar 10y ago
> 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-nat
60.
by airless_bar 10y ago
Jesus Christ, just get on with times. Even Node has overtaken Rust.

More ›