Live data from Hacker News

Scala Native

github.com

201–210 of 265 posts

Re: Scala Native

#201

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!

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…

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.

Re: Scala Native

#203
post #40

Earlier quoted context omitted.

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.

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 structure imposed by the syntax and type constraints.

Re: Scala Native

#204
post #203

Earlier quoted context omitted.

It's funny to me to see "syntaxless" used as a good thing :) For me, syntax--good syntax, anyway--makes code far more readable.

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.

Re: Scala Native

#205

Earlier quoted context omitted.

The difference is that Scala devs didn't push for immediate adoption while they were still working things out. Apple's Swift message is more or less "Stop writing Objective-C if you can and start using Swift – oh and by the way – you will have to rewrite your code with every major Swift release which we will be releasing at a rapid schedule". It will be very hard for Swift to get rid of all the cruft they accumulate.…

> In Scala every major release addresses one or two pain points and migration is very smooth – no "rewrite all your stuff". Yes, the Java way. Take ten years to implement basic stuff. I much prefer Swift and C#'s approach to this: first major version bump, things get deprecated. Second bump, they get removed. It worked great for C#, it's going to work great for Swift, which has already seen incredible adoption on iOS…

Oh come on Cedric. You managed to troll better in the past.

As you surely know it already, the deprecate-remove cycle is pretty much how a) Scala works and b) C# doesn't work.

Re: Scala Native

#206
post #194

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.

I've got at least 30 enterprise applications that disagree with your "nonstarter" assertion. Dead code can only exist in real world code.

I'm talking about within the main use case, which is front-end web development. I guess some folks might be cool with 10MB+ JS apps, but I don't think that would be terribly popular, and certainly not popular enough to bother with imitating Java reflection in JavaScript.

Re: Scala Native

#207

Earlier quoted context omitted.

What languages would you say have definitely better tooling: I'd say for sure the .NET languages, C++, Java, and Javascript but I'd put Scala just at a level below that, no? The tooling stories for Go, Rust, Haskell I don't think are as strong (yet), but that's definitely going to change though.

Not parent, but I would reduce it down to - C# with VisualStudio + JetBrains addon - Java with IntelliJ Why not the others you mentioned? - IDE support for F# is not very good. - VB is too dynamically typed to be reliable. - C++ IDEs seem to be constantly fighting with constructs that manage to break the IDE's understanding of the code. It's gotten better with LLVM, but even VisualStudio is far away from providing a…

- VB.NET support is at the same level as C#

- F# does lack some Microsoft love, but Visual F# Power Tools does improve the experience a lot

- Netbeans and Visual Studio 2015 are quite good in JavaScript support, specially on code where JsDoc comments are available

Re: Scala Native

#208
post #56

Hi, Some questions - Can this reuse existing Scala code? - How does it compare against Rust/GO/Swift? Why use this over them? - How about libraries?

A difference is that Scala can run on the JVM, the browser (and other JS ecosystems) via ScalaJS, and now native. It doesn't get more universal than that!

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.

Re: Scala Native

#209

Earlier quoted context omitted.

Scala.net didn't die because it was academic. It died due to lack of interest, as nobody cared about a Scala for .NET

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 proof of this, you only need to look at Clojure. Its .NET implementation is well maintained by David Miller, yet it's very unpopular. And the reason for why .NET developers don't care is because they don't have an open source culture. Or in other words, if it doesn't come from Microsoft, then it doesn't exist.

Re: Scala Native

#210
post #208
post #56

Earlier quoted context omitted.

A difference is that Scala can run on the JVM, the browser (and other JS ecosystems) via ScalaJS, and now native. It doesn't get more universal than that!

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.
Post reply on HN