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

181–190 of 265 posts

Re: Scala Native

#181

Post by stuhood »

pfarnsworth wrote: post #30
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've heard a lot of the early adopters of Scala are moving away, including LinkedIn, Twitter, etc.

Twitter is not moving away from Scala. Scala continues to grow at a faster rate internally then any other language, and is ~50% of Twitter's backend codebase.

Re: Scala Native

#182

Post by avita1 »

airless_bar wrote: post #51
pfarnsworth wrote: post #30

Earlier quoted context omitted.

I've heard a lot of the early adopters of Scala are moving away, including LinkedIn, Twitter, etc.

No, not really. Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed. Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate…

I like Scala, and this is purely anecdotal: but with Java 8 becoming pervasive and large companies adopting Scala style guides that recommend most of the advanced features away [1], Scala becomes a less compelling choice.

Sure, companies aren't dropping existing code in Scala, but I would be surprised if large organization were to push for new code to be written in Scala instead of Java 8.

Edit: link

[1] https://github.com/twitter/scala_school

Re: Scala Native

#183

Post by sjrd »

airless_bar wrote: post #136
densh wrote: post #131

Earlier quoted context omitted.

The goal is to be as "true" as possible by default with extra flags to trade some exact semantic aspects for performance. E.g. overflow semantics, bounds checks, null safety etc. Apart from the base language we'll also introduce some language/library extensions to make lower-level programming that is going to be limited Scala Native "dialect" of Scala. E.g. pointers, structs, stack allocation, extern objects etc.

Is there a difference between @extern and @native? I could have imagined that it would have been more compatible if Scala-JVM and Scala-Native used the same annotations (using JNI behind the scenes on the JVM).

I would explain the difference as: @native says please implement this Scala method of this Scala class in C, respecting all the JVM calling conventions and memory model. @extern says call this C function that never knew about Scala or the JVM, respecting all the C calling conventions and memory model.

Re: Scala Native

#184

Post by sjrd »

incepted wrote: post #102
patrickmclaren wrote: post #97

Earlier quoted context omitted.

Will Lightbend be supporting this project in any way? The reason I ask is that I see on GitHub that you are the only contributor so far. This project is quite a large commitment for a single person, I'm hesitant to play around with Scala Native without knowing more about future plans for support, milestones, etc. Having said that, this project looks awesome. Nice work so far!

Agreed. I see the statement "It's being developed at EPFL by one engineer" as a very high risk that once this student graduates or moves on to a different university, the project will be abandoned and die.

It's worth noting that Scala.js started this way, and is now mature and used by thousands of developers. I foresee a similar path for Scala Native.

Re: Scala Native

#185

Post by dang »

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…

Please don't start programming language flamewars on HN ("Go is utter shit", etc.) Those are all the same, and we're hoping for thoughtful discussion.

We detached this subthread from https://news.ycombinator.com/item?id=11678317 and marked it off-topic.

Re: Scala Native

#186

Post by dang »

ihsw wrote: post #72

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.

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/newswelcome.html

We detached this subthread from https://news.ycombinator.com/item?id=11678838 and marked it off-topic.

Re: Scala Native

#187

Post by zem »

runT1ME wrote: post #174
saosebastiao wrote: post #82

Earlier quoted context omitted.

> It's pretty well known that Scala was heavily influenced by Haskell. Except that Martin Odersky himself has explicitly said that the primary influences were SML/OCaml and Java. > In particular, do notation (for comprehensions), I'll give you that one > pattern matching Which pre-date Haskell by nearly 2 decades in ML > lots of standard lib classes (ex Maybe (Option)), Also pre-date Haskell by nearly 2 decades, in a…

Given the fact that OCaml seems to be adding type class support and has support for monadic comprehension (do/for), it seems like these ideas are getting adopted in multiple places. As a Scalaz committer and as a developer working at one of the largest scala shops (that makes heavy use of Scalaz), we don't try to write Haskell on the JVM. We do try to write pure, functional code as much as we can, and so what we end…

reference for ocaml adding type class support?

Re: Scala Native

#188

Post by kangar00 »

patrickmclaren wrote: post #97
sjrd wrote: post #41

Earlier quoted context omitted.

Yes. Scala Native is developed at EPFL for real.

Will Lightbend be supporting this project in any way? The reason I ask is that I see on GitHub that you are the only contributor so far. This project is quite a large commitment for a single person, I'm hesitant to play around with Scala Native without knowing more about future plans for support, milestones, etc. Having said that, this project looks awesome. Nice work so far!

There have been so many successful projects started by one person. Shooting it down before seeing what will be done is a bad idea.

I'm interested in it breaking away from the JVM to become more performant, since that has been one of my concerns about Scala; there is a lot of good about JVM-based languages, but when in the ring with other languages like Go, you need to be quick to win.

I hope that others join him, but there's no reason to believe he can't do it if he sets his mind to it.

Re: Scala Native

#189

Post by acjohnson55 »

airless_bar wrote: post #114
nothrabannosir wrote: post #110

Earlier quoted context omitted.

Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference? If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect? Or am I looking at this…

Scala macros are compile-time. The Scala reflection library (that works at runtime) share most API with macros. Macros should always work, reflection is harder as some information needs to be retained at runtime (either via Java reflection or additional data – which can both be problematic in Scala.js).

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.

Re: Scala Native

#190

Post by acjohnson55 »

edem wrote: post #40
brianwawok wrote: post #18

Earlier quoted context omitted.

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.

It's funny to me to see "syntaxless" used as a good thing :)

For me, syntax--good syntax, anyway--makes code far more readable.

Post reply on HN