19 ms·

Scala Native

466 points by virtualwhys 10y ago

grandinj 10y ago
Given that Apache harmony is no longer being developed, you might want to coordinate with the Avian people, since they also reuse harmony.
dsabanin 10y ago
Really excited about this. This is another reason why Scala is an extremely valuable tool these days. With Scala JVM, Scala.js with React Native and now with Scala Native (LLVM), there'll be literally nothing you can't do well with it.
- xavi 10y ago
  That's one of the things I like about Clojure too, i.e. that is a good tool for many jobs, in part because it runs on the JVM, the browser (ClojureScript), and can also be used to build React Native apps (http://cljsrn.org/ http://cljsrn.org/).
- estefan 10y ago
  Does Scala.js with React Native work well? I avoided it because I didn't want to complicate my stack or have to jump through hoops when reading the react docs. If it all works well I might make the jump to scala front & back...
  - sjrd 10y ago
    Reportedly, it works really well. Have a look at https://github.com/chandu0101/sri https://github.com/chandu0101/sri
spriggan3 10y ago
Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".
- duaneb 10y ago
  I would argue scala' main selling point is making the jvm palatable to people who hate Java. However, it's entirely unclear without the jvm why I would choose it over, say, rust, Haskell, go, c++, etc.
  - dsabanin 10y ago
    That is a very narrow view of Scala. It's a great and powerful language.
    - the_af 10y ago
      No-one denies Scala is a fine language, but I don't think that's a narrow view of it. It's actually a pretty good question. A lot of Scala's design is full of compromises made for Java inter-op. A huge motivation for using Scala is "I want a modern language which allows me to use all these existing Java libraries and tools". If you remove the ecosystem and the inter-op, what is there left for Scala? Why not use a better language?
      - dsabanin 10y ago
        I don't think the amount of compromises in Scala is more than the amount of compromises in any other language. No matter how clean the language starts up to be, after a certain time it always has to accumulate compromises with it's own previous design decisions, unless it's being kept in the never-ending alpha release state. Can you provide an example of what you think is a better language?
      - hibikir 10y ago
        Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.
densh 10y ago
Hi all, I'm the author of the project and would gladly answer any questions.
- spriggan3 10y ago
  On what OS does it run right now?
  - grenoire 10y ago
    Mentions using LLVM, so all OS should work. Not sure about the stdlib.
    - jjnoakes 10y ago
      All OSs which LLVM supports should work. Not quite "All OS".
  - densh 10y ago
    Scala Native is currently being developed on Darwin/Intel/x64. If you can compile and run C code with Clang on some platform, it's reasonable to expect Scala Native to be run there eventually as we're based on the the same underlying compiler toolchain. Currently we mostly aim at POSIX environments.
- dsabanin 10y ago
  Just wanted to say thank you for your amazing work!
- badlogic 10y ago
  How's the managed runtime implemented (GC, memory model, etc.)? How did you get rid of JVM and JRE class library dependencies of Scala? What's the debugging story? I'd be great if this kind of info found its way onto th website. Is this in any way related to vmkit? Excited about this, keep up the great work!
  - more_original 10y ago
