Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Native

github.com

Post reply on HN
Print view View original

41–50 of 265 posts

Re: Scala Native

#41

Post by sjrd »

shrugger wrote: post #26
densh wrote: post #4

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

Is this actually affiliated with the facility that is behind Scala for JVM? I saw the banner of the university on the Scala Native site, is that for real? I have been so extraordinarily impressed with Scala, and with the contributions its made in the PLT field, I'm very excited for Scala Native to start picking up steam. Can we expect the same level of excellence from Scala Native as we've received from Scala for JVM…

Yes. Scala Native is developed at EPFL for real.

Re: Scala Native

#42

Post by airless_bar »

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

Re: Scala Native

#43

Post by airless_bar »

duaneb wrote: post #14
spriggan3 wrote: post #3

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

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.

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.

Re: Scala Native

#44

Post by int_19h »

kbenson wrote: post #28
badminton1 wrote: post #17

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

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 t…

'+' works great as a concatenation operator, so long as you don't ever try to implicitly convert the values. Case in point - Python:

  >>> 1+2
  3
  >>> "1"+"2"
  '12'
  >>> "1"+2
  Traceback (most recent call last):
    File "", line 1, in 
  TypeError: Can't convert 'int' object to str implicitly

Re: Scala Native

#45

Post by dtech »

densh wrote: post #4

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

Do you see any possibilities to undo/mitigate JVM-specific design decision which handicap the language? For example could you not erase generics or would that cause too much problems incompatibilities?

Re: Scala Native

#46

Post by joostdevries »

joostdevries wrote: post #36
the_af wrote: post #22

Earlier quoted context omitted.

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 bet…

I remember Martin Odersky explaining how the Scala compiler has to do a lot of work to compile FP code to a JVM that is mostly geared for the Java language only. Because of that the compiler is well positioned to compile to other targets as well. Like Javascript or LLVM. Are you talking about compromises in the language or the standard library? In the language itself I can only think of type erasure for generics havi…

Snif. sbt demoNative/compile seems to work. But sbt demoNative/run produces a scala.scalanative.linker.LinkingError Unresolved dependencies: `#scala.Serializable`

Re: Scala Native

#47

Post by the_af »

dsabanin wrote: post #27
the_af wrote: post #23

Earlier quoted context omitted.

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

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.

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!

Re: Scala Native

#49

Post by abc_lisper »

airless_bar wrote: post #42

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…

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

Woah!

Re: Scala Native

#50

Post by lauriswtf »

airless_bar wrote: post #42

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…

A small side note: Scala has several great features, but "low development overhead" just isn't one of them. Also why so harsh on Go?
Post reply on HN