Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scala Native v0.1

scala-lang.org

Post reply on HN
Print view View original

211–220 of 254 posts

Re: Scala Native v0.1

#211

Post by SureshG »

Recurecur wrote: post #75
LeanderK wrote: post #10

Earlier quoted context omitted.

I think for Server-Application Scala on the JVM will probably beat Scala-Native. The benefits of Scala-Native over Scala JVM are: - faster startup time - (drastically) lower memory footprint - fine hand-tuning of you application All these things are not super important in server-applications. For example Java trades memory for throughput (higher memory footprint, but also higher throughput. These usually go hand in h…

In general (not for server apps), two major benefits of Scala Native are: - Predictable latency if desired (optional GC) - Very low call overhead for C ABI As to your point about memory use, Java trades memory for convenience, not performance. GC requires substantially more memory for similar performance. I read an IBM blog (which I can't find at the moment) within the last week which showed a Swift web service runni…

The medium post is really a stupid benchmark. Check this for a real JSON serialization benchmark - https://www.techempower.com/benchmarks/#section=data-r13&hw=...

Re: Scala Native v0.1

#212

Post by SureshG »

geodel wrote: post #165
sreque wrote: post #133

Earlier quoted context omitted.

Many things pointed out in this article apply to just about every managed language runtime. Implement a TreeSet in any language and you'll see the same overhead from object headers, memory alignment, etc. Java has some oddities that cause it to waste extra memory, but off the top of my head the only I can think of is 16-bit character Strings. Java 9 is supposed to help with that by allowing Strings to internally stor…

Go uses quite a bit less memory than Java. http://benchmarksgame.alioth.debian.org/u64q/go.html

As per the Specjbb benchmark, JDK9 compact strings optimization itself provides,

  * 21% memory footprint reduction
  * 27% less GC
  * 5% throughput improvments
https://www.infoq.com/presentations/java-se-9-cloud - check this presentation for more details.

Re: Scala Native v0.1

#213

Post by rekado »

platz wrote: post #83
rekado wrote: post #79

Unfortunately, this requires an existing Scala compiler to build, so it won't be useful as a bootstrap compiler for Scala on the JVM. Does anyone here know of an alternative implementation of Scala that could be used to build the libraries and tools of the reference implementation from source? It is a problem that many compilers cannot be bootstrapped from source without a trusted binary of a previous release.

how big of a problem is it, really? is it a theoretical problem or a practical problem for industry users?

It is a practical problem for people who want to have a correspondence between source and binary. Some users would like to have to rely on as few opaque binaries as possible. There are efforts underway to build a minimal C compiler in a subset of Scheme that can be implemented on bare metal. The goal is to reduce the set of binaries that needs to be trusted or audited manually.

Re: Scala Native v0.1

#214

Post by taway_1212 »

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.

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking frameworks expect to mock classes, so every bit of functionality needs to be it's own separate class, just like in Java...

Re: Scala Native v0.1

#215

Post by pjmlp »

taway_1212 wrote: post #214
jwdunne wrote: post #160

Earlier quoted context omitted.

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

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking framework…

If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE.

Re: Scala Native v0.1

#216

Post by jwdunne »

taway_1212 wrote: post #214
jwdunne wrote: post #160

Earlier quoted context omitted.

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

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking framework…

Funnily enough, I was reading a Scala program the other day and I noted how much it looked like a high-level dynamic Java programming. I think there was maybe 8 lines of typical functional programming code and the rest just looked like imperative code. It seems a waste to use Scala that way to me, but maybe I'm missing something?

Re: Scala Native v0.1

#217

Post by lmm »

geodel wrote: post #173
lmm wrote: post #168

Earlier quoted context omitted.

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:+PrintGCDateSt…

If you use the maven shade plugin (or similar) you can replace the whole "-cp ..." stanza with a "-jar myfile.jar". The "-D" arguments can be set in code instead (though I'd ask why you are allowing remote management without authentication and without SSL?).

The rest of the arguments are about GC tuning and logging. How would you do those things in a language that gives you a "simple" static binary? Either you can't at all, or they'd require an equally complex series of arguments.

Re: Scala Native v0.1

#218

Post by lmm »

taway_1212 wrote: post #214
jwdunne wrote: post #160

Earlier quoted context omitted.

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

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking framework…

I view mocks as a code smell. If you have good interfaces and make a clear distinction between services and values you should never mock - stub your services, and use real values in tests.

Re: Scala Native v0.1

#219

Post by lmm »

jwdunne wrote: post #216
taway_1212 wrote: post #214

Earlier quoted context omitted.

As a Scala/Java dev, I'd be willing to explore Go not because it seems like a better language (I have no opinion), but because I'd hope there's less design pattern/enterprise-overengineering approach among devs. Even in Scala, which is super-flexible, people tend to structure code like they do in Java - everything is decomposed into tiny classes to the point of absurd. One of the reasons is that the mocking framework…

Funnily enough, I was reading a Scala program the other day and I noted how much it looked like a high-level dynamic Java programming. I think there was maybe 8 lines of typical functional programming code and the rest just looked like imperative code. It seems a waste to use Scala that way to me, but maybe I'm missing something?

Even if you're writing Java-like code you get a lighter syntax, fewer awkward special cases (primitives and arrays aren't as special, == does the right thing by default, try doesn't need braces and nor do function blocks, if is an expression), and some very useful code-saving constructs (case classes, pattern matching). It's not using Scala's full potential but it's still a good language for that space.

Re: Scala Native v0.1

#220

Post by lmm »

therealmarv wrote: post #203
hocuspocus wrote: post #22

Earlier quoted context omitted.

In the age of containers it's really not that much harder to build and deploy a JVM app. Edit: thanks for the downvotes but you could at least tell me what's so crazy about my statement.

No downvote from me. But a explanation why e.g. compiled binaries are better. I had a hard time to get a normal non fancy Scala Play project running on a 512MB DigitalOcean instance. Mostly because it needs a lot more ram for building. I solved it with using a bigger swap partition. With single binary precompiled programs this problem is more a developer machine problem than a infrastructure problem. So I think the d…

You shouldn't build it on the deployment server. You build a jar and upload/download that to/from the place you want it to run, just as you'd do with an executable. A jar is "not binary" but what practical difference does that make?
Post reply on HN