jiang101 10y ago
Wow, they're even planning to provide a native version of the runtime library? That will be more than nice.
abc_lisper 10y ago
Hi, Some questions - Can this reuse existing Scala code? - How does it compare against Rust/GO/Swift? Why use this over them? - How about libraries?
- edko 10y ago
  A difference is that Scala can run on the JVM, the browser (and other JS ecosystems) via ScalaJS, and now native. It doesn't get more universal than that!
  - pjmlp 10y ago
    Native is all that it takes. Bytecodes are great for optimization passes and interactive development sessions. Java should have gone the native route for deployment, instead of having a few architects at Sun being religious against AOT compilation.
    - edko 10y ago
      The other two are important too: the JVM lets you leverage lots of existing libraries. The browser lets you reach more users.
      - pjmlp 10y ago
        Yes, but many of the use cases those libraries cover are also covered by other libraries. The browser, well personally I am not a big fan for anything besides interactive hypertext documents. Even though I worked several years as web developer, I tend to favor native + network protocols instead. Many researchers jumped into the JVM because it provided a fertile ground for language research, without having to build their own. Apparently LLVM brought a change to that and now everyone is using it instead of the JVM for language research, with the benefit of always having JIT and AOT toolchains, with GCC trying to follow up on that. What I dislike in the JVM was the religion against AOT compilation (only third party commercial JVMs offer it) and missing out on value types, even though Eiffel, Oberon and Modula-3 where all having them. Personally I think all language toolchains should offer JIT/AOT, with the developers using the best one for each deployment use case. Although for dynamic languages, AOT is probably not a good use case.
OhHeyItsE 10y ago
Otherwise known as "Haskell"?
- dsabanin 10y ago
  Yeah, think of it as practical Haskell that you can actually use in your day to day work ;-)
  - the_af 10y ago
    Haskell is a practical language, and one usual impediment for using it in your day to day work is "we must use the JVM". What happens if you remove that requirement? :)
    - dsabanin 10y ago
      Haskell seriously lacks mature tooling, like IDEs, and also libraries. It's still a niche language and it suffers from that. I think it's pretty clear it's not going anywhere close to mainstream any time soon.
      - the_af 10y ago
        That's debatable. Some tooling is needed, some (like IDEs) are mostly unnecessary; crutches we're used to because some languages are unbearable to use otherwise. IMO it's a niche language because, unlike Scala, it requires a clean break from the way the mainstream industry sees programming languages. But don't mistake that for lack of practicality!
        dsabanin 10y ago
        I don't subscribe to the point that IDEs are crutches any more. I don't rely on IDEs to generate code for me, I use them to explore code and refactor it efficiently. Good refactoring support in IDE can save you a lot of time and errors, especially in the statically typed languages. It has nothing to do with language being unbearable, but a lot to do with the size and complexity of the code you have to work with. I have nothing against Haskell, and before sticking with Scala I've seriously considered it. However, having things like Akka in Scala, an actor/OTP framework that is the only one that is even remotely comparable to what Erlang has, was a huge benefit. Other tools like Play, Spark also made choosing Haskell an unpractical decision for me. Besides, after a couple years of excursion into pure FP-only approach to development, I've understood to myself that OOP is not in any way in opposition to FP, but can be a rather welcome addition. Especially when you work with big code bases and you plan to maintain them for many years to come. And that is an area where Scala really shines.
openasocket 10y ago
Is this a "true" Scala? As in, if I write a Scala program that only uses the scala stdlib, will it run on both the JVM and Scala native with no modifications to the source? Or, is it more like "a Scala" in the same way you would say "a Lisp"? I think a lot of the design decisions for Scala were made so that Scala would work on the JVM and easily inter-op with Java. It might make more sense to modify the language slightly to better suit the native environment. I'm seeing some hints to that on the page with the "@struct" and "@extern" decorators.
- brianwawok 10y ago
  Clearly they added a bunch of new stuff that the JVM can't understand. So it is either "Scala like LISP" or It is a superset of the Scala language. Meaning all existing stuff will work with it, but if you use new secret keywords it will work "better". Which seems not quite ideal, because that means most Scala libraries will not be "tuned", and you will need all new libraries.. just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Worried the Scala ecosystem is turning into a nightmare ;)
  - openasocket 10y ago
    It's not necessarily a bad thing: you can think about the various Scala implementations as dialects in a language family, like Pascal in the old days. It may be difficult to share code between these dialects, but it allows people to write code for a wide variety of environments using the same syntax and nearly-identical semantics.
  - 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-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.
