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

31–40 of 265 posts

Re: Scala Native

#31

Post by coldtea »

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…

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

Re: Scala Native

#32

Post by edko »

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…

You can also use: s"The width is $width"

Re: Scala Native

#34

Post by hibikir »

the_af wrote: post #22
dsabanin wrote: post #16

Earlier quoted context omitted.

That is a very narrow view of Scala. It's a great and powerful language.

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…

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.

Re: Scala Native

#35

Post by codecamper »

densh wrote: post #4

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

What are your mobile plans? :) I realize this is probably a ways off, but I've dreamed of being able to write core logic in a language like Scala & then using that code from ios & android.

Will scala native generate some c-linkable files?

Re: Scala Native

#36

Post by joostdevries »

the_af wrote: post #22
dsabanin wrote: post #16

Earlier quoted context omitted.

That is a very narrow view of Scala. It's a great and powerful language.

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 having to follow the JVM choice.

Re: Scala Native

#37

Post by airless_bar »

brianwawok wrote: post #18
openasocket wrote: post #13

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

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…

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

Re: Scala Native

#38

Post by pacala »

densh wrote: post #4

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

Fantastic work!

* Any plans to strengthen the Scala core lib so one doesn't have to reach out to JVM for mundane tasks like I/O or threading?

* Is there a simple way to use raw C / C++ libraries from Scala native?

* Is there a http://search.maven.org/ equivalent?

Re: Scala Native

#39

Post by dtech »

densh wrote: post #4

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

Heya, your project looks interesting I must say. I was curious, is this mainly a 1-man gig or do you have support from the existing community (e.g. Odersky).

I heard some rumors that someone (you) was doing it as a graduation thesis under Odersky, is that true or complete bollocks?

Re: Scala Native

#40

Post by edem »

brianwawok wrote: post #18
openasocket wrote: post #13

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

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…

The language is already a nightmare compared to a nearly syntaxless lisp so I'm not surprised that the ecosystem follows suit.
Post reply on HN