Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Native v0.1

scala-lang.org

Post reply on HN
Print view View original

101–110 of 254 posts

Re: Scala Native v0.1

#101

Post by acjohnson55 »

the_duke wrote: post #89
dillonb wrote: post #33

Earlier quoted context omitted.

Well, this is just targeting a different VM, LLVM instead of the JVM. You get easy interop with all LLVM languages with this, including C.

You should really check your facts before posting a statement like this. While the VM in LLVM historically was short for Virtual Machine, it really has nothing to do with that. It's a compiler backend used by Clang (C++ compiler) and Rust.

My understanding is that IR is designed as though there were a VM to run it, but in practice, IR is immediately used to generate code for a target architecture.

Re: Scala Native v0.1

#102

Post by acjohnson55 »

the_duke wrote: post #89
dillonb wrote: post #33

Earlier quoted context omitted.

Well, this is just targeting a different VM, LLVM instead of the JVM. You get easy interop with all LLVM languages with this, including C.

You should really check your facts before posting a statement like this. While the VM in LLVM historically was short for Virtual Machine, it really has nothing to do with that. It's a compiler backend used by Clang (C++ compiler) and Rust.

My understanding is that IR is designed as though there were a VM to run it, but in practice, IR is immediately used to generate code for a target architecture.

Re: Scala Native v0.1

#103

Post by sjrd »

danaliv wrote: post #91
sjrd wrote: post #80

Earlier quoted context omitted.

Actually, there are people using Scala.js to run Scala on AWS lambda, precisely for that reason. * https://github.com/tptodorov/aws-lambda-scalajs * http://underscore.io/blog/posts/2016/03/21/serverless-scale-...

Sure, but it'd be nice not to have everything in the known universe depend on JavaScript.

Absolutely! I'm just pointing out that this need is so strong that people have reached for the slow throughput of Scala.js just to get its fast startup time. If we can have both, that's even better!

Re: Scala Native v0.1

#104

Post by sjrd »

tejasmanohar wrote: post #99

Does this mean the future of Scala is off the JVM? I ask because the post calls the JVM impl. a "reference implementation".

IMO the future of the JVM is highly multi-platform: JVM, native and JS.

Re: Scala Native v0.1

#105

Post by acjohnson55 »

Negative1 wrote: post #30

Important bit: "The project has reached a point of feature completeness in terms of the coverage of the Scala language. We support the whole language including the more advanced features such as method dispatch via structural types and even macros." It must be frustrating to work on a project like this, see areas where the language can be improved, but only be able to do the work to make it purely compatible. Hopeful…

Or inspiring! I guess it depends on your outlook.

Re: Scala Native v0.1

#106

Post by zepolen »

danaliv wrote: post #91
sjrd wrote: post #80

Earlier quoted context omitted.

Actually, there are people using Scala.js to run Scala on AWS lambda, precisely for that reason. * https://github.com/tptodorov/aws-lambda-scalajs * http://underscore.io/blog/posts/2016/03/21/serverless-scale-...

Sure, but it'd be nice not to have everything in the known universe depend on JavaScript.

I disagree. Having a common language in many places has led to huge improvements over the board in the JS ecosystem, it's become the "C" of the modern era, and you can build a lot of stuff on the foundations that others have laid.

I still hate JS though.

Re: Scala Native v0.1

#108

Post by emodendroket »

tejasmanohar wrote: post #99

Does this mean the future of Scala is off the JVM? I ask because the post calls the JVM impl. a "reference implementation".

Does that not mean that it's the canonical one which other implementations should be measured against? That would seem to imply just the opposite.

Re: Scala Native v0.1

#109

Post by dbaupp »

acjohnson55 wrote: post #101
the_duke wrote: post #89

Earlier quoted context omitted.

You should really check your facts before posting a statement like this. While the VM in LLVM historically was short for Virtual Machine, it really has nothing to do with that. It's a compiler backend used by Clang (C++ compiler) and Rust.

My understanding is that IR is designed as though there were a VM to run it, but in practice, IR is immediately used to generate code for a target architecture.

That might have been true originally, but I don't think anyone uses LLVM like a JVM/CLR-esque VM any more. As the parent states, the original Low-Level Virtual Machine initialism was even retracted, meaning the project's name is just the "arbitrary" sequence of letters LLVM, with no particular meaning assigned to them.

Re: Scala Native v0.1

#110

Post by algesten »

wtetzner wrote: post #72
algesten wrote: post #63

Earlier quoted context omitted.

> the cold startup time of the JVM itself (which is not relevant on a server in comparison to desktop Java apps). I disagree somewhat with this. We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling. For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, th…

> For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, than try to construct reconnect logic. This sounds like a very Erlang-ish way to handle the problem. Another advantage is that if the server/process is in some weird state that's causing problems, killing and restarting it lets you clear out the broken state, and get back into the state that…

Yes. We're almost now risking it going the other way, that some bad programming goes unchecked for a long time, because overall, the process sort of does what it should. Even if it restarts like 10 times a day.
Post reply on HN