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

121–130 of 265 posts

Re: Scala Native

#121

Post by danellis »

incepted wrote: post #102
patrickmclaren wrote: post #97

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!

Agreed. I see the statement "It's being developed at EPFL by one engineer" as a very high risk that once this student graduates or moves on to a different university, the project will be abandoned and die.

It's worth noting that there was an LLVM-backed Scala project that was abandoned and died, so I definitely hope this avoids the same fate.

Re: Scala Native

#122

Post by airless_bar »

the_af wrote: post #107
airless_bar wrote: post #93

Earlier quoted context omitted.

Thanks for the downvote. Let's close this discussion.

I didn't downvote you. In fact, I consider your post interesting, because (for example) I didn't know about the opt-in nullable references. Here's a +1 to counter the downvote.

Alright. Sorry.

Regarding your question about nulls and Java:

I think that there is not much Scala can do here. All existing evidence from other languages that tried this shows that there is a large semantic gap between "nullable values" and "values of unknown nullability".

As Scala is much more independent of Java it is a much smaller issue, but improvements with Java interop require action from Java library authors first.

The approach of supplying external nullability meta data has largely been a failure, because

a) authors are not aware of the stated, external constraints, so they could break these assumptions in future releases without even knowing

b) it's really really hard to retrofit nullability guarantees into libraries which have been designed without this requirement in mind

c) the existing ecosystem is not very amenable to these guarantees, as nullability metadata would be largely limited to final classes and members, because everything else could be subclasses or overridden in third-party code, breaking these assumptions

As soon as Java library authors themselves start using @Nullable/@NonNullable annotations everywhere, there is a good opportunity of reading these annotations and typing the values accordingly, but without it, benefits are very slim.

The planned changes are valuable for dealing with nullable types, but as mentioned "unknown nullability" needs a different solution, and I think it's currently not worth adding something to the languages as long as there is still hope for widespread adoption of nullability annotations.

Re: Scala Native

#123

Post by airless_bar »

jtheory wrote: post #120
airless_bar wrote: post #101

Earlier quoted context omitted.

People who can't assess statements objectively are probably exactly those people whose opinion I couldn't care less about. Perhaps this is exactly the filter I want to have.

A few different people are trying to politely show you a way you're undercutting yourself.

And that's perfectly fine! I won't throw a tantrum because I might disagree (which I don't).

Re: Scala Native

#124

Post by airless_bar »

pfarnsworth wrote: post #112
airless_bar wrote: post #83

Earlier quoted context omitted.

Well, then we got different sources. Scala is developed by the EPFL, Lightbend, and ScalaCenter. That's three, not one. > Scala keeps making breaking changes on dot releases, making it impossible to maintain long term. That hasn't been true for more than half a decade.

Sorry, I meant minor releases, like 2.10 to 2.11, etc.

These are not minor releases.

Re: Scala Native

#125

Post by PeCaN »

placeybordeaux wrote: post #119
kod wrote: post #65

Earlier quoted context omitted.

If by low development overhead you mean amount of crap you need to type in order to get things done, Scala absolutely does have low development overhead. As for Go, I'd say that's the most honest description of the language I've seen in a while.

If your limiting factor is how fast you can type you are either an amazing person that should be studied or you need to take a typing class.

I suppose "amount of crap you have to type" means "low boilerplate", not "basically APL".

Scala is pretty good in the low boilerplate department. I'm not a fan of Scala in the slightest, but in terms of code more or less directly expressing ideas it isn't bad.

Re: Scala Native

#126

Post by Negative1 »

nothrabannosir wrote: post #110
Negative1 wrote: post #89

Earlier quoted context omitted.

You're talking about Play Framework, I assume. They did some fancy work with Macros (i.e. Scala Reflection) which causes a lot of headaches for Scala.js. The reality is most of the reflection it does is nice but not necessary and I really wish they offered a "switch" to turn it off.

Sorry I've never used Scala macros, beginner's question: are Scala macros not completely compile time? Why would they use reflection? Is it just syntactic sugar for dynamic type inference? If they just use reflection during compilation: why would that not be compatible with whatever the runtime is? Shouldn't that be unaffected by runtime and purely depend on the compiler's support for reflect? Or am I looking at this…

Play uses it specifically for in it’s JSON module; you can define readers and writers that allow you to parse the structure of a JSON object. To avoid having to be very explicit, you can define a case class that directly mirrors the structure of that object. e.g. given some case class that looks like this: case class SomeObj(someInt: Int) you could do: val theObj = SomeObj((json \ “someInt”).as[Int]) or implicit val reads: Reads[SomeObj] = ((json \ “someInt”).read[Int])(SomeObj.apply _) with reflection, you get: implicit reads: Reads[SomeObj] val theObj = reads.validate(json)

Seems trivial with this small example but with large objects it keeps your code much more maintainable and consistent since reading and writing from that case class is the same.

As far as it not working in Scala.js, from my understanding it has to do with how the reflection library is shared between both runtime and compile time implementations.

You can read more about it here: http://docs.scala-lang.org/overviews/reflection/overview.htm...

Re: Scala Native

#127

Post by PeCaN »

lauriswtf wrote: post #50
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…

A small side note: Scala has several great features, but "low development overhead" just isn't one of them. Also why so harsh on Go?

Regarding Go... perhaps the parent was harsh, but not wrong per se. I think a strong argument can be made for Go being a very poorly designed language with an excellent community.

Scala certainly doesn't have high development overhead either. Build system more or less just works, plenty of libraries, minimal ceremony to do much. Don't get me wrong, I kinda hate Scala¹, but compared to _many_ languages it does have low development overhead.

¹ Disclaimer: haven't used Scala since 2.8. Maybe it's better now. Don't get your panties in a wad, but Scala is basically really shitty OCaml on the JVM in my mind.

Re: Scala Native

#128

Post by pfarnsworth »

kod wrote: post #116
pfarnsworth wrote: post #80

Earlier quoted context omitted.

I know for a fact LinkedIn dropped Scala because of dissatisfaction over Scala. Things like maintainability, the fact it was just a single company developing Scala, etc that caused them to switch away. Kafka is deprecating their Scala clients because of maintainability issues as well. Scala keeps making breaking changes on dot releases, making it impossible to maintain long term.

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