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

231–240 of 265 posts

Re: Scala Native

#231

Post by FraaJad »

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

auto greeting = "Hello" ~ " World!";

immutable x = 9 + 99;

auto:immutable::var:val

Re: Scala Native

#232

Post by geodel »

lmm wrote: post #227
placeybordeaux wrote: post #69

Earlier quoted context omitted.

>Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes. Making blanket statements like that without any substantiation makes me want to just write off everything else you have said.

To my mind writing off Go is table stakes for having an interesting discussion about modern programming language choice - anyone who takes Go seriously is coming from a position so different from mine that it would take many pages (all of which would be rehashing of old discussions) to bridge the gap, and I honestly can't be bothered. While I would try not to be so rude about it, I think GP is right to dismiss the la…

I agree with you that they are just 2 very different language in philosophy and usage. To my mind Go is about boring technology used to make interesting and very popular products while Scala is about exploring cutting edge in PL theory.

One can see most work on Scala in git commits is done either by few people at a research institute(EPFL) or at a consulting company(lightbend) whereas Go has quite varied committer profiles and there are far more committers.

Re: Scala Native

#233

Post by lmm »

geodel wrote: post #232
lmm wrote: post #227

Earlier quoted context omitted.

To my mind writing off Go is table stakes for having an interesting discussion about modern programming language choice - anyone who takes Go seriously is coming from a position so different from mine that it would take many pages (all of which would be rehashing of old discussions) to bridge the gap, and I honestly can't be bothered. While I would try not to be so rude about it, I think GP is right to dismiss the la…

I agree with you that they are just 2 very different language in philosophy and usage. To my mind Go is about boring technology used to make interesting and very popular products while Scala is about exploring cutting edge in PL theory. One can see most work on Scala in git commits is done either by few people at a research institute(EPFL) or at a consulting company(lightbend) whereas Go has quite varied committer pr…

> To my mind Go is about boring technology used to make interesting and very popular products while Scala is about exploring cutting edge in PL theory.

I would strongly disagree with the implication that Scala isn't used to make interesting or popular products (e.g. Spark or twitter), or indeed that it's "exploring" anything "cutting-edge"; it is very much a production-quality language (backed by theory sure, but theory that's been established for decades now), and I don't see that it contains anything more novel or experimental than e.g. Go's concurrency model. It's a decent platform for doing research in, but that's mostly just a question of being a good language.

> One can see most work on Scala in git commits is done either by few people at a research institute(EPFL) or at a consulting company(lightbend) whereas Go has quite varied committer profiles and there are far more committers.

We're talking about a factor of 2-3 in number of committers, not that I have any idea what that number is supposed to tell anyone. Certainly Scala has substantial industrial support and a wide base of contributors.

Re: Scala Native

#234

Post by lmm »

kangar00 wrote: post #230
patrickmclaren wrote: post #201

Earlier quoted context omitted.

Note that I am not concerned about the fact that the project was started by one person, nor am I dismissing it altogether. The author of this project is most definitely a smart and capable individual. However, at some point this project will reach a point where it requires more work than one individual can achieve, hence the question regarding official support - is there any financing, plans for new contributors, etc…

I understand your concern, but, as I said, a number of authors have not have financing, plans for new contributors, etc. in the beginning and have been successful; these are not requirement for success in the beginning. For example, here is the story of how Python got its start from Guido van Rossum (quote from 1996): "Over six years ago, in December 1989, I was looking for a "hobby" programming project that would ke…

Well, Ruby or Python would not have been suitable for many use cases in those days, and probably weren't as widely announced as scala-native is being.

Re: Scala Native

#235

Post by geodel »

lmm wrote: post #228
azinman2 wrote: post #165

Earlier quoted context omitted.

How so? You can find examples of poor engineering in any language. What's specific about go?

Go doesn't have the facilities that let you handle real-world concerns in a nice way. All the examples of bad, enterprisey Java - Spring AbstractSingletonProxyFactoryBean, XML config for everything, reflection-based JSON serialization, annotation-based transaction management, JavaSpaces - they weren't written by idiots, they were written because they were the best way to solve real business problems within the limits…

Well Java has generics since 2004 and I have seen bloated enterprisey usage and patterns increasing vastly since then. Spring has become major force after Java had generics. So your argument about generics does not sound realistic to me.

Re: Scala Native

#236

Post by lmm »

geodel wrote: post #235
lmm wrote: post #228

Earlier quoted context omitted.

Go doesn't have the facilities that let you handle real-world concerns in a nice way. All the examples of bad, enterprisey Java - Spring AbstractSingletonProxyFactoryBean, XML config for everything, reflection-based JSON serialization, annotation-based transaction management, JavaSpaces - they weren't written by idiots, they were written because they were the best way to solve real business problems within the limits…

Well Java has generics since 2004 and I have seen bloated enterprisey usage and patterns increasing vastly since then. Spring has become major force after Java had generics. So your argument about generics does not sound realistic to me.

Java's type system is limited (no higher kinds) and methods that might throw exceptions can't be handled as values in a generic way.

Re: Scala Native

#237

Post by emeryberger »

densh wrote: post #132
badlogic wrote: post #10

Earlier quoted context omitted.

How's the managed runtime implemented (GC, memory model, etc.)? How did you get rid of JVM and JRE class library dependencies of Scala? What's the debugging story? I'd be great if this kind of info found its way onto th website. Is this in any way related to vmkit? Excited about this, keep up the great work!

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

Hans Boehm's GC is actually really, really good. Before you embark on a massive engineering effort that will likely lead to little gain and a lot of pain, I would measure the overheads very carefully. I am not at all convinced precise GCs buy you that much over the Boehm GC for most apps, and they fundamentally kill interop with C code.

(I can't recall for sure but I believe I had this conversation with Martin in a taxi ride not too long ago :)

Re: Scala Native

#238

Post by kod »

pfarnsworth wrote: post #198
kod wrote: post #172

Earlier quoted context omitted.

No, you specifically said they're being deprecated because of maintainability issues inherent to scala, which is not true.

Nope. They were getting sick of having to maintain different versions of the Scala clients because of breaking changes, as per a Kafka committer.

Even if some random kafka committer that you can't source believes that, the reasoning doesn't add up:

SBT makes it fairly straightforward to cross publish for different dot releases of Scala, and libraries in the Scala ecosystem do it all the time.

Scala dot releases are far apart. It's been over 2 years since 2.11, and 2.10 released in 2012.

By contrast, the JAVA client that the Kafka project published in November is already undergoing breaking changes for the current release candidate. It's pretty clear that avoiding breaking changes is not an overriding concern for them, and even if it is, it's equally clear that Scala was not the inherent problem.

Re: Scala Native

#239

Post by dragonwriter »

bad_user wrote: post #209
dragonwriter wrote: post #164

Earlier quoted context omitted.

ISTR a significant reason it died was the .Net platform's reified generics, which made making a language with generics and a type system more expressive than the underlying platform problematic, and especially made it difficult to have something that would be fully compatible with Scala-on-the-JVM.

That's not really true. Yes there are challenges with reified generics and yes Scala's generics don't fit. However you can work around it by doing the type erasure yourself. You can always consider a List[Int] to be a List[Any] and be done with it. And yes that's going to generate inefficient code, but ClojureCLR doesn't seem to mind. No, the reason for why Scala.Net didn't happen is because nobody cared. To find pro…

If you do erasure, then you can't also have the level of platform integration Scala has on the JVM: Scala on .NET either ends up as a different-but-similar language that isn't 100% compatible with Scala-on-JVM on a language level (as well the library differences), or its a second-class citizen that doesn't integrate well with the .NET platform, in which case, why have it?

So, in a sense, no on cared -- because neither of the available options was anything anyone wanted.

Re: Scala Native

#240

Post by sievebrain »

densh wrote: post #4

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

Hi,

What is the rationale for doing this, given that the Graal / JVM guys are already developing an AOT compiler which can compile Scala to native binaries?

Is this motivated by performance? The desire to write C libraries in Scala? What?

Given the high level, dynamic nature of Scala I am skeptical LLVM+Boehm GC will result in faster code. I expect it would result in slower code.

EDIT: OK, I just saw the link to your talk below. I feel you should know a few things:

1) The Hotspot team are adding AOT compilation to the JVM. There is a talk on it here. This mostly eliminates warmup time:

https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar...

You can't eliminate warmup time entirely because profile guided on-the-fly optimisation is actually quite powerful and an AOT compiler that doesn't have profile data to work with can't generate code that's as good. But they support tiered AOT, where the AOT compiled code does basic profiling of itself, and then it can still trigger profile-guided JIT compilation if you want to.

2) Interop with native is being heavily worked on in project Panama: another JVM upgrade project. With the current prototype you can feed it arbitrary header files that are parsed with clang, and it generates Java interfacing files that are efficiently compiled (no overhead). There's a Pointer type and so on.

3) Stack allocation isn't so easy to do unless you are willing to pretty wildly violate the safety of the language. It's also been found to not help much when very adventurous JVM implementors tried it anyway (Azul), because a good generational GC makes short lived allocations so cheap. Valhalla is doing value types on the JVM but that's about more than just stack allocation.

4) You can do manual memory management on the JVM already, via the Unsafe class. I'm sure a Scala DSL would make it have a more convenient syntax.

5) Java 9 will have a static linker equivalent that generates stripped, standalone, optimised application packages that don't depend on any separate JVM. The AOT compiler will be a plugin to this static linker.

So I don't mean to discourage you if this is a fun research project, but you should be aware that the daydream is not one that the actual Java team are ignoring for mysterious reasons. They're working on it too, and are better funded and taking a more general and compatible approach. By the time you have a tool that's usefully complete it'll take years and by then there might not be much difference between the approaches.

Post reply on HN