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

251–260 of 265 posts

Re: Scala Native

#251

Post by bshanks »

airless_bar wrote: post #61
the_af wrote: post #55

Earlier quoted context omitted.

Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds lik…

> all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. Scala devs deprecate and remove things that haven't worked out well. They have an established track record of making these migrations easier with each release. > Null Upcoming versions will make references non-nullable by default. If you want things to be nullable, you will have to opt-in explicitly with T|Null. > - Type infe…

I'm interested in exploring what makes a build tool good. Which design choices does SBT choose that makes it amazing?

Re: Scala Native

#252

Post by goldbrick »

edko wrote: post #210
pjmlp wrote: post #208

Earlier quoted context omitted.

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.

There are lots of existing libraries in PHP, why not target PHP?

Re: Scala Native

#253

Post by the_af »

Recurecur wrote: post #242
the_af wrote: post #23

Earlier quoted context omitted.

Haskell is a practical language, and one usual impediment for using it in your day to day work is "we must use the JVM". What happens if you remove that requirement? :)

Haskell doesn't seem to be a very good language for doing hard or soft realtime, or simulation (realtime games, flight simulation, robotics, industrial control etc.). On the other hand, given appropriate memory management which looks to be in the works, native Scala seems a pretty good fit. It seems to me Scala is potentially much more "general purpose" than Haskell. In other words, "more practical".

I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either), but Haskell can be used to write simulators and games.

Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?

Re: Scala Native

#254

Post by the_af »

bad_user wrote: post #166
the_af wrote: post #55

Earlier quoted context omitted.

Note: I use Scala in my day job. I consider it better than Java, but worse than other languages. I definitely agree that all languages accumulate compromises and inelegant hacks as they evolve. It's unavoidable. That said, in my opinion Scala's blunders are many. You can find out about many of them from Paul Philips, ex committer of Scala, but if he sounds too bitter to you (he does to me; at this point he sounds lik…

- I've never experienced null problems in Scala. There's theory and there's practice. In practice if a NPE does happen, you treat it as a bug and wrap it. I don't experience problems, because Scala libraries are well behaved and for Java libraries I read the docs. - Being a "jack of all trades" means Scala has the superior module system. In Scala you can have abstract modules, the way you have in Ocaml. In Scala type…

> I've never experienced null problems in Scala. There's theory and there's practice.

Yes, and I'm speaking in practice! If your language allows nulls, they will be used. I've experienced plenty of NPEs in Scala code, both from Java libraries and from misbehaving Scala code, to know this is real. Lucky you if you haven't experienced them! (As an aside: avoiding NPE is almost never a matter of simply "reading the docs". Many times there aren't docs at all, and even when there are, nulls are seldom documented).

> Being a "jack of all trades" means Scala has the superior module system

Your comparison with Haskell modules is fair. But that's just one aspect. Being a jack of all trades means Scala has poorer type inference, way worse type signatures, and generally it feels less clean than both a purer OOP language and a FP one. Scala does fine in all fronts, but not great. If you want to do FP, there are far better languages. I assume it's the same with OOP.

> SBT is amongst the best build tools ever available

If true, that's... unfortunate. SBT is uncomfortable and bizarre. Before you mention it: Maven looks likewise bizarre to me. These are tools to suffer with resignation, not to celebrate. Talking about Haskell, I'm trying to learn stack, which some say makes cabal more bearable. Are you familiar with it?

I agree IntelliJ is now an acceptable IDE for Scala. It's still ages from the comfort of using Eclipse with Java (at least what Eclipse used to be, not the unbearable beast it is now), and to be honest, IntelliJ only recently became usable. A couple of years ago (definitely less than 3 years), the IDE choked on Scala code and highlighted compilation errors left and right where there were none -- and I'm talking about vanilla Scala code, nothing advanced.

Re: Scala Native

#255

Post by cle »

pjmlp wrote: post #204
cle wrote: post #203

Earlier quoted context omitted.

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.

I agree. There's a complexity tradeoff with either decision.

Having worked with both approaches, there's a time and place for both. Being able to quickly dive into a codebase is not always a good thing. One thing conservative enterprise developers should like about DSLs is that they require new developers to structure their code in a way that fits the intended domain model. I've seen my fair share of code written by developers who "quickly dove in" and they almost never fit the model and end up causing a huge mess which may be unrecoverable. Conversely, if you don't trust your developers to write decent code, trusting them inside a dynamically-typed DSL is probably not a good idea either.

Re: Scala Native

#256

Post by airless_bar »

sievebrain wrote: post #240
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…

What Oracle does is cute, but I will put my bet on people who have a solid track record at shipping.

Re: Scala Native

#257

Post by airless_bar »

duaneb wrote: post #243
hibikir wrote: post #34

Earlier quoted context omitted.

Because all the other languages mentioned are better only from very specific perspectives. Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. Scala gets a bad rap precisely because people are big fans of their own way of writing code, call it better, and think that anyone that wants some…

> Scala's strength is precisely that it's a mutt: Want to write imperative code? Sure. Functional? No problem. How about a type system that far more featureful than Go? That works too. This also essentially describes C++. This is also why both languages can be so terrible to use: every library has its own dialect.

The C++ comparison is great because it tells readers that that the person making it has no idea about C++, Scala or both.

Re: Scala Native

#258

Post by lmm »

placeybordeaux wrote: post #248
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…

Go is obviously pretty god awful when it comes to design when viewed strictly as a language. The language is mind numbingly boring and restrictive. The reason why people are interested in go (at least IMO) is because of stuff that isn't really about the language design. They are interested in the subsecond compile times out of the box. They are interested in one of the best standard libraries out there, a static bina…

I guess I can see the case for using Go for something basic like CRUD that you just want to "crank out". But to my mind the kind of code you can program that way shouldn't be something you program at all - rather you write a system that handles it all generically (e.g. Rails/Django have generic model editor forms). Maybe in a business where programming is incidental it makes sense? But certainly it would destroy any kind of "hitting the high notes" business.

Re: Scala Native

#259

Post by sjrd »

duaneb wrote: post #245
airless_bar wrote: post #43

Earlier quoted context omitted.

Scala is a pretty great language on its own. Have a look at the adoption of Scala.js. The ecosystem of Scala.js is larger than the "compile-to-js" ecosystems of "rust, Haskell, go, c++" combined. One of main strengths of Scala is that people get things done. It's the only language of the ones you mentioned which has reasonable support across three vastly different platforms.

Who actually uses Scala.js, though? It still seems firmly in the hobbyist camp. > One of main strengths of Scala is that people get things done. This is also true of rust, go, c++, and arguably haskell. I don't see anything about scala that inherently makes it easier to "get things done". If anything, I've spent a good 10% of my scala development time (over hundreds if not thousands of hours) debugging library, compi…

> Who actually uses Scala.js, though? It still seems firmly in the hobbyist camp.

This is false. You can see a few commercial uses in "Built with Scala.js" at https://www.scala-js.org/community/

I have also talked to people out of a few tens of companies who have told me they were using Scala.js in production.

Re: Scala Native

#260

Post by Recurecur »

the_af wrote: post #253
Recurecur wrote: post #242

Earlier quoted context omitted.

Haskell doesn't seem to be a very good language for doing hard or soft realtime, or simulation (realtime games, flight simulation, robotics, industrial control etc.). On the other hand, given appropriate memory management which looks to be in the works, native Scala seems a pretty good fit. It seems to me Scala is potentially much more "general purpose" than Haskell. In other words, "more practical".

I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either), but Haskell can be used to write simulators and games. Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?

"I've no experience with hard realtime systems, so I won't debate about that (I'll just say I doubt Scala is suitable for that either),"

Hard and soft realtime both require deadlines to be met, the difference being that in soft realtime a missed deadline is not considered a fatal error, just highly undesirable.

Examples: Soft realtime: A game where 60 FPS is desired for smooth animation. Lower frame rates degrade the experience but are tolerated.

Hard realtime: Flight surface control software in a fly-by-wire aircraft. Missed deadlines potentially result in a crashed plane - a true "fatal error".

Any ahead of time compiled language with deterministic memory performance may be used for hard realtime. Absolute performance isn't required, although it is desirable. As long as memory primitives are available for native Scala that permit pre-allocation, and the GC can be turned off (trivial), it should work fine even for hard realtime.

As an aside, I expect for many things native Scala will equal C++ in performance. On the JVM is extremely close to Java in performance.

"but Haskell can be used to write simulators and games."

Realtime simulations and games? It seems hard to reconcile immutable state with time-based simulation in any efficient way. Then there are garbage collection cycles and laziness to deal with.

"Haskell is currently a practical general purpose language. I don't see any evidence Scala is any better at this. Are you speaking from experience?"

GC based languages in general aren't good choices for the types of systems discussed above. GC is also a problem on smaller hardware (embedded systems for instance) since there should be a much larger memory pool than actually used for good performance.

Haskell also throws in laziness, which leads to non-determinism.

Scala also supports mutable state and the OO paradigm if they are better or more convenient for a particular system.

Post reply on HN