Live data from Hacker News

Scala Native

github.com

71–80 of 265 posts

Re: Scala Native

#71
post #65

Earlier quoted context omitted.

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?

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.

"Low development overhead" was taken from parent comment, but I understood that it means how productive and fast it is to write code/develop something in Scala.

Re: Scala Native

#72
Such blatant ignorance, cognitive dissonance, and chauvinism is astounding.

I have worked with tools like you and I hope I never do again, your attitude is toxic and I doubt your professional capability.

Re: Scala Native

#73

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…

> Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes Woah!

Go is great if you dont mind writing 1000's of lines of boiler plate code one would expect to exist.

Re: Scala Native

#74
post #67

Earlier quoted context omitted.

> Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes Woah!

Clearly people either love or hate Go. There is a lot of hate I've seen on HN. I personally love it, but who am I to say what is a good language and what isn't.

Clearly people have opinions that range across a wide spectrum on any subject.

To say interest in is divided into either hate or love is disingenuous.

Re: Scala Native

#75

Earlier quoted context omitted.

Clearly they added a bunch of new stuff that the JVM can't understand. So it is either "Scala like LISP" or It is a superset of the Scala language. Meaning all existing stuff will work with it, but if you use new secret keywords it will work "better". Which seems not quite ideal, because that means most Scala libraries will not be "tuned", and you will need all new libraries.. just like ScalaJS made you need entirely…

> just like ScalaJS made you need entirely new Scala libraries that did not use reflection. Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js. I think quite a few things in scala-native are there to show the possibilities of this platform, but in the mid- to long-term those improvements will be supported everywhere: - @struct and AnyVals: As soon as AnyVals can support mor…

> Most Scala libraries never used reflection, so most of the ecosystem "just worked" on Scala.js.

Do you have personal experience with this? I do not have hard numbers, but for me - basically none of my stack worked.

I had to find a new JSON parser. I had to find new validation for my form stuff. Etc. etc.

It wasn't impossible, but it was a lot of work.

Re: Scala Native

#76

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!

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.

Re: Scala Native

#77

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…

>Go: Go is utter shit that only survives due to the devs name-dropping "Google" every 5 minutes. Making blanket statements like that without any substantiation makes me want to just write off everything else you have said.

So what? If you can't tolerate an opinion I can imagine you are having a hard time on the internet. :-)

Re: Scala Native

#78
post #29
post #4

Hi all, I'm the author of the project and would gladly answer any questions.

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?

Re: Scala Native

#79

Just saw this on twitter. Scala, you have my attention. There were a lot of talks about "the tools of yesterday" and "the tools of the future" lately. Scala getting closer to the metal, without the JVM is a significant step toward "the tools of the future".

I've heard a lot of the early adopters of Scala are moving away, including LinkedIn, Twitter, etc.

[deleted]

Re: Scala Native

#80

Earlier quoted context omitted.

I've heard a lot of the early adopters of Scala are moving away, including LinkedIn, Twitter, etc.

No, not really. Some people from losing ecosystems like to spin it that way¹, but the truth is people are happy, adoption is great, and companies see that pain-points get addressed. Of course there are companies which drop Scala, but often like in LinkedIn's case it's not caused by a dissatisfaction with Scala, but new leaders making different decisions like "we are using 10 different languages, we should consolidate…

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.

Post reply on HN