Hacker News Reader

Comment by cwyers | Hacker News Reader

It seems to me like Scala's biggest benefit and biggest downside are two sides of the same coin: easy interop with the JVM and Java code. Scala Native just seems like you're paying all the price of that for none of the benefit.

View on HN

I think the Scala community's aims have been higher than what you've suggested for a while. For example, from what I've seen, Scala.js has been wildly successful, yet according to you it should never have existed.

Scala.js lets you run Scala code on javascript-based VM's and provides full integration with the underlying platform and libraries. Scala native looks to be another attempt to expand Scala's reach into new platforms beyond the JVM.

Define "wildly successful"... I can't name a single company or project that uses Scala.js.

There is a small list under "Built with Scala.js" here: https://www.scala-js.org/community/. And that's only for the public facing apps of companies who have explicitly sent a PR to the website to add themselves to the list. Other companies use Scala.js for internal tools.

that's hardly 'wildly successful'

Don't crap in Sid's Cheerios. For a project mostly made by one dude, Scala.js is amazing.

It's hardly "one dude", though. Don't give me too much credit. There were two others (@gzm0 and @nicolasstucki) who helped a lot on the core. But even more than that, the reason it's so popular and adopted is mostly due to the amazing community who wrote great, relevant libraries, and communicated to the world.

It's at least a dozen people who should be credited, even if I'm currently the only one paid for this work.

Perhaps it could mean successful in wilderness not in typical companies etc.

Even if you're not using Java code, it's still the best language going IMO.

What are the alternatives? I couldn't live without HKT these days (once you're used to thinking in them it's painful to work without them), which rules out most languages even in the ML space, and Scala has better IDE support than anything that's left (indeed an excellent tool ecosystem in general in terms of e.g. profilers, instrumentation) except possibly Ceylon (which doesn't have anything like the library/developer ecosystem of Scala). Even assuming Ocaml lands their modular implicits functionality doesn't change this as far as I can see.

Haskell is an option, but eager evaluation makes reasoning about performance much easier. (And I do think there are legitimate use cases for traditional OO inheritance, though this is debatable). If and when Idris reaches a similar level of library/tool support to Scala then it might become a better alternative to Scala Native, but not that many people are willing to use Idris in production yet.

PureScript may soon be a serious contender in the HKT language category. It is more or less a strict Haskell for JavaScript runtimes with some new type system features like row types and more fine-grained control over I/O (see http://www.purescript.org/learn/eff/ and https://github.com/purescript/purescript/wiki/Differences-fr...). It has an experimental native (via C++11) backend.

I started working for a company that does a lot of Scala a few months ago. It's my first real exposure to it.

To me, Scala's biggest benefits are just the language itself. So many little things that I couldn't do in Java, I can do with little effort in Scala. I can write imperative code if I really want, but I have all the benefits of functional programming available too.

Java/JWM interop was a good starting point to make corporate adoption easier and Scala was/is pretty successful with that strategy. However, in my opinion, Scala developers are not necessarily interested in Java and see it more as the necessary evil.

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.

LLVM IR apparently is not restricted to C/C++/Objc/Swift etc, it is a generally purposed IR; and LLVM itself is an infrastructure that contains many facilities to deal with compilation backends (mostly, analyses and transformations).

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.

LLVM is not a VM in the same sense as the JVM is.

Yup.

Easy interop with C++ or Rust? I'll believe it when I see it.

It looks like it can!

http://www.scala-native.org/en/latest/user/interop.html

>Scala Native provides an interop layer that makes it easy to interact with foreign native code. This includes C and other languages that can expose APIs via C ABI (e.g. C++, D, Rust etc.)

From that page, it looks like Scala-C interop is decent, but that's a far cry from C++/Rust interop. For C++ at least, you more or less need to write a pure-C wrapper API to call from Scala, since it doesn't handle C++ types.

Interesting, I guess I understood that wrong. Looks like no "easy" interop, but it's there if you really need it and don't mind the extra work.

I've been playing with this and trying to convert a ~20 line helper script that I use at work (and would really like to benefit from no JVM warmup time), and I've already run into missing core library functions like parallel collections and regexes.

This thing will be really great when it's ready, but it's not even close yet.

You would need the same for Rust as well.

Rust's FFI is the same as C.

I'm not sure what exactly you mean by that, but what I was trying to say is that you can't expose Rust directly, you need to expose a C ABI. Which is totally doable, but is not just "drop in Rust code and it works."

> languages that can expose APIs via C ABI

That's what I thought.. another C-based FFI. Better than nothing, I suppose.

Nim has pretty decent interop with C++. In general, though, you are right that C is much much easier to interop with

The biggest benefit should be a powerful and expressive language, the biggest downside would be incompatibility with lots of existing (java-oriented) Scala code.

Reply on news.ycombinator.com