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

211–220 of 265 posts

Re: Scala Native

#211

Post by rrdharan »

airless_bar wrote: post #143
pfarnsworth wrote: post #129

Earlier quoted context omitted.

By definition those are minor releases.

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.

Note that the use of major.minor.revision actually predates the formal SemVer specification by something like 20 years.

That doesn't mean you're wrong; but it does explain the confusion. I'm a fan of Scala but I'll admit I was confused by this as well when getting started with it since I've been trained to see everything after the first decimal as "minor".

Re: Scala Native

#212

Post by Negative1 »

densh wrote: post #142
Negative1 wrote: post #11

Earlier quoted context omitted.

This is exciting but I've been burned in the past. Your commit graph seems to show you're serious so I hope you stick with it. Will probably have more questions after I browse through the code but some basics: Q: How much of the collections library is covered with full support? Partial support? NYI w/ ETA? Q: Cross-platform support? If I wanted to run this on iOS and Android today, what do I have to do? What about on…

> Q: How much of the collections library is covered with full support? Partial support? NYI w/ ETA? Non-parallel collections should work in first developer preview (to be announced.) Parallel collections may took a few release to get working. > Q: Cross-platform support? If I wanted to run this on iOS and Android today, what do I have to do? What about on Windows or OSX? If you can compile and run C code with Clang o…

Ah, so since Scala Native is not built on the JVM you can't just take a pre-existing Java library and make it interop. You need it to be real Scala. The only options then are to use a convertor or manually port the library from Java to Scala?

Re: Scala Native

#213

Post by grogs »

bad_user wrote: post #145
Negative1 wrote: post #126

Earlier quoted context omitted.

Play uses it specifically for in it’s JSON module; you can define readers and writers that allow you to parse the structure of a JSON object. To avoid having to be very explicit, you can define a case class that directly mirrors the structure of that object. e.g. given some case class that looks like this: case class SomeObj(someInt: Int) you could do: val theObj = SomeObj((json \ “someInt”).as[Int]) or implicit val…

The tricks that Play JSON does don't need runtime reflection. Macros don't use runtime capabilities at all and all macros work in Scala.js. I'm actually surprised by claims of Play JSON needing the runtime reflection of "scala.reflect". No, Play JSON doesn't work because it wraps Jackson, a Java library.

Your correct that it probably doesn't use scala.reflect, but it still uses reflection.

Jackson works using reflection. Play JSON therefore at least depends on reflection transatively.

Re: Scala Native

#214

Post by grogs »

paulddraper wrote: post #196
acjohnson55 wrote: post #189

Earlier quoted context omitted.

And as the original author of Scala.js pointed out in a Scala Days talk today, unrestricted reflection means that it's impossible to do dead code elimination, which is a non-starter for real-world use.

Well, Proguard does whole program optimization. You have to specify the symbols to preserve explicitly.

I believe that works against jvm bytecode, which you don't get for scalajs. Instead the compiler has a JS specific intermediate representation which the optimizations occur on.

Re: Scala Native

#215

Post by grogs »

brianwawok wrote: post #103
Negative1 wrote: post #89

Earlier quoted context omitted.

You're talking about Play Framework, I assume. They did some fancy work with Macros (i.e. Scala Reflection) which causes a lot of headaches for Scala.js. The reality is most of the reflection it does is nice but not necessary and I really wish they offered a "switch" to turn it off.

Ya play is where I started, then I moved my app into Scala.JS land. Had some cool parts to it, but not sure I was sold on the overall experience. I hate JS so bad and want to avoid it, but I kind of felt like I was mostly trading evils. Maybe if I worked at it enough it would finally get better? Not sure

When did you try it out? What didn't you like?

I ported a site written in vanilla Javascript. I decided to faithfully port it without any changes before introducing scala specific libraries. That was pretty painful. A bunch of manual casting for UndefOr and js.Function.

Since then I've started using some of the scalajs libraries/frameworks straight away on projects. It has been a much more pleasant experience!

Re: Scala Native

#216

Post by grogs »

Negative1 wrote: post #212
densh wrote: post #142

Earlier quoted context omitted.

> Q: How much of the collections library is covered with full support? Partial support? NYI w/ ETA? Non-parallel collections should work in first developer preview (to be announced.) Parallel collections may took a few release to get working. > Q: Cross-platform support? If I wanted to run this on iOS and Android today, what do I have to do? What about on Windows or OSX? If you can compile and run C code with Clang o…

Ah, so since Scala Native is not built on the JVM you can't just take a pre-existing Java library and make it interop. You need it to be real Scala. The only options then are to use a convertor or manually port the library from Java to Scala?

Yep, or drop the dependency. E.g. For joda specifically, you should probably move to Java 8 date API, which is more likely to be ported.

Bare in mind that scalajs has the same issue and a lot of work has already been done!

Re: Scala Native

#217

Post by hukola »

pjmlp wrote: post #204
cle wrote: post #203

Earlier quoted context omitted.

Maybe. Syntax imposes structural rules on your code. If your domain doesn't fit the syntax, then you'll end up with far _less_ readable code. The draw towards "syntaxless" lisp-y languages is that you can build the syntax to fit your domain, rather than vice versa. The result is a DSL that naturally models the domain, rather than an unintuitive mess of data transformations to force your domain model to fit the struct…

This thing that each Lisp developer writes its own DSL library is one of the reasons why the enterprise isn't so found of Lisp. It is always a steep curve to dive into other developers code.

Wouldn't LISP become more popular if students started with LISP at school/university rather than C/C++, Java or Python? How can a young developer compare or choose if he/she had never been exposed to LISP?

Re: Scala Native

#218

Post by estefan »

dsabanin wrote: post #2

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.

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

Re: Scala Native

#219

Post by pjmlp »

edko wrote: post #210
pjmlp wrote: post #208

Earlier quoted context omitted.

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.

The other two are important too: the JVM lets you leverage lots of existing libraries. The browser lets you reach more users.

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.

Re: Scala Native

#220

Post by skoczymroczny »

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…

D uses + for addition and ~ for concatenation
Post reply on HN