partycoder 10y ago
In a way, simple Scala code resembles Swift, as commented by this person: https://leverich.github.io/swiftislikescala/ https://leverich.github.io/swiftislikescala/ Now the type system of course is entirely different.
- kbenson 10y ago
  val label = "The width is " val width = 94 val widthLabel = label + width I really wish more languages would distinguish concatenation from addition, especially when they do type coercion. There's a very specific reason Perl opted for '.' to concatenate strings instead of +, which is that it disambiguates the following: val first = "2" val second = 3 val together1 = first + second val together2 = second + first Not to mention, addition is commutative and concatenation is not (1+2 == 2+1, but "one" + "two" != "two" + "one") Hopefully Scala at least has some very well defined and easy rules for exactly how string concatenation works, but I think it's an uphill battle to argue that '+' is a good concatenation operator.
  - coldtea 10y ago
    Maybe, but in 20 years of programming (and 10+ of them with dynamic languages) I don't think I have had that issue more than 2-3 times. (1) Passing an int/string when a function expects the other type? Yes, I had that happen lots. (2) Concatenating a string and a (coerced) int? It's either a much narrower subproblem of (1), or exactly what I wanted to happen in the first place (e.g. print "Your score is: " + n + " points".
    - kbenson 10y ago
      I've dealt with it lots. While concatenating variable and string literals like your example is very rarely ambiguous, but what can be is using + to operating on two variables whose input has been returned from elsewhere. Does that function that gets the user supplied value for height automatically convert to a numerical type, or is it a string? What about the function that gets the user supplied value for width? Is it stored in a back-end format that strictly types those fields to ensure that if the data is set from some less frequently used method it has the same type (e.g. are you storing as JSON, and can this JSON be created from multiple code paths?) Given a simple statement like "foo = bar + baz", why should there be ambiguity when there doesn't need to be? The glib answer to the problem is to tell people to use better variable names, or document their functions better, or any number of suggestions that put the onus on the programmer, when this is a very simple to solve problem. Don't overload operators in the core language for conceptually different actions. We don't "add" strings, we concatenate them. Add is at best, shorthand for "add to end of" which means to append. Coercion can be a useful tool, except for when it creates confusion. There are well known and tested ways to combat this confusion, so I'm not sure why we haven't adopted them widely where coercion is in use. P.S. It's not just addition. Testing for equality is another common case where coercion can cause problems. The answer to that is equally as simple, use a different operator (such as "eq" and "ne" for string equality in Perl). Numeric equality is not the same as string equality (10.0 is equivalent to 10, but "foo." is not equivalent to "foo"), and making the programmer think (not not!) about what will happen when using an overloaded equality operator on two variables just shifts a small amount of up-front cost when learning the language (we have different operators for string concatenation and equivalence testing, learn them) to a cost imposed every time the programmer has to use those operators.
smegel 10y ago
What about GC?
- BenoitP 10y ago
  True. I wonder if the "Extern objects" section mentioned malloc for a reason.
- densh 10y ago
  In a first release we're going to use Boehm GC. That's just a stepping stone, not a long-term strategy. Stay tuned for news on this front.
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: 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).
- abc_lisper 10y ago
  > Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes Woah!
  - jjuel 10y ago
    Clearly people either love or hate Go. There is a lot of hate I've seen on HN. I personally love it, but who am I to say what is a good language and what isn't.
    - ihsw 10y ago
      Clearly people have opinions that range across a wide spectrum on any subject. To say interest in is divided into either hate or love is disingenuous.
    - placeybordeaux 10y ago
      Honestly I'd expect to see the most Go hate on a thread about scala. The design principals of both languages are completely at ends with each other.
  - 10y ago
gnufied 10y ago
So, is this "released" yet? There are no downloadable installers or even instructions to compile.
- Scarbutt 10y ago
  Looks like its based on dotty so Java 8 is a requirement.
  - densh 10y ago
    It's currently based on Scala 2.11 with 2.12 and Dotty support coming in the future.
- joostdevries 10y ago
  It is not released. But you can publish it locally. Compiling the demo-native subproject seems to work. When I try to run it I get a LinkingError though.
  - densh 10y ago
    Demo reproduction guide to be published in next few days.
- densh 10y ago
  No, it's not released yet, just publicly announced. Developer preview is planned to be released in the future. Stay tuned for further updates.
ihsw 10y ago
Such blatant ignorance, cognitive dissonance, and chauvinism is astounding. I have worked with tools like you and I hope I never do again, your attitude is toxic and I doubt your professional capability.
- dsabanin 10y ago
  He attacked a language, an abstract concept, you've attacked a living person. You're a bit of a tool yourself, I might say.
  - ihsw 10y ago
    I don't care what he attacks, he's talking out of his ass and he's not shy about it.
- dang 10y ago
  Personal attacks are not allowed on HN. We ban accounts that do this, so please don't do it again. Instead, please (re-)read the site guidelines and make sure your posts are civil and substantive. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=11678838 https://news.ycombinator.com/item?id=11678838 and marked it off-topic.
cbeustwatch 10y ago
Hello Cedric Beust, you really need to stay off Scala threads. When are you going to delete your hacker news account just like your reddit account. Do it for the sake of your own reputation. https://www.reddit.com/r/scala/comments/454ahd/recent_dottyscala_fud/ https://www.reddit.com/r/scala/comments/454ahd/recent_dottys...
- dang 10y ago
  You can't attack someone like this on HN no matter how bad their contribution to programming language discussion on the internet. If you think you see abuse here, do please let us know at hn@ycombinator.com. We promise to look into it. But single-purpose accounts, let alone ones targeting individuals, aren't allowed here, so we've banned this one. We detached this comment from https://news.ycombinator.com/item?id=11681233 https://news.ycombinator.com/item?id=11681233 and marked it off-topic.
CheKhovHemingw8 10y ago
Another thread covers in hands-on way Getting Started: https://news.ycombinator.com/item?id=11699897 https://news.ycombinator.com/item?id=11699897

466 points by virtualwhys 10y ago

Given that Apache harmony is no longer being developed, you might want to coordinate with the Avian people, since they also reuse harmony.

dsabanin 10y ago

Really excited about this. This is another reason why Scala is an extremely valuable tool these days. With Scala JVM, Scala.js with React Native and now with Scala Native (LLVM), there'll be literally nothing you can't do well with it.

xavi 10y ago
That's one of the things I like about Clojure too, i.e. that is a good tool for many jobs, in part because it runs on the JVM, the browser (ClojureScript), and can also be used to build React Native apps (http://cljsrn.org/ http://cljsrn.org/).
estefan 10y ago
Does Scala.js with React Native work well? I avoided it because I didn't want to complicate my stack or have to jump through hoops when reading the react docs. If it all works well I might make the jump to scala front & back...
- sjrd 10y ago
  Reportedly, it works really well. Have a look at https://github.com/chandu0101/sri https://github.com/chandu0101/sri

spriggan3 10y ago

Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".

duaneb 10y ago
I would argue scala' main selling point is making the jvm palatable to people who hate Java. However, it's entirely unclear without the jvm why I would choose it over, say, rust, Haskell, go, c++, etc.
- dsabanin 10y ago
  That is a very narrow view of Scala. It's a great and powerful language.
  - the_af 10y ago
    No-one denies Scala is a fine language, but I don't think that's a narrow view of it. It's actually a pretty good question. A lot of Scala's design is full of compromises made for Java inter-op. A huge motivation for using Scala is "I want a modern language which allows me to use all these existing Java libraries and tools". If you remove the ecosystem and the inter-op, what is there left for Scala? Why not use a better language?
    - dsabanin 10y ago
      I don't think the amount of compromises in Scala is more than the amount of compromises in any other language. No matter how clean the language starts up to be, after a certain time it always has to accumulate compromises with it's own previous design decisions, unless it's being kept in the never-ending alpha release state. Can you provide an example of what you think is a better language?
    - hibikir 10y ago
      Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants something else is deluded. The Scala way is to say 'sure, you can do that too, to hell with purity'. I'd rather have power over purity any day.

densh 10y ago

Hi all, I'm the author of the project and would gladly answer any questions.

spriggan3 10y ago
On what OS does it run right now?
- grenoire 10y ago
  Mentions using LLVM, so all OS should work. Not sure about the stdlib.
  - jjnoakes 10y ago
    All OSs which LLVM supports should work. Not quite "All OS".
- densh 10y ago
  Scala Native is currently being developed on Darwin/Intel/x64. If you can compile and run C code with Clang on some platform, it's reasonable to expect Scala Native to be run there eventually as we're based on the the same underlying compiler toolchain. Currently we mostly aim at POSIX environments.
dsabanin 10y ago
Just wanted to say thank you for your amazing work!
badlogic 10y ago
How's the managed runtime implemented (GC, memory model, etc.)? How did you get rid of JVM and JRE class library dependencies of Scala? What's the debugging story? I'd be great if this kind of info found its way onto th website. Is this in any way related to vmkit? Excited about this, keep up the great work!
- more_original 10y ago

jiang101 10y ago

Wow, they're even planning to provide a native version of the runtime library? That will be more than nice.

abc_lisper 10y ago

Hi, Some questions - Can this reuse existing Scala code? - How does it compare against Rust/GO/Swift? Why use this over them? - How about libraries?

edko 10y ago
A difference is that Scala can run on the JVM, the browser (and other JS ecosystems) via ScalaJS, and now native. It doesn't get more universal than that!
- pjmlp 10y ago
  Native is all that it takes. Bytecodes are great for optimization passes and interactive development sessions. Java should have gone the native route for deployment, instead of having a few architects at Sun being religious against AOT compilation.
  - edko 10y ago
    The other two are important too: the JVM lets you leverage lots of existing libraries. The browser lets you reach more users.
    - pjmlp 10y ago
      Yes, but many of the use cases those libraries cover are also covered by other libraries. The browser, well personally I am not a big fan for anything besides interactive hypertext documents. Even though I worked several years as web developer, I tend to favor native + network protocols instead. Many researchers jumped into the JVM because it provided a fertile ground for language research, without having to build their own. Apparently LLVM brought a change to that and now everyone is using it instead of the JVM for language research, with the benefit of always having JIT and AOT toolchains, with GCC trying to follow up on that. What I dislike in the JVM was the religion against AOT compilation (only third party commercial JVMs offer it) and missing out on value types, even though Eiffel, Oberon and Modula-3 where all having them. Personally I think all language toolchains should offer JIT/AOT, with the developers using the best one for each deployment use case. Although for dynamic languages, AOT is probably not a good use case.

OhHeyItsE 10y ago

Otherwise known as "Haskell"?

dsabanin 10y ago
Yeah, think of it as practical Haskell that you can actually use in your day to day work ;-)
- the_af 10y ago
  Haskell is a practical language, and one usual impediment for using it in your day to day work is "we must use the JVM". What happens if you remove that requirement? :)
  - dsabanin 10y ago
    Haskell seriously lacks mature tooling, like IDEs, and also libraries. It's still a niche language and it suffers from that. I think it's pretty clear it's not going anywhere close to mainstream any time soon.
    - the_af 10y ago
      That's debatable. Some tooling is needed, some (like IDEs) are mostly unnecessary; crutches we're used to because some languages are unbearable to use otherwise. IMO it's a niche language because, unlike Scala, it requires a clean break from the way the mainstream industry sees programming languages. But don't mistake that for lack of practicality!
      - dsabanin 10y ago
        I don't subscribe to the point that IDEs are crutches any more. I don't rely on IDEs to generate code for me, I use them to explore code and refactor it efficiently. Good refactoring support in IDE can save you a lot of time and errors, especially in the statically typed languages. It has nothing to do with language being unbearable, but a lot to do with the size and complexity of the code you have to work with. I have nothing against Haskell, and before sticking with Scala I've seriously considered it. However, having things like Akka in Scala, an actor/OTP framework that is the only one that is even remotely comparable to what Erlang has, was a huge benefit. Other tools like Play, Spark also made choosing Haskell an unpractical decision for me. Besides, after a couple years of excursion into pure FP-only approach to development, I've understood to myself that OOP is not in any way in opposition to FP, but can be a rather welcome addition. Especially when you work with big code bases and you plan to maintain them for many years to come. And that is an area where Scala really shines.

openasocket 10y ago

Is this a "true" Scala? As in, if I write a Scala program that only uses the scala stdlib, will it run on both the JVM and Scala native with no modifications to the source? Or, is it more like "a Scala" in the same way you would say "a Lisp"? I think a lot of the design decisions for Scala were made so that Scala would work on the JVM and easily inter-op with Java. It might make more sense to modify the language slightly to better suit the native environment. I'm seeing some hints to that on the page with the "@struct" and "@extern" decorators.

brianwawok 10y ago
Clearly they added a bunch of new stuff that the JVM can't understand. So it is either "Scala like LISP" or It is a superset of the Scala language. Meaning all existing stuff will work with it, but if you use new secret keywords it will work "better". Which seems not quite ideal, because that means most Scala libraries will not be "tuned", and you will need all new libraries.. just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Worried the Scala ecosystem is turning into a nightmare ;)
- openasocket 10y ago
  It's not necessarily a bad thing: you can think about the various Scala implementations as dialects in a language family, like Pascal in the old days. It may be difficult to share code between these dialects, but it allows people to write code for a wide variety of environments using the same syntax and nearly-identical semantics.
- 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-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.

partycoder 10y ago

In a way, simple Scala code resembles Swift, as commented by this person: https://leverich.github.io/swiftislikescala/ https://leverich.github.io/swiftislikescala/ Now the type system of course is entirely different.

kbenson 10y ago
val label = "The width is " val width = 94 val widthLabel = label + width I really wish more languages would distinguish concatenation from addition, especially when they do type coercion. There's a very specific reason Perl opted for '.' to concatenate strings instead of +, which is that it disambiguates the following: val first = "2" val second = 3 val together1 = first + second val together2 = second + first Not to mention, addition is commutative and concatenation is not (1+2 == 2+1, but "one" + "two" != "two" + "one") Hopefully Scala at least has some very well defined and easy rules for exactly how string concatenation works, but I think it's an uphill battle to argue that '+' is a good concatenation operator.
- coldtea 10y ago
  Maybe, but in 20 years of programming (and 10+ of them with dynamic languages) I don't think I have had that issue more than 2-3 times. (1) Passing an int/string when a function expects the other type? Yes, I had that happen lots. (2) Concatenating a string and a (coerced) int? It's either a much narrower subproblem of (1), or exactly what I wanted to happen in the first place (e.g. print "Your score is: " + n + " points".
  - kbenson 10y ago
    I've dealt with it lots. While concatenating variable and string literals like your example is very rarely ambiguous, but what can be is using + to operating on two variables whose input has been returned from elsewhere. Does that function that gets the user supplied value for height automatically convert to a numerical type, or is it a string? What about the function that gets the user supplied value for width? Is it stored in a back-end format that strictly types those fields to ensure that if the data is set from some less frequently used method it has the same type (e.g. are you storing as JSON, and can this JSON be created from multiple code paths?) Given a simple statement like "foo = bar + baz", why should there be ambiguity when there doesn't need to be? The glib answer to the problem is to tell people to use better variable names, or document their functions better, or any number of suggestions that put the onus on the programmer, when this is a very simple to solve problem. Don't overload operators in the core language for conceptually different actions. We don't "add" strings, we concatenate them. Add is at best, shorthand for "add to end of" which means to append. Coercion can be a useful tool, except for when it creates confusion. There are well known and tested ways to combat this confusion, so I'm not sure why we haven't adopted them widely where coercion is in use. P.S. It's not just addition. Testing for equality is another common case where coercion can cause problems. The answer to that is equally as simple, use a different operator (such as "eq" and "ne" for string equality in Perl). Numeric equality is not the same as string equality (10.0 is equivalent to 10, but "foo." is not equivalent to "foo"), and making the programmer think (not not!) about what will happen when using an overloaded equality operator on two variables just shifts a small amount of up-front cost when learning the language (we have different operators for string concatenation and equivalence testing, learn them) to a cost imposed every time the programmer has to use those operators.

smegel 10y ago

What about GC?

BenoitP 10y ago
True. I wonder if the "Extern objects" section mentioned malloc for a reason.
densh 10y ago
In a first release we're going to use Boehm GC. That's just a stepping stone, not a long-term strategy. Stay tuned for news on this front.

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

abc_lisper 10y ago
> Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes Woah!
- jjuel 10y ago
  Clearly people either love or hate Go. There is a lot of hate I've seen on HN. I personally love it, but who am I to say what is a good language and what isn't.
  - ihsw 10y ago
    Clearly people have opinions that range across a wide spectrum on any subject. To say interest in is divided into either hate or love is disingenuous.
  - placeybordeaux 10y ago
    Honestly I'd expect to see the most Go hate on a thread about scala. The design principals of both languages are completely at ends with each other.
- 10y ago

gnufied 10y ago

So, is this "released" yet? There are no downloadable installers or even instructions to compile.

Scarbutt 10y ago
Looks like its based on dotty so Java 8 is a requirement.
- densh 10y ago
  It's currently based on Scala 2.11 with 2.12 and Dotty support coming in the future.
joostdevries 10y ago
It is not released. But you can publish it locally. Compiling the demo-native subproject seems to work. When I try to run it I get a LinkingError though.
- densh 10y ago
  Demo reproduction guide to be published in next few days.
densh 10y ago
No, it's not released yet, just publicly announced. Developer preview is planned to be released in the future. Stay tuned for further updates.

ihsw 10y ago

Such blatant ignorance, cognitive dissonance, and chauvinism is astounding. I have worked with tools like you and I hope I never do again, your attitude is toxic and I doubt your professional capability.

dsabanin 10y ago
He attacked a language, an abstract concept, you've attacked a living person. You're a bit of a tool yourself, I might say.
- ihsw 10y ago
  I don't care what he attacks, he's talking out of his ass and he's not shy about it.
dang 10y ago
Personal attacks are not allowed on HN. We ban accounts that do this, so please don't do it again. Instead, please (re-)read the site guidelines and make sure your posts are civil and substantive. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html We detached this subthread from https://news.ycombinator.com/item?id=11678838 https://news.ycombinator.com/item?id=11678838 and marked it off-topic.

cbeustwatch 10y ago

Hello Cedric Beust, you really need to stay off Scala threads. When are you going to delete your hacker news account just like your reddit account. Do it for the sake of your own reputation. https://www.reddit.com/r/scala/comments/454ahd/recent_dottyscala_fud/ https://www.reddit.com/r/scala/comments/454ahd/recent_dottys...

dang 10y ago
You can't attack someone like this on HN no matter how bad their contribution to programming language discussion on the internet. If you think you see abuse here, do please let us know at hn@ycombinator.com. We promise to look into it. But single-purpose accounts, let alone ones targeting individuals, aren't allowed here, so we've banned this one. We detached this comment from https://news.ycombinator.com/item?id=11681233 https://news.ycombinator.com/item?id=11681233 and marked it off-topic.

CheKhovHemingw8 10y ago

Another thread covers in hands-on way Getting Started: https://news.ycombinator.com/item?id=11699897 https://news.ycombinator.com/item?id=11699897