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

151–160 of 265 posts

Re: Scala Native

#151

Post by airless_bar »

PeCaN wrote: post #127
lauriswtf wrote: post #50

Earlier quoted context omitted.

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?

Regarding Go... perhaps the parent was harsh, but not wrong per se . I think a strong argument can be made for Go being a very poorly designed language with an excellent community. Scala certainly doesn't have high development overhead either. Build system more or less just works, plenty of libraries, minimal ceremony to do much. Don't get me wrong, I kinda hate Scala¹, but compared to _many_ languages it does have l…

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, but think OCaml is a poor ML. That's why I love Scala. It's extremely consistent, and design decisions are very considerate.

It's an amazing language and I can express my intentions much better than in OCaml (no typeclasses, no higher-kinded types, etc.).

Re: Scala Native

#152

Post by hugofirth »

dtech wrote: post #45
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?

In point of fact, I think its not so much a handicap: http://stackoverflow.com/questions/20918650/what-are-the-ben...

Re: Scala Native

#153

Post by densh »

abc_lisper wrote: post #7

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?

1. Yes, base language is the same.

2. It's mostly the question of what language you're most comfortable with. I personally love Scala sans the JVM and that's why I'm developing Scala Native.

3. Subset of java.* is going to be supported. Pure Scala code that uses that subset and other Scala libraries should just work on Scala Native.

Re: Scala Native

#154

Post by densh »

gnufied wrote: post #48

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

No, it's not released yet, just publicly announced. Developer preview is planned to be released in the future. Stay tuned for further updates.

Re: Scala Native

#155

Post by densh »

smegel wrote: post #19

What about GC?

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.

Re: Scala Native

#156

Post by airless_bar »

incepted wrote: post #106
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…

> Swift where things get added at a frightening rate. Things are always added at a frightening rate when a language is young. Happened for C#, happened for Scala, happens for all languages. Not really something to worry about.

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 way – you will have to rewrite your code with every major Swift release which we will be releasing at a rapid schedule".

It will be very hard for Swift to get rid of all the cruft they accumulate.

In Scala every major release addresses one or two pain points and migration is very smooth – no "rewrite all your stuff".

Re: Scala Native

#157

Post by densh »

Scarbutt wrote: post #58
gnufied wrote: post #48

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

Looks like its based on dotty so Java 8 is a requirement.

It's currently based on Scala 2.11 with 2.12 and Dotty support coming in the future.

Re: Scala Native

#158

Post by bad_user »

dtech wrote: post #84
whateveracct wrote: post #52

Earlier quoted context omitted.

Idiomatic Scala doesn't care at all about erased generics. With implicits and macros and libraries built upon them like shapeless, you can do everything you'd want to do with reified generics and more and it'll be done and statically checked at compile time instead of dynamically at run time.

I know there are ways like typetags to work around it, but on the JVM this is never going to run without extra work: def erased[T](xs: List[T]) : String = { xs match { case ns : List[Int] =>"Natural numbers" case fs : List[Double] => "Floating point numbers" case _ : List[T] => "Something else" } } System.out.println(erased(List(1,2,3))) System.out.println(erased(List(1.0,2.0,3.0))) Which is purely because of a JVM r…

The part that you're missing is that code like this in Scala is totally unnecessary and it never happens:

    case ns : List[Int] =>
Worst case scenario, you can always do the following and it would be more idiomatic, no type erasure standing in the way:

    val listInt = listAny.collect { case x:Int => x }
    val listDouble = listAny.collect { case x:Double => x }
But even that is totally unnecessary. You know why? Because your function does not make sense. What could you possibly do with a function that takes a List[T] and returns a String?

The only way this would make sense would be if you are talking about a List[Any] deserialized from somewhere (like some shitty JSON library). But then in Scala we don't really work with Any, that should never happen and if you see libraries that use Any in their API, drop them like they are hot ;-)

> Which is purely because of a JVM runtime limitation

No it's not. Talk to compiler authors. This is actually a freedom, because by introducing reified generics in the runtime, then language designers either have to deal with inefficiencies due to boxing because of extra conversions, or to limit their type system, so for example you can say goodbye to higher-kinded types. A runtime that has reified generics is not a multi-language runtime. In fact many languages are doing type erasure. Haskell is doing type erasure. And why shouldn't it, I mean, type casting and isInstanceOf checks make no sense in Haskell.

Re: Scala Native

#159

Post by densh »

joostdevries wrote: post #85
gnufied wrote: post #48

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

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.

Demo reproduction guide to be published in next few days.

Re: Scala Native

#160

Post by densh »

airless_bar wrote: post #140
densh wrote: post #132

Earlier quoted context omitted.

> How's the managed runtime implemented (GC, memory model, etc.)? 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. > How did you get rid of JVM and JRE class library dependencies of Scala? We're reimplementing / porting from Apache Harmony all the things we need. > What's the debugging story? We're going to integrate with lldb.…

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

We're are going to have an official guide on licensing in next few days.
Post reply on HN