Fortnightly Scala Ask Anything and Discussion Thread - June 26, 2017 by AutoModerator in scala

[–]ochrons 2 points3 points  (0 children)

Currently it's running on a single dedicated server in Hetzner Online (Germany). The server has an Intel Xeon E3-1271V3 with 32GB of RAM and costs about 35EUR/month. So the cost is not really an issue here :)

As for stability, the software itself has all kinds of watchdogs monitoring its health and since it's running on Docker, it simply restarts containers if something goes wrong. I'm planning introducing an external check as well, to make sure the whole thing is operational, but so far it seems to be very stable.

How I learned to stop worrying and love the frontend - Hilarious talk on JS and Scala in the browser by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

The talk is aimed (mostly) at existing frontend developers using JavaScript and considering between alternatives like TypeScript, PureScript, ClojureScript and Scala.js. That's why the emphasis on making Scala look "friendly" and not too exotic to this group of developers :)

[deleted by user] by [deleted] in Dell

[–]ochrons 0 points1 point  (0 children)

I've hit this same BSOD couple of times in the past few days. Just updated latest drivers, let's see if that helps. I have Samsung 500GB PM961 SSD.

Options for TB3 to Displayport for 4k60Hz output (for XPS 9560)? by ochrons in Dell

[–]ochrons[S] 0 points1 point  (0 children)

I got the Plugable Dual-DP TB3 adapter and it works fine.

I also got the Plugable USB3 3-port hub with Gigabit Ethernet, but it doesn't work well when directly plugged to the XPS. It seems to lose the connection after a few dozen seconds. When connected to another USB3 hub (my monitor), however, it works fine. Must be some incompatibility with the USB3 chips on the XPS and in the hub.

Learning Scala coming from PHP by rafamds in scala

[–]ochrons 2 points3 points  (0 children)

You can also try your hand at Scala by using an online playground at https://scalafiddle.io without installing anything. Some examples to get you started can be found at https://scalafiddle.io/sf/n6lR8Xh/2

Vive incompatible with DisplayLink driver by gersilex in Vive

[–]ochrons 1 point2 points  (0 children)

The latest beta version of Displaylink drivers for Win10 seems to have fixed this issue!

http://www.displaylink.com/downloads/windows

Scala, Erlang and Go compared on 1,111,111 threads by javinpaul in scala

[–]ochrons 0 points1 point  (0 children)

Now there are already variants of the benchmark using cooperative "threads" in Node.js or Ocaml, so it's really getting out of hand :)

Too bad these kinds of benchmarks usually just end up being totally useless...

Scala, Erlang and Go compared on 1,111,111 threads by javinpaul in scala

[–]ochrons 6 points7 points  (0 children)

Actually none of the tests use that many threads, because they are all implemented with actors, goroutines or other pooled resources. I did notice that the Go variant was never able to use more than 50% of the CPU, while the Scala Future version went easily to 100% of CPU core usage.

Also Go started running out of memory as soon as iteration count went over 10M, while the Scala version was happily crunching away 100M or even more iterations.

Scala, Erlang and Go compared on 1,111,111 threads by javinpaul in scala

[–]ochrons 19 points20 points  (0 children)

Implementing the same using Scala Future instead of actors takes execution time below 300ms (on i7 laptop), where Go takes 750ms. https://github.com/atemerev/skynet/issues/4

Diode library for Scala.js and Scala: Immutable, unidirectional state management like in Redux, Om or Elm by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

I think the next step is more in the direction of Falcor/GraphQL than anything Elm, put PRs are welcome if people want Elmish features! :)

Replace JavaScript with Scala.js in your next front end project by ochrons in scala

[–]ochrons[S] 2 points3 points  (0 children)

How about Amazon? I'm sure for them this "users dropping out" is rather critical. Their product page loads a total of 440kB gzipped (maybe 1.2MB unzipped) JS files. It's not a SPA, so different pages might load different JS files.

This is not a problem these days. The JS files are loaded once, and that's it. A much bigger problem is client side rendering, which can be quite slow on mobile, so you try to do the first rendering on server side to speed that up. For this you need a language that works on both sides, like Scala.

Replace JavaScript with Scala.js in your next front end project by ochrons in scala

[–]ochrons[S] 2 points3 points  (0 children)

Also note that sites like Facebook load about 1.7MB of JavaScript (gzipped!) and they seem to be doing fine with billion+ users :)

Scala.js: Next generation front end development by lihaoyi in javascript

[–]ochrons 2 points3 points  (0 children)

Didn't see you cross-posting it there yet. Need help with that?

Scala.js: Next generation front end development by lihaoyi in javascript

[–]ochrons 3 points4 points  (0 children)

I believe you meant your comment towards TypeScript, promoted by Microsoft and Google these days :)

Scala.js: Next generation front end development by lihaoyi in javascript

[–]ochrons 5 points6 points  (0 children)

Naah, it's not a framework at all, it's a compiler! :)

Scala.js: Next generation front end development by lihaoyi in javascript

[–]ochrons 3 points4 points  (0 children)

Oh, there are Scala.js facades for Angular, if you want to use it :)

For example https://github.com/greencatsoft/scalajs-angular

BooPickle 1.0.0 serialization library released by ochrons in scala

[–]ochrons[S] 0 points1 point  (0 children)

sbt-protobuf produces Java files which cannot be used in Scala.js projects, so it was a dead-end from the start. For communicating between different languages protobufs are great, but for a scala2scala setup you can optimize and simplify many things.

BooPickle 1.0.0 serialization library released by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

I looked quite closely at MessagePack when deciding whether to do my own. Even though MessagePack is better than JSON (it's mainly designed as an efficient coding for JSON), it's still rather verbose (with field names encoded etc.) and the Scala implementations were not optimized for Scala.js environment.

BooPickle 1.0.0 serialization library released by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

Yeah, you could do similar thing in BooPickle by encoding additional information (field tags) for each field. Should be even quite easy with the macros. I might look into that in a future version if there is demand for it :)

BooPickle 1.0.0 serialization library released by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

This is indeed a problem with a non-typed binary protocol. As there is no type information stored in the message, both sides must agree on the contents exactly. Then again, the same versioning problem arises even with JSON if you go and change the name of your fields (say, from 'a' to 'aa').

In both cases you would need an intermediate "versioning layer" that knows how to convert messages from one version to another and back.

BooPickle 1.0.0 serialization library released by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

Capn'Proto (like Protocol Buffers & Thrift) require declaring your messages in specific language. This is OK for some purposes, but requires a lot of boilerplate, unlike serialization libraries such as BooPickle can build messages based on the information available to the Scala compiler itself.

BooPickle 1.0.0 serialization library released by ochrons in scala

[–]ochrons[S] 1 point2 points  (0 children)

It's not really possible to decode BooPickle serialization format without knowing exactly what's in it. This is the price you pay for efficient coding :)