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

171–180 of 265 posts

Re: Scala Native

#171

Post by petecox »

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

> We're reimplementing / porting from Apache Harmony all the things we need.

Would GCJ be any use? They had native compilation over a decade ago.

(Although developers moved on to IcedTea, iirc)

Re: Scala Native

#172

Post by kod »

pfarnsworth wrote: post #128
kod wrote: post #116

Earlier quoted context omitted.

That's funny, when I talked to Neha (ex-Linkedin, cofounder of Confluent) she explicitly denied this meme about moving away from Scala. The new Kafka client library is in Java just to reduce the number of dependencies, the server is still written in Scala. Strangely, using Java hasn't stopped Confluent from making breaking changes on dot release of the client... which really puts the lie to your explanation.

I specifically said the Scala clients are being deprecated. Go ask Neha to confirm this.

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

Re: Scala Native

#173

Post by asragab »

Scarbutt wrote: post #78
edko wrote: post #29

Earlier quoted context omitted.

Can you please post your slides from Scala Days? EDIT: Thank you! https://github.com/densh/talks/blob/517b20c30dd4aaf390785039...

Is there a video online for it?

In the past the videos from the Scala Days talks are usually posted online through Parley's, I expect that would happen again this year. Though it is usually a few weeks to a month or two after.

Re: Scala Native

#174

Post by runT1ME »

saosebastiao wrote: post #82
OhHeyItsE wrote: post #20

Earlier quoted context omitted.

Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc) Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to…

> It's pretty well known that Scala was heavily influenced by Haskell. Except that Martin Odersky himself has explicitly said that the primary influences were SML/OCaml and Java. > In particular, do notation (for comprehensions), I'll give you that one > pattern matching Which pre-date Haskell by nearly 2 decades in ML > lots of standard lib classes (ex Maybe (Option)), Also pre-date Haskell by nearly 2 decades, in a…

Given the fact that OCaml seems to be adding type class support and has support for monadic comprehension (do/for), it seems like these ideas are getting adopted in multiple places.

As a Scalaz committer and as a developer working at one of the largest scala shops (that makes heavy use of Scalaz), we don't try to write Haskell on the JVM. We do try to write pure, functional code as much as we can, and so what we end up with falls somewhere in the middle between an OCaml and Haskell.

Re: Scala Native

#175

Post by asragab »

the_af wrote: post #55
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…

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…

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.

Re: Scala Native

#176

Post by airless_bar »

asragab wrote: post #175
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…

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 reliable experience.

- JavaScript is dynamically typed, so IDE support is not reliable.

Re: Scala Native

#177

Post by AzzieElbab »

kbenson wrote: post #59
coldtea wrote: post #31

Earlier quoted context omitted.

Maybe, but in 20 years of programming (and 10+ of them with dynamic languages) I don't think I have had that issue more than 2-3 times. (1) Passing an int/string when a function expects the other type? Yes, I had that happen lots. (2) Concatenating a string and a (coerced) int? It's either a much narrower subproblem of (1), or exactly what I wanted to happen in the first place (e.g. print "Your score is: " + n + " po…

I've dealt with it lots. While concatenating variable and string literals like your example is very rarely ambiguous, but what can be is using + to operating on two variables whose input has been returned from elsewhere. Does that function that gets the user supplied value for height automatically convert to a numerical type, or is it a string? What about the function that gets the user supplied value for width? Is i…

I think concats like 1 + "111" can be disabled with import scala.Predef.{find_right_implicit => _,_}. Cant imagine how many things it will break though

Re: Scala Native

#178

Post by broodbucket »

airless_bar wrote: post #76
more_original wrote: post #57

Earlier quoted context omitted.

Looks like it's currently using the Boehm–Demers–Weiser conservative garbage collector. In scala-native/rtlib/src/main/resources/rt.cpp it includes gc.h and allocates memory using GC_malloc, i.e. not in precise mode.

Ouch.

They can still replace it later once they're further along with the rest of the implementation. I doubt they'll keep it.

Re: Scala Native

#179

Post by curried_haskell »

FnuGk wrote: post #105
airless_bar wrote: post #42

Not the author: > - Can this reuse existing Scala code? I think that's the plan. Would be a pretty pointless exercise without that, right? :-) > - How does it compare against Rust/GO/Swift? Why use this over them? Rust: Scala and Rust have different niches. Rust is more focused on low runtime overhead, while Scala is more focused on low development overhead. This means Rust can be potentially faster to run, but Scala…

I would like to hear what makes Go utter shit

Oodles of boilerplate to do stuff that's a (simple and understandable) one-liner in several other languages.

It's a dumbed down language, not a simplified language.

Re: Scala Native

#180

Post by AzzieElbab »

OhHeyItsE wrote: post #20
saosebastiao wrote: post #15

Earlier quoted context omitted.

Much to the Scalaz crowd's dismay, Scala always was an ML first and foremost. Any similarity to Haskell is incidental to Haskell/ML's shared background in strongly typed functional programming.

Incidental? It's pretty well known that Scala was heavily influenced by Haskell. In particular, do notation (for comprehensions), pattern matching, lots of standard lib classes (ex Maybe (Option)), many of the methods in the collections library (map, fold, take, etc) Anyway, I wasn't trying to disparage either of them (or this project). Just poking fun at the seemingly common "I want to use Haskell but I'm forced to…

It's pretty well known that any post that starts with "It's pretty well known" is usually misleading
Post reply on HN