Scala Native v0.1 • Hacker News Board

Re: Scala Native v0.1

#171

Post by lmm » Tue, Mar 14, 2017, 11:53 PM UTC

NickHoff wrote: post #161

Will this mean that we can get rid of type erasure when running native code?

It's more likely to make type erasure more extensive. The main effect of type erasure is to stop people doing naughty things in generic methods. When one doesn't have to support JVM reflection, erasure can be pushed further.

Re: Scala Native v0.1

#172

Post by notgood » Wed, Mar 15, 2017, 12:05 AM UTC

pjmlp wrote: post #134

oldrny wrote: post #131

Earlier quoted context omitted.

Javascript performs unchecked memory accesses? Or are you alluding to their both being weakly typed?

No,but implicit conversions, including from operators into numeric values isn't much better. The amount of page differences between "JavaScript the good parts" and the actual language reference speaks for itself.

That book was created before many alternatives came out; now if you are working in a team project you should look at JavaScript the same way you look at assembler, you know it will be the final thing but you shouldn't be creating it directly, but instead "compiling" from TypeScript, ELM, etc. (langs with no implicit conversions, strong typing, etc)

Re: Scala Native v0.1

#173

Post by geodel » Wed, Mar 15, 2017, 12:07 AM UTC

lmm wrote: post #168

bluejekyll wrote: post #11

Earlier quoted context omitted.

Long time Java lover here. I agree with all your points, but in the context of Java at least (does Scala support this?) there is no simple static binary that can be built and released, which includes the JVM. I think 1.9 will have this option, but this is something I didn't realize I missed until I started work with Rust and Go. It makes deployment so much simpler.

Does it really need to be a binary? Build executable jars (use the maven shade plugin), run them with java -jar foo.jar, that's about as simple as it gets.

Maybe some apps do not have classpath. Here is what I see of running kafka instance on one of my server. And it does not looks like as simple as it gets.

java -Xmx512M -Xms512M -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+DisableExplicitGC -Djava.awt.headless=true -Xloggc:/opt/kafka_2.11-0.10.0.0/bin/../logs/zookeeper-gc.log -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dkafka.logs.dir=/opt/kafka_2.11-0.10.0.0/bin/../logs -Dlog4j.configuration=file:bin/../config/log4j.properties -cp :/opt/kafka_2.11-0.10.0.0/bin/../libs/aopalliance-repackaged-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/argparse4j-0.5.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-api-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-file-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-json-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/connect-runtime-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/guava-18.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/hk2-api-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/hk2-locator-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/hk2-utils-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-annotations-2.6.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-core-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-databind-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-jaxrs-base-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-jaxrs-json-provider-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jackson-module-jaxb-annotations-2.6.3.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javassist-3.18.2-GA.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.annotation-api-1.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.inject-1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.inject-2.4.0-b34.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.servlet-api-3.1.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/javax.ws.rs-api-2.0.1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-client-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-common-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-container-servlet-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-container-servlet-core-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-guava-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-media-jaxb-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jersey-server-2.22.2.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-continuation-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-http-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-io-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-security-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-server-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-servlet-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-servlets-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jetty-util-9.2.15.v20160210.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/jopt-simple-4.9.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka_2.11-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka_2.11-0.10.0.0-sources.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka_2.11-0.10.0.0-test-sources.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-clients-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-log4j-appender-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-streams-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-streams-examples-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/kafka-tools-0.10.0.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/log4j-1.2.17.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/lz4-1.3.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/metrics-core-2.2.0.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/osgi-resource-locator-1.0.1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/reflections-0.9.10.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/rocksdbjni-4.4.1.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/scala-library-2.11.8.jar:/opt/kafka_2.11-0.10.0.0/bin/../libs/scala-parser-combinators_2.11-1.0.4.jar:/opt/kafka_2.11-0.10.0.0/bin/../lib

Re: Scala Native v0.1

#174

Post by steveklabnik » Wed, Mar 15, 2017, 12:50 AM UTC

spullara wrote: post #166

steveklabnik wrote: post #60

Earlier quoted context omitted.

You would need the same for Rust as well.

Rust's FFI is the same as C.

I'm not sure what exactly you mean by that, but what I was trying to say is that you can't expose Rust directly, you need to expose a C ABI. Which is totally doable, but is not just "drop in Rust code and it works."

Re: Scala Native v0.1

#175

Post by lacampbell » Wed, Mar 15, 2017, 1:11 AM UTC

Scala is a language I desperately wanted to like - high level, statically typed pure OO language. But in practice I found it almost unusable. The type signatures were unreadable and I distinctly recall writing a 100 line or so program where the type declarations crashed the compiler. And the tools themselves were huge memory hogs - sbt was a particularly bad offender (though otherwise quite pleasant).

I also did not get on well with the community, which seemed to have a lot of people with the attitude - "they won't let me use haskell at work so I'll make do with this shit". They didn't seem to understand or be interested in OO at all, and were very fanatical about driving application logic with types, purity, and the like.

Regardless, a native variant would be something well worth investigating if it ever reaches "production ready".

Re: Scala Native v0.1

#176

Post by brianwawok » Wed, Mar 15, 2017, 1:25 AM UTC

twic wrote: post #159

algesten wrote: post #63

Earlier quoted context omitted.

> the cold startup time of the JVM itself (which is not relevant on a server in comparison to desktop Java apps). I disagree somewhat with this. We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling. For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, th…

A JVM boots in about 100 milliseconds . A difference of 100 milliseconds made the difference in how you do error handling?

On what box with what kind of disk for how big of app? You aren't getting 100ms starts on a 199 mb fatjar on Amazon EBS.

Re: Scala Native v0.1

#177

Post by brianwawok » Wed, Mar 15, 2017, 1:32 AM UTC

dominotw wrote: post #100

sjrd wrote: post #74

Earlier quoted context omitted.

There is a small list under "Built with Scala.js" here: https://www.scala-js.org/community/ . And that's only for the public facing apps of companies who have explicitly sent a PR to the website to add themselves to the list. Other companies use Scala.js for internal tools.

that's hardly 'wildly successful'

Don't crap in Sid's Cheerios. For a project mostly made by one dude, Scala.js is amazing.

Re: Scala Native v0.1

#178

Post by pryelluw » Wed, Mar 15, 2017, 1:57 AM UTC

jwdunne wrote: post #160

pjmlp wrote: post #139

Earlier quoted context omitted.

> isn't the thing the kids are learning these days Yep, they learn Ruby and then they need to go JRuby when performance becomes relevant. :)

Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.

Im one of those. Anytime Python / Django doesnt cut it I use Go. Works very well.

Re: Scala Native v0.1

#179

Post by [deleted] » Wed, Mar 15, 2017, 1:59 AM UTC

[deleted]

Re: Scala Native v0.1

#180

Post by anoctopus » Wed, Mar 15, 2017, 2:06 AM UTC

scotchmi_st wrote: post #116

I would love for there to be a similarly thorough project with Clojure. It really bothers me there's no good native compiler. Apart from anything else, it means that Clojure lives and dies by the languages it compiles to, and while Java is used everywhere still, it probably isn't the thing the kids are learning these days. Besides, without going into any further rational arguments for why using the JVM (or another VM…

Java is still taught in plenty of places and is entrenched enough to stick around for the foreseeable future. The JVM would still be fine even if Java the language declined. Clojure is is a much less vulnerable position than most languages in terms of VM risk, with Clojurescript and ClojureCLR.

The real benefit of native Clojure to me would be for reducing startup time and the JVM overhead in containers. The best option for this right now is CLJS, but it would be nice to just not have a runtime.