Making the move from Scala to Go - <AUTHOR> https://movio.co/blog/migrate-Scala-to-Go/ <comment><USER3> Since they cite me (and my essay from 2014) as part of their decision making process, I want to throw in 2 cents here. They ended up deciding on Go, whereas I have ended up preferring Clojure, yet I agree with a lot of what they say, so I'll try to clarify why I ended up with a different decision than what they made.

I understand what they mean when they write:

 _I think the first time I appreciated the positive aspects of having a strong type system was with Scala. Personally, coming from a myriad of PHP silent errors and whimsical behavior, it felt quite empowering to have the confidence that, supported by type-checking and a few well-thought-out tests, my code was doing what it was meant to._

There are times when I appreciate the strict type-checking that happens in Java. I do get what they mean. But there are also a lot of times when I hate strict type-checking (in particular, when dealing with anything outside of the control of my code, such as whimsical, changing 3rd party APIs that I have to consume (for some business reason), or even 1st party APIs that feel like 3rd party APIs because they are developed by another team (within the same company) or for some reason we can not fix the broken aspects of some old API that was developed in-house 6 years ago.) Because of this, I have become a proponent of gradual typing. If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement. This is what I attempted to communicate in my essay "How ignorant am I, and how do I formally specify that in my code?" [1]

I think everyone who works with Clojure sometimes misses strict type-checking. Because of this, there have been several efforts to offer interesting hybrid approaches that attempt to offer the best of all worlds. There is Typed Clojure for those who want gradual typing, and there is more recently Spec. Given what I've written, you might think I am a huge fan of Typed Clojure, but I've actually never used it for anything serious. The annotations are a little bit heavy. I might use it in the future, but for now, I am most excited about Spec, which I think introduces some new ideas that are both exciting for Clojure, and which I think will eventually influence other languages as well.

Do watch the video "Agility & Robustness: Clojure spec" by Stuart Halloway. [2]

I also sort of understand what they mean when they write this:

 _No map, no flatMap, no fold, no generics, no inheritance… Do we miss them?_

There are times when we all crave simple code. Many times I have had to re- write someone else's code, and this can be a very painful experience. There are many ways that other programmers (everyone who is not us, and who doesn't do things exactly like we do) can go wrong, from style issues such as bad variable names to deeper coding issues such as overuse of Patterns or using complex algorithms when a simple one would do. I get that.

All the same, I want to be productive. And to be productive in 2017 means relying on other people's code. And, in particular, it means being able to reliably rely on other people's code -- using other people's code should not be a painful experience. Therefore, for me, in 2017, one of the most important issues in programming is composability. How easy is it for me to compose your code with my code? That is a complex issue, but in general, those languages that allow for high levels of meta programming allow for high levels of composability. Both Ruby and Javascript and Clojure do well in this regard, though Ruby and Javascript both have some gotchas that I'd rather avoid. In all 3 languages, I find myself relying on lots of 3rd party libraries. I use mountains of other people's code. Most of the time, this is fairly painless. But there are some occasionally painful situations. With Ruby I run the risk that someone's monkeypatching will sabotage my work in ways so mysterious that it can take me a week to find the problem. And Javascript sometimes has the same problem when 3rd parties add things to prototype, perhaps using a name that I am also using. I so far have had an almost miraculous time using Clojure libraries without facing any problems from them. It's this issue of composability that makes me wary of Go. While I sometimes crave a language that simple, I can't bring myself to give up so much of modern languages best features.

[1] [http://www.smashcompany.com/technology/how-ignorant-am-i- and...](http://www.smashcompany.com/technology/how-ignorant-am-i-and-how-do-i- specify-that)

[2] [https://www.youtube.com/watch?v=VNTQ- M_uSo8](https://www.youtube.com/watch?v=VNTQ-M_uSo8)

<comment><USER4> > If I am facing a problem that I have never faced before, I like to start off > without any types in my code, and then, as I understand the problem more, I > like to add in more contract-enforcement.

This seems to be a widespread sentiment.

In practice, I've found that prototyping anything remotely complex without types is so painful that I'd rather settle for an inferior design than trying to come up with the best possible abstraction.

In Haskell, I come up with a coherent skeleton without having to implement mundane details, hit a wall in the design space because of some case I didn't think of, come up with a better idea and then go back to the code and refactor with confidence. The type system always guarantees that my prototype is coherent as a whole. And I can do that dozens of times.

In Clojure, even with spec, I'd have to implement all my functions fully before being even able to test the design as a whole (sure, testing individual functions works fine in the REPL.) And after hitting a wall, having to reimplement everything every time is just too much work.

<comment><USER5> > In practice, I've found that prototyping anything remotely complex without > types is so painful

Just to offer a counter-point, I have a Clojure project here with 3k LOC, without using spec/schema. All I have is 700 LOC tests. The tests enforce semantic meaning, along with (some) contracts. I miss types from time to time, but it is no where near as bad as you mention. Against me is the fact is that my app is mostly self-contained, and written all by me. I am fairly certain the project would be atleast 30k LOC if I wrote it in Java.

I think value of types only comes into being when there are many people working on a single code base. Repl/tests/integration tests will take one a long way before it reaches its limits.

I don't buy the argument that types are useful for large codebases, because 1\. Types don't enforce meaning. Meaning is far complex than type. Haskell style types only work as far as they enforce meaning. 2\. Types have limits too. More accurately, humans have limits. Working with large codebases where there are 1000s of types is hard; which it shouldn't be because that was type systems selling point all along.

Cleaner abstractions of code, separated by strongly enforced protocols(types) is the way to go, I think.

<comment><USER6> Today I caught a bug in a macro-expanding code walker, where it was expanding the wrong form. The syntax being walked is (foo-special-operator x y z . rest). x and z are ordinary forms that need to be expanded; y is a destructuring pattern (irrelevant here). The walker was expanding z in the place of x: that is to say, expanding z twice, and using that as the expansion of both x and of z. That's simply due to a typo referring to the wrong variable.

The type system would be of donkey all use here, because everything has the correct type, with or without the mistake. The code referred to the wrong thing of exactly the right type.

A lot of code works with numerous variables or object elements that are all of the same type, and can be mixed up without a diagnostic.

<comment><USER7> So the issue you faced was that you used z twice, and x not at all? In that case, linear types ([http://edsko.net/2017/01/08/linearity-in- haskell/](http://edsko.net/2017/01/08/linearity-in-haskell/)) may have caught that.

<comment><USER6> x not being used at all can be caught by a simple unused variable warning.

In this situation, the variable's value was used somewhere, so that didn't go off.

</comment></comment></comment></comment></comment></comment><comment><USER8> _As it turned out, more flexibility led to devs writing code that others actually struggled to understand._

This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging.

"Clever" should be regarded as a limited resource. Also, the shop should encourage a culture where "clever" with regards to making code easier to understand should be valued above all else.

<comment><USER9> I'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere.

And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

<comment><USER10> >And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

IMO, the answer is people vastly underestimate the cognitive cost of reading code. "Code" rarely exists in a vacuum, the reader has a universe of inputs, outputs, problems, solutions, failures and goals. The cognitive cost of trying to read someone's code is something that must be paid multiple times per day and at one point do you have to wonder - is the gain in expressiveness for a single programmer worth the cognitive cost of the multiple programmers who have to parse that code.

I'd imagine the answer is no - especially for companies that spend more time iterating and patching based on customer feedback than actually designing and architecting systems. My belief is that expressive languages have their place but companies are far more likely to build their software in a "patch-test- iterate" environment which favors less expressive languages.

<comment><USER11> I'll keep repeating myself: the cognitive cost of "code" is dwarfed by the cost of understanding an _application_. If a couple esoteric languagn features take an extra few hours to learn but reduce LOC tenfold, it's a price I'd pay every time.

Not everyone feels this way, the investment to learn these features may not pay off right away, and if you come from a "move fast and break things" language (python/php/js) it can feel like a waste of time.

<comment><USER12> > _If a couple esoteric languagn features take an extra few hours to learn but > reduce LOC tenfold, it 's a price I'd pay every time._

Issue is that a beginner pre-conditioned long enough on "verboser, imperativer" models/languages, when reading/comprehending such a codebase, has to literally mentally expand every 1 line into 10 upon reading, for quite a while .. some weeks, some months, as more intuitive grasp sets in slowly over time. Probably what happened at OP's quoted company and with the different speeds in comprehending what "clever" (compact) code some of their coders came up with, what they flippantly called "code that was harder to understand by others"..

</comment></comment></comment></comment></comment><comment><USER13> Scala is the latest whipping boy(1). It's a great language with tons of warts, but it actually acknowledges the warts.

Case in point, when (2)Paul Phillips went after Scala (mentioned in the article), Odersky took some of that criticism to heart for the next iteration/rewrite of the Scala compiler. In an industry where everyone doubles down, that's extremely refreshing.

Scala's cognitive footprint can lead to misbehaving programmers, but clean Scala has its own elegance if the cuteness is avoided. The slowness I'll give you though :(.

1) I'm old enough to remember this language CoffeeScript that "really really sucked". And then all of a sudden, people were using ES6/TS with parameter destructuring, classes, lambdas, but yeah, CS was the bad guy.

2) Despite his bellyaching, Paul Phillips never really left Scala the language (check his commit log), just the compiler team & lightbend.

<comment><USER14> Well Coffeescript was refreshing in being very terse and introducing a lot of niceties that were missing in JS. It was also trivial to introduce footguns given its whitespace rules and some pretty radical syntax rules.

New Javascript has basically taken the best that CS had and wrapped it in the necessary turd that is backwards compatibility in a hastily designed language, but the results speak for themselves and modern JS is just much more pleasurable.

<comment><USER15> Yes, the frustrating thing was that people previously praised the language _despite_ its obvious footguns. A language where 'dropping parentheses where you can' is idiomatic is a disaster waiting to happen.

I don't know about you, but I never want to be holding a footgun, ever.

<comment><USER16> Coffeescript worked pretty great when using it on solo projects, because I could use the bits I liked (which where very nice) and ignore all the footguns that I didn't like. The problem as such was that any coffeescript I wrote turned out not be all that idiomatic.

</comment></comment></comment></comment><comment><USER17> Some experience to share: I studied Scala and FP on the side before jumping to a team that was using it in production. Most of the engineers on the team have an enthusiasm to learn about and use fp.

Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others.

We program as simply as possible but when a new technique is discovered we go ahead and use it after it's been presented to the team and everyone is comfortable with it.

all code is reviewed and unreadable code does not pass

Compile times haven't been an issue. As an example a 100k line Scala program with around 900 files takes around 2 minutes to rebuild whilst incremental changes are immeasurably fast. Reloading code while a local server is running is easy by default in IntelliJ.

Using worksheets for playing is often useful.

we don't use actors where streams would make more sense and vice versa, know the purpose of your tools

I've had bad experiences with Go. I know that for the application I'm working on it would not scale to 10 programmers working and constant refactoring due to business goals changing.

<comment><USER18> What magical place do you work that allows for this level of engineering quality?

> all code is reviewed and unreadable code does not pass

Sounds quite nice.

<comment><USER19> Thorough code review is a great process that should be used in every company.

<comment><USER18> Keyword: _Should_

</comment></comment></comment></comment><comment><USER20> Looking through the really abstract scala code they linked brings up a problem that really frustrates me in haskell. Why doesn't anybody document their really abstract code? You _know_ it's going to be confusing, so why not help out? If I have a type like

        def foreignKey[P, PU, TT <: AbstractTable[_], U] ...

It's not sufficient to document the function's arguments. You also need to document the type variables! Likewise in haskell with code like

        f . g x . (h (i x) $ j y z) . k $ aNamedVariable

It really isnt' so hard to refactor that into

        let descriptivelyNamedFunction = (h (i x) $ j y z)
            anotherDescriptivelyNamedVariable = descriptivelyNamedFunction . k $ aNamedVariable
         in f . g x $ anotherDescriptivelyNamedVariable

It's much larger, but in certain places it prevents so many headaches. It's great that you can put stuff inline, but both communities seem super lax about accepting code that is the opposite of self-documenting.

 _edited for clarity, i hope_

<comment><USER21> I mostly agree with you, but I also think a bit part of what Haskell-like FP shows is how often your code is invariant to so many things that the variables no longer have any sense to them whatsoever.

That doesn't really excuse badly named variables when that doesn't hold. It's more that it's something sort of novel to a lot of Haskell-like programmers and so we all get excited about it and probably overdo it somewhat. But on the other hand, I think it's very well-justified often enough.

For instance, with

        class Functor f where
          fmap :: (a -> b) -> (f a -> f b)

there are many words you _could_ give to f, a, and b but they're essentially all misleading.

With another example from the article, Strong Syntax, the "Syntax" bit is basically a convention in scalaz that ought to be immediately obvious if you're familiar with the scalaz library. The "Strong" bit has to do with a subtype of "Profunctor" structures, "Strong Profunctors".

Profunctors are generalizations of functions that show up all over the place. Strong profunctors are profunctors which can "distribute over a tuple".

Giving names to these types is an exercise in futility. At least with a function `a -> b` might be named `in -> out`, but with a Profunctor there isn't even that intuition. It's just too general. Subsequently, it shows up all over the place.

<comment><USER22> > At least with a function `a -> b` might be named `in -> out`, but with a > Profunctor there isn't even that intuition.

What about:

      dimap :: (newIn -> in) -> (out -> newOut) -> p in out -> p newIn newOut

<comment><USER21> With profunctors there's not necessarily anything going in or out and especially not necessarily and notion that the thing going in produces a thing going out.

That's all roughly true with one kind of profunctor, a function arrow, but not true in general.

For instance,

        data Counterexample a b = Cx (Set a) b

is (very, very, very nearly [0]) a profunctor, but a isn't necessarily "going in" and b isn't necesssarily "coming out".

[0] It's a profunctor if a is finite. You can handle the infinite form by writing it as `data Cx a b = Cx (a -> Bool) b` which is equivalent to what I wrote when `a` is finite... but it also makes it a little easier to pretend that a is "going in" even if that's a bad intuition.

<comment><USER22> I'm not sure I see how the intuition is bad here? What would the lmap implementation for your (Set a) example be if not equivalent to the (a -> Bool) case? And how is that not an example of data "going in"?

More generally even if there are Profunctors for which this analogy isn't perfect, I feel like the intuitive type names are still more useful than random letters. Especially for a relatively advanced concept like Profunctors, for which I expect pretty much all users to be comfortable with the idea that a type variable does not necessarily imply that concrete values of that type will exist.

<comment><USER21> It is equivalent to the (a -> Bool) case. In Haskell at least, all "negative type parameters" are ultimately generated by the left side of a function—but this is more a concern for how ideas are modeled (perhaps partially) in Haskell then a fundamental one. If you're writing code that's

        forall p . Profunctor p => ...

then `in` and `out` aren't generally valid.

I definitely hear the argument that ergonomically it might be a good idea to use a sort-of-appropriate model to drive better terminology... but at the same time I think there are drawbacks. I think it helps the early part of a learning curve but then hinders the latter part. An expert doesn't care what they're called since they're just mentally erasing the names as appropriate anyway. A non-expert will try to carry the metaphor further than it can go and gets stuck.

This is why there's endless debate about calling Monoid "Appendable" or something like that. For the commonest cases that's the right idea... but the first time someone questions why there's an Appendable instance for Bool (two, actually!) you're fighting with your own inappropriate metaphor.

"Oh, Appendable actually means Monoid but we didn't want to say that straight up."

</comment></comment></comment></comment></comment></comment><comment><USER23> My company also have a lot of problems with Scala, both technical and non technical ones, but so far we have managed to control it:

\- As for slow compilation times, incremental building helps a lot.

\- Intellij works most of the time, and if it doesn't a few type annotation will fix it.

\- It's very hard to find people with Scala experience. We have given up on finding those and decide to train people from the beginning for 2 months. I myself studied mechanical engineering in university and I can code just fine after a few months.

\- The language itself is very complex, so we let more experienced programmers write the backbone/framework/library/common parts and the less experienced one do the code glueing-job. That way we can have Scala type safety and expressiveness without scaring the juniors. IIRC one company used Haskell also do the same and they said it is very hard to introduce runtime bugs because almost everything were caught during compile time, "If it compiles, it works".

You may ask why going through so much trouble just to use Scala. There are many reasons (speed, type safety etc..), one of them is that we can be immensely productive _when needed_ , the conciseness of the language combine with a powerful type system let us implement complicated features rapidly without very few bugs. IMHO Scala strives to combine both FP and OOP on top of JVM so a lot of tradeoffs had to be made. The developers have to learn a lot of concepts and have good self discipline, but in exchange we can write fast, robust systems and even enjoy it.

(Edited for better formatting, this is my first time posting here.)

<comment><USER24> +1 for "If it compiles, it works" .... been there done that ... multiple times !!! And yes in the beginning the feeling of "it works on the first run" was just strange and it get me some time getting used to it

</comment></comment><comment><USER25> [Scala team lead at Lightbend here]

I'm always eager to learn how we can improve Scala, especially as we kick of the Scala 2.13 cycle (hard at work on compiler performance and standard library improvements). Email is 'adriaan.at("lightbend.com")

Regarding Scala's growth, I will leave you with [https://www.indeed.com/jobtrends/q-scala.html](https://www.indeed.com/jobtrends/q-scala.html).

<comment><USER26> For completeness:

[https://www.indeed.com/jobtrends/q-scala-q- golang.html](https://www.indeed.com/jobtrends/q-scala-q-golang.html)

<comment><USER27> Or for those who don't call it "golang":

[https://www.indeed.com/jobtrends/q-scala-q-golang-q- go.html](https://www.indeed.com/jobtrends/q-scala-q-golang-q-go.html)

<comment><USER28> "Go" the language is tricky to search for as just the word "go", so I wouldn't read much into that. Many job ads contain the word go, but have nothing to do with go the language. e.g. "...go to our website..." "...go above and beyond..." etc.

</comment></comment></comment></comment><comment><USER29> Some notes:

\- the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual _functional programming_ (as in programming with mathematical functions), then you wouldn't want to go back to a language that makes that impossible ;-)

\- Akka actors are not the only game in town for processing data, you can also use Finagle, FS2, my own Monix and even Akka Streams; And yes, concurrency often requires multiple solutions because there's no silver bullet and Go's channels suck compared with what you can do with a well grown streaming solution

\- Scala's Future are not meant for "hiding threads" and 1:1 multi-threading is actually simpler to reason about, because if that fancy M:N runtime starts being unsuitable (because lets be honest, most M:N platforms are broken in one way or another), then you can't fix it by choosing a more appropriate solution without changing the platform completely

\- Your devs are maybe lazy or maybe they don't give a fuck, but given that you're supposedly dealing with concurrency in your software, if those developers struggle with a programming language, then it's time to invest in their education or hire new developers, because the programming language is the least of your problems

\- Paul Phillips still works with Scala and he most likely hates languages like Go, so when you mention him or his presentation, it definitely cannot be in support of Go

<comment><USER30> Paul Phillips here. I searched my tweet archive for my tweets about Go. Draw your own conclusions.

\- Kill me before I look at go.

\- Nobody shot me first so I looked at go. Sigh. After maybe an hour of go I was ahead of where I was after a week with rust.

\- The first audible WTF with go: cuddled else is mandatory. Parse error otherwise.

\- go is a terrible, terrible language, yet still a major productivity boost. Amdahl's law in another context.

\- You often see languages which are fighting the last war. Go is fighting the War of 1812.

\- If someone had made up Go within a work of fiction, they'd have been laughed out of the room.

\- I had thought Blub was a rhetorical device, but Go is more Blub than Blub.

\- reduce: what you will do with your expectations after you start with Go

\- Did they miss any chance to introduce an ad hoc inadequate non-solution? Tool directives in comments! What could go wrong!

\- Comical levels of confirmation bias in proglangs. Guy doesn't get it, poor impl, isn't useful, "see?" Examples: scala, python, go.

\- Some specifics are enumerations in scala, closures in python, and anything devised since 1980 in go.

\- Go: compiler directives in comments is "an elegant design". [https://t.co/DjCO1UxgC2](https://t.co/DjCO1UxgC2) [http://t.co/BR3kFxRZvc](http://t.co/BR3kFxRZvc)

\- Rust and Scala drown you in complexity. Go drowns you in simplicity.

\- This comment sums up Go pretty well. [https://t.co/Td9Q3wOW43](https://t.co/Td9Q3wOW43)

\- go logging package lets you set the global Writer, but not query it. So you can't save/restore it. Nice job.

\- This year's gold medalists in type safety's missing-the-point olympics: Go! [https://t.co/ktrlBUEwP9](https://t.co/ktrlBUEwP9)

\- Turns out Go is the result of a bar bet between Rob Pike and Robert Heinlein. Everybody lost.

\- It's incredible how far Go has lowered my estimation of the vaunted Google engineer. What an institutional failure.

\- Go is what you might come up with if your definition of programming was "shuffling electrons".

\- A Go discussion thread is "how to build a space station with crayons" up to homotopy.

\- A supposed selling point of Go is that you can learn it in a day. Think of what that tells you about what it can do.

\- The existence of Go leads me to realize the infamous Google technical interview is designed to _weed out_ out-of-the-box thinking.

\- I added a second file to [https://t.co/ktrlBUEwP9](https://t.co/ktrlBUEwP9) further explaining how go's casting requirements are broken by design.

\- But little did I know, I'm just a "lesser" programmer because I enjoy Go's simplicity" says a commenter. Well, yeah.

\- The Go string type can't be passed as a fmt.Stringer. You apparently have to accept interface{} and type match. Amazing.

\- An example of go upside: "go get ...gocov" and code coverage instantly worked. In scala it has always been painful/fragile at best.

\- Any go code which has error in parameter position which tests err against nil will silently miss a bunch of errors.

\- Hostility to abstraction: the Go story

\- Sad that google waited this long to put a deep mind on go.

<comment><USER30> I missed a couple which didn't mention go:

\- Rob Pike is like Henry Ford, except when people said "faster horses" he said "that is the best idea I've ever heard."

\- Rob Pike is the Antonin Scalia of programming language design - <USER2> Originalist. Except 1970s not 1770s.

<comment><USER31> Enjoy your horse then; I'll just speed off into the sunset with the latest model Generics Motors has to offer. :)

</comment></comment></comment></comment><comment><USER32> I have a simple question. In the article they mentioned they had a concurrency issue with a timed buffer that they later neatly solved with go channels and goroutines. They said that they solved the problem in Scala by moving to the actor model, but that required importing Akka into their project and training everyone how to use Akka.

My simple question is: couldn't they have achieved the heart and soul of the actor model by just making an object on its own thread, and talking to that object on a simple synchronized message queue? It's a handful of easy to understand lines of code, and nobody needs to delve into the sea of madness that is learning and configuring Akka and its actor model.

In more general terms, it's possible to use Scala as Java that plays well with immutability and functional programming techniques without turning your codebase into an overly complex difficult-to-understand mess. But for some reason people just can't stop themselves.

For what it's worth, Elixir hits a real sweet spot of functional goodness, combined with awesome concurrency without getting too deep into bizarre complexity.

<comment><USER33> Actors should be in a process no? If it's in a thread then it'll take the main process down with it.

Erlang's BEAM VM every actor is in it's own process. So if something goes bad then it can be restarted via supervisor.

Scala is on JVM and JVM isn't built with concurrency in mind and I think Erlang's BEAM is too good at this. Akka is gimped too, you have to write actor a certain way iirc other wise it takes over the scheduler. BEAM is preemptive, it doesn't matter if you have a for(1) loop, your process/actor can only take some much of the cpu time.

I think hands down Erlang is a really really beautiful language for concurrency. It's syntax is ugly but it's such a small language that does everything you need for concurrency. Scala is just big and there are so many way to shoot yourself in the foot and tons of compromises. I also think implicit type is too magical and shot myself in the foot many time using libraries that use implicit type.

<comment><USER34> Erlang's processes are green threads, they're just called "processes". Neither Erlang, nor Akka run 1 thread or process per actor, they just schedule multiple actors over N native threads inside the single process (ignoring multi-node situations).

<comment><USER35> Two notable differences: Akka Actors concurrency is done at library level and an actor can block a JVM thread if not coded carefully. Erlang processes concurrency is support at VM level and there's no way an Erlang process can block a VM scheduler (native code aside, but with native code all bets are off)

</comment></comment></comment></comment><comment><USER36> Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style.

My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think.

The largest bad design decision was to support inheritance which leads to it's own problems with type inference. Sad that after Java devs already recognized how bad inheritance is that Scala also got inheritance.

The sticking out problems is how very very very slow Scala compiles. This makes web development (even with Play) and unit testing a huge pain (and the complicated syntax + implicits + type inference makes IntellJ as an IDE very very slow on detecting problems in your code)

Concerning the article I do think Futures are a more powerful (and higher) concept compared to coroutines. They are easier to combine IMHO [2]

Now trying Kotlin for the faster IDE and compilation speed, sadly the Kotlin developers think Option is only about nullable Types (it's not and something differen!) and don't embrace it.

[1] [http://codemonkeyism.com/scala-unfit- development/](http://codemonkeyism.com/scala-unfit-development/)

[2] [http://codemonkeyism.com/a-little-guide-on-using-futures- for...](http://codemonkeyism.com/a-little-guide-on-using-futures-for-web- developers/)

<comment><USER25> The only thing on your list on your blog [1] that's still true is that we care about PL research. Since 2.10, we've worked really hard on improving the migration between major versions, and the feedback has been very positive. We'll keep working on finding the right balance between ease of migration and fixing issues in the libraries. Scala 2.13 will be a library release, with further modularisation of the library (towards a core that we can evolve much more slowly, and modules that can move more quickly, but where you can opt to stay with older versions as you prefer).

We've also invested heavily in incremental compilation in sbt. Sbt is meant for use as a shell, and it's super powerful when used like that. When I'm hacking the compiler in IntelliJ, recompiles of some of the biggest source files in the compiler (Typers.scala, say) take just a few seconds. I rarely have time for office chair sword fights anymore.

With Scala 2.13, half of my team at Lightbend is dedicated to compiler performance. We'll have some graphs to show you soon, but our internal benchmarking shows our performance has steadily improved since 2.10.

<comment><USER36> I still have the problem of upgrading because not all of the libraries are cross compile or do work. At the end of last year we've upgraded one library which cost us many days.

Next is upgrading Lift to 3.0 which will be a nightmare (again).

"We've also invested heavily in incremental compilation in sbt."

Yes, I read this over and over again, and I see micro benchmarks posted.

Using SBT with continuous unit testing I can't feel a difference - or it is so slow with a major code base that it's still much to slow and I judge it having no progress. Either way, after years it is still too slow (newest Scala + newest SBT).

"I rarely have time for office chair sword fights anymore."

Today I expect Kotlins practically instant compilation. 10 seconds for compiling some changed files is already to much for rapid development with TDD/Web, it breaks my flow, but YMMV.

"We'll have some graphs to show you soon,"

See above, I've seen dozens of micro benchmarks that claim improvements, in the end it doesn't show up in my real projects - at least in mine and the person who migrated to Go in the linked article. And all the other blog post authors that moved away from Scala towards something faster (Kotlin, Java 8, Go, ...)

But as I've said, I've moved on to Kotlin for new projects because for me Scala is a lost course.

</comment></comment></comment><comment><USER37> So _four_ developers moved from Scala to Go.

'As you can see, we largely came from the stateful procedural world.'

No, you come from the 'my first languages' world....

<comment><USER38> Ah, the GORILLAS.BAS world...

</comment></comment><comment><USER39> Making the move from Go to X, and why we're not going back (2018)

<comment><USER40> [https://mobile.twitter.com/HackerNewsOnion/status/7587710913...](https://mobile.twitter.com/HackerNewsOnion/status/758771091363856384)

</comment></comment><comment><USER41> Sounds more like moving away from a big jvm monolith is how they gained their speed.

Our Scala based microservices build in seconds.

Anyway, no idea who movio is, but cool they like go. Not sure why they needed to write Scala FUD in the process.

<comment><USER14> I think that if you _have_ to move to microservices just to avoid atrocious compilation times that means there's something horribly wrong in the language stack. Microservices should be used to solve architecture problems, not a workaround for compiler slowness.

<comment><USER42> just cyclic dependencies between project's generated source codes of exposed interfaces/contracts. ez.

It's not hard to fuck up ur sw eng. practices and blame language.

</comment></comment></comment><comment><USER43> This mentions weak IDE support as one of Scala's pain points, but Go has very much the same problem, and the language is vastly less complex.

The two best IDEs for Go right now IMO are VS Code and the EAP Gogland, but both of them are not yet on par what you get with Java. VS Code has only support for very rudimentary refactoring (renames) and relies on a rather slow horde of external CLI linters (executed on save) to provide code analysis. Gogland has pretty nice refactoring, but its built-in code analysis is still too shallow.

Both will get better, but I can't take the claim that you'd move to Go from another language due to "lack of a good IDE". If you want the best IDE move to Java (or Kotlin, or C#) and never look back.

<comment><USER44> Go can be written without good IDE. I just use Sublime with Go plugin it works great. Also Gogland gives sub-par experience to many experienced Go users. E.g. it does not use `gofmt` but their own formatter which they use for all IDEs. Not sure about their refactoring tool but `gorename` seems to me fine refactoring tool.

<comment><USER43> Gogland's non-standard formatting is one of my pain points. But the standard go* tooling doesn't offer any proper refactoring.

Unless if by refactoring you mean "Jus' renaming my functions and variables and nothing else, and only when all my packages compile correctly, with 80% guranteed success" then Gorename is a good tool, I guess. YMMV.

This is what I have in mind when I talk about good refactoring (Resharper on Visual Studio being the gold standard IMHO): [https://es137custom.files.wordpress.com/2012/12/resharperref...](https://es137custom.files.wordpress.com/2012/12/resharperrefactoring.png)

It's a huge productivity boost for me, enough that I'm willing to live with the subpar experience of IDE Vim Plugins.

Again, you can argue that _YOU_ don't need this IDE fanciness, but OP claimed this is a major reason for them wanting to ditch Scala.

</comment></comment></comment><comment><USER45> _Having this smartness disparity between devs is really bad for team dynamics, and complexity leads invariably to this._

More and more I believe this to be a profound truth.

<comment><USER46> This seems like an argument for the lowest common denominator.

What should programmers who enjoy working with more powerful abstractions do?

<comment><USER47>
      >> What should programmers who enjoy working with more powerful abstractions do?

Work on teams where the lowest common denominator is higher.

</comment></comment></comment><comment><USER48> Obligatory "did you try running sbt ~ compile before you started complaining about the compile times" post.

It's amazing how the tools for faster turnaround times exist-- the one thing the Scala community needs to do a better job of is clear, opinionated documentation.

Also -- [https://github.com/scala-native/scala- native](https://github.com/scala-native/scala-native) \-- watch that space.

<comment><USER49> Could you explain this a little bit? I am just getting into Scala, usually I use `sbt run` and `sbt test` while I am working, then `sbt dist` to package my production app. What does `sbt ~ compile` do ?

<comment><USER50> If you run `~` before any command, sbt watches the directory for any source changes, and on detecting source changes, redoes the command. So `sbt ~compile` will re-compile any new sources as soon as they are saved.

<comment><USER51> The use of the ~ here illustrates the problem in the scala world: a lot of surprising bells and whistles. Why not call it watch instead of ~?

<comment><USER17> Or just use IntelliJ and you can reload classes while your program is running if you want. Sbt is a very powerful tool but it's not written with readability for new users in mind.

</comment></comment></comment></comment></comment><comment><USER52> In my experience, the larger your codebase, the more you appreciate these features:

\- a strong type system

\- a pure functional language so you have referential transparity

\- an IDE that helps you with refactoring

If your project is small than you can do without all of those, actually they might even slow you down.

When I read the article, I get the feeling that this particular team was working on a small codebase.

<comment><USER53> The author also complains about the sub-optimal IDE experience with Scala and then says he moved to a langage that has none …

</comment></comment><comment><USER54> I would consider Scala a far better language from a safety, syntax and design perspective. Go is compelling due to the low GC pause times, and to some extent the community for some types of software. I would imagine switching between these to be quite rare. I would expect more movement from Scala to Swift or perhaps Rust.

</comment><comment><USER55> Stroustrup is right, there are languages that people complain about, and languages that no-one uses. Go is now firmly in the former camp. Even if the complaints are always generics and error handling.

</comment><comment><USER56> All this whinging about compile speed ~LOL~

I remember when software development was a gentleman's game and we looked forward to sharing a half hour together in somebody's office or around the railing or coffee pot to exchange ideas and news while the build finished.

Scala is good. Its not perfect, its not appropriate for every situation, but its worth learning and using.

Go has an anachronistic feel about it that is just, well, ugly.

</comment><comment><USER57> I think this team was doomed from the start.

If you come from an imperative programming background, as this team did, (typed) FP is a new way of thinking. It takes a long time to adjust to this new mindset, _particularly_ if you've been programming in imperative languages for a long time. Go, on the other hand, is more of the same. It doesn't seem that anyone on the team had a background in typed FP, and it doesn't seem that they had any support from the organisation to make this shift. I'm not surprised it took them a long time and didn't end well.

Learning new things is hard and until universities and other training providers start teaching FP these kinds of stories will continue. (The alternative, to have companies investing in training and mentoring [plug: my company provides these services for Scala] doesn't appear to be likely en- masse, even though it would be radically cheaper than throwing away code.)

<comment><USER58> They just want a language more efficient to do develop/test/deploy loops. Yes, Go does much better than JVM based langauges from this point.

</comment></comment><comment><USER59> Wonder where they'll go once their codebase becomes crippled with interface{} type and nil pointers check, and they stop using chanel to return to mutex for performance reasons, or more control.

Note : sounds snarky, but it's an honest question i find asking to myself after having tried many server side techs and feeling limited with go.

<comment><USER60> Probably nowhere because 1) never happens 2) is a non-issue and 3) too probably 99% of the time.

<comment><USER53> 1) I have a totally different experience ! When your are writting code which must have a certain degree of genericity you end up having a ton of interface{} …

2) wat ? How having a null pointer a non issue ?! Empirically it causes fewer bugs than in Java or JavaScript, but it's still a really common source of bugs in Go.

3) I've never run into this kind of problem myself since I dont use Go for performance-heavy code.

</comment></comment></comment><comment><USER61> X = the current disliked language of the month on Hacker News

Z = latest, most discussed language on Hacker News

Making the move from X to Z, and why this is just a marketing campaign from a marketing group.

<comment><USER62> I've been on HN for years. Scala has been widely criticized with these exact same criticisms for years. These are all legitimate issues people have, even if you don't think they're valid.

</comment></comment><comment><USER11>
        It took some of us six months including some after hours MOOCs, to be able to get relatively comfortable with Scala

Huh. Yeah, sounds like Go is a really good choice for you guys! For some reason our team is able to onboard new engineers and have them be productive in less than a month...

<comment><USER63> You're either being a little unfair, or have a very low standard for "productive".

<comment><USER64> No, there's a huge difference in quality of programmers. I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. I've been on other teams where some of the guys still couldn't understand closures after 6 months.

<comment><USER65> > I've led a team that was productive (by which I mean shipping code that met > business goals) within weeks of starting with scala.

Personally, I like to measure things like that by how fast a team/developer can get up to speed on maintaining an already existing non-trivial codebase in the language. Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.

<comment><USER11>
         Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.

I don't agree. I work on an incredibly large Scala team and a powerful type system gives you a _lot_ more confidence to make everything from minor bug fixes to sweeping refactors.

The price paid for having to learn the complexities and power of Scala (which I'll admit is much harder than other languages) pays off in that it lowers the overall application complexity by reducing the need for a plethora of frameworks/libraries.

If you write Scala like you'd write a java/python/Go application, you'll have better type inference and a worse IDE, along with slower compile times. Not a great proposition. If you write Scala like a pure functional language that allows you to create powerful libraries and DSLs that make it possible to hack together very reliable applications, you'll be amazed.

</comment></comment></comment></comment></comment><comment><USER66> Scala is an excellent language from a safety and design perspective. It's biggest flaw is the lack of a corporate sponsor and higher barrier of entry. Map, FlatMap, Options are all really great but hard to grok at first.

<comment><USER25> Thanks, glad you like it! We at Lightbend (my employer) don't think of ourselves as very corporate, but we definitely sponsor Scala development. My team is hard at work on Scala 2.13 (well, except the part of it that's commenting on HN stories).

</comment></comment><comment><USER67> wrt to programming languages, going from scala to go is like going from english professor to honey boo boo. go is basically new php with lots of ftm features baked in. scala, for all it's flows stays true to it's goal - it is a scalable language. use as mush of it as you are comfortable with and keep growing. here is btw one of the "coolest" features of go in scala [http://storm-enroute.com/coroutines/docs/0.6/101/](http://storm- enroute.com/coroutines/docs/0.6/101/)

</comment><comment><USER68> I don't know, types help me think. I get lost real soon without them and the reason why I could never pick up any Lisps. In Scala/Haskell I can come up with a solution incrementally and types are the biggest reason why. I always have that feeling that I am missing out on the trumpeted awesomeness of Lisps but I can never justify using them. Maybe there is a personal angle to language selection but I just can't help but feel types are the future and a real advancement of technology.

</comment><comment><USER69> Some points might be valid it's really hard not to dismiss the whole article when you write things like this:

> The funny part is that, because dependency hell is so ubiquitous in Scala- > land (which includes Java-land), we ended up using some of the projects that > we deemed too complex for our codebase (e.g scalaz) via transitive > dependencies.

First, I've just checked, there are 237 dependencies in my classpath, and it never caused me any issue. Dependency management is a complex problem, but the JVM ecosystem does a pretty good job at it. Binary incompatibilities that are specific to Scala are pretty much non-existent today outside of very specific cases.

Secondly, why use stuff that you deem too complex and then complain that it is? Transitive dependencies are just that, transitive. I have Cats and Shapeless in my classpath and I haven't found yet the need to use them in my own code.

<comment><USER70> It is too bad though that e.g. IntelliJ cannot tell the difference, will offer you the transitive dependency's stuff in code completion, and now you are tied to it. Of course, the thing _you_ used went away in the newer version that the newer version of your direct dependency uses, and now you're spending time figuring out dependencies instead of writing code. Which, in my experience, happens pretty much all the time in Java/Scala land. (and I won't start about the sorry state of build tools for the JVM; seen them all, nothing is as nice as what I'm using now (Elixir/Mix)).

</comment></comment><comment><USER71> Nice write-up. I wonder if you guys have tried using Scala as a functional programming (_no_ vars, returns, partial functions, exceptions, mutable data structures, etc.) - or just used it like in the stateful procedural world.

<comment><USER70> I think the problem here is that Scala doesn't make any choices for you. Now you're busy having to do a ton of code reviews to make sure that everyone stays within the chosen paradigm, stuff will of course slip through and bite you, and there you are with one big nice mess. Plus, it's too simple to just pull in a Java library which doesn't mesh well paradigm-wise with what you have (or a Scala library for that matter). I've done a ton of Scala and I've been left with the same conclusion as I had waaaay back with C++ - too many potential solutions, too many pitfalls and ways to make a mess. I guess I'm a person that wants to make the language make the paradigm choice for me and then I'll happily stick with that. One reason I like a language like Elixir so much - the language made the choices, it matches the problem set I work on pretty well, all the libraries look the same, life is simple, I can just write code (instead of trying to understand a moderately complex build.sbt file which basically comes with a paradigm of its own).

</comment></comment><comment><USER72> Worked with a principle engineer once who used language as a litmus test. If you could not understand functional programming like Lisp or MLs, he'd just know not to get you on his team.

Obviously, most of the software could be written by monkeys, and only need to produce trivial functionality, in those cases, please switch to Go or at least stick to Java or C#. I say that because in the hands of someone who doesn't know, more expressive languages can cause havoc, and turn really messy. Especially the hybrid languages like Scala.

<comment><USER32> Leading teams to victory and accomplishing business objectives is an even more important litmus test, in my book. But different strokes for different folks I guess!

<comment><USER72> But the best thing you can do to improve the team's chances of accomplishing business objectives is to choose its members more carefully.

<comment><USER32> I agree. But personally I'd be concerned about a team lead who thinks the make or break thing is whether a candidate engineer loves fondling their monads all day.

<comment><USER72> Ya, it's a little draconian, but in practice it was more nuanced. If you just didn't know those things, it was fine, but if you couldn't learn and eventually understand them...

</comment></comment></comment></comment></comment><comment><USER73> "..it felt quite empowering to have the confidence that, supported by type- checking and a few well-thought-out tests, my code was doing what it was meant to. "

Does this mean that on what software is "meant to do" type checking covers most test cases and only few additional is needed to ensure iy does what it's meant to do?

<comment><AUTHOR> That's not what I meant to emphasise, but kind of. I was contrasting the Scala programming experience to this: [https://eev.ee/blog/2012/04/09/php-a-fractal- of-bad-design/](https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) which seems to be pretty much the point expressed by the Coursera people in the blogpost I quoted from them.

</comment></comment><comment><USER74> You know, this really needs to be said:

Does this company have 'adult' technical supervision or what?

</comment><comment><USER75> "Part of my frustration with Scala (and Java) was the feeling that I was never able to get the full context on a given problem domain, due to its complexity."

This. Same with any other kitchen sink language.

</comment><comment><USER74> And they could have just used Java from the beginning.

<comment><USER44> And how do you propose to offset the benefit of smaller image size and lower memory usage?

<comment><USER74> I see. Smaller image size and lower memory usage was the critical factor informing the decsion to use Scala and not Java?

If we're talking server provisiong cost bread ($) I think factoring in the costs of stack switch, code rewrites and salaries should be on the table too!

p.s. Have been writing Go code since the day it was released. My comment has nothing to do with their decision du jour.

</comment></comment></comment><comment><USER76> If I had too move away from scala I would rather consider swift. Could anyone help me compare those two languages ?

<comment><USER77> [http://hyperpolyglot.org/rust](http://hyperpolyglot.org/rust)

Here is a pretty good comparison between Rust/Swift/Scala

</comment></comment><comment><USER78> Felix looks like an awesome programmer! :)

</comment><comment><USER79> Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.

<comment><USER80> > the build time has reduced from 15m to 3.6m.

Is 3.6m the build time of the remained Java code, the rewritten Go code, or both remained Java and rewritten Go code together?

<comment><USER79> java ~ 3.4 mins, go - 3-4 secs :D

</comment></comment></comment><comment><USER81> First Yammer, then LinkedIn, then Twitter, and now movio.co.

The exodus away from Scala continues.

<comment><USER82> Regarding LinkedIn, they are not moving away from Scala AFAIK. And Yammer was a long time ago. Note that Scala has improved quite a bit since then, especially with the release of 2.12.0 (Java 8 support).

I don't understand why, but there seems to be a lot of negativity aimed towards Scala. It's a solid language backed by the JVM, has great Java interop, and beautifully combines OOP and FP in a way I've never seen in any other language. Also, ScalaJS[1] is absolutely amazing.

Yet every few weeks, you get a blog post detailing why Scala is a failure and how it will be dead in a few years. Seriously, what gives?

[1]: [https://www.scala-js.org/](https://www.scala-js.org/)

<comment><USER83> I don't care much for language battles, but maybe I can shed some light on this.

The former VP of Platform Eng at Twitter said in 2015, "What I would have done differently four years ago is use Java and not used Scala as part of this rewrite. [...] it would take an engineer two months before they're fully productive and writing Scala code." The VP of Platform Eng at Twitter expressed regret for the choice of Scala.

LinkedIn's SVP of Eng Kevin Scott said, "We are not getting rid of Scala at LinkedIn. We've recently made the decision to minimize our dependence on Scala in our next generation front end infrastructure which is rolling out this year. We've also made a decision to focus our development infrastructure efforts on Java 8, Javascript, Objective-C, Swift, C++, and Python given the nature of things that we are building right now and will be building in the foreseeable future. That said, we have a ton of Scala code running in production, and will continue to provide basic support for Scala and those Scala systems for the foreseeable future."

And Coda's Yammer letter is around for those to Google.

Companies don't ditch languages that they have a huge investment in. It's just not worth it when you reach a certain level. It's not just the code to run your services, but the huge investment in performance, tooling, and monitoring - not to mention the bugs that come up from code that's just a little different. Twitter is past the scale where it can ditch a language. So is LinkedIn. But they can regret choices or decide to concentrate future development in a different direction.

I think that Java 8 has dulled some people's enthusiasm for Scala. Java 8 comes with a lot of nice features that people _really_ missed in Java and might choose Scala because it did have them.

But I think more generally, there's been a movement away from being enamored with features, cleverness, and terse syntax in a language. Scala is a language of features, cleverness, and terse syntax. I was at a presentation by Rob Pike (one of the Go folk) and he argued that there are many things you can add to a language that feel clever and satisfying to write, but obscure what's actually going on and ultimately the things that are annoying, that are time sinks, and that cause problems aren't that you had to use a loop rather than something more clever. It was a long time ago so this is potentially more what I took away from the presentation than Pike's sentiment.

If we look at Go, Go is boring as hell. I mean, it has one cool thing in it - the goroutines (with cool being defined as something generally not found in all programming languages). It doesn't even have a lot of the cool things Java has. Java has annotations, inheritance, generics, a cool lambda syntax, "final" immutable references, advanced codegen. . . Go doesn't even have a way for me to declare an immutable variable. But it's so easy to pick up because there's basically nothing unfamiliar to someone who has experience with a mainstream, imperative language. Really, the syntax might be a bit different and it will always take a bit to adjust to a new language, but goroutines is really the only feature of the language that should be "new" to users (maybe multiple return vars, but that's stretching it). It generally emphasizes the ease of understanding and debugging over terseness of code. People seem to be enjoying that (at least some people). Part of it might just be that when a new philosophy comes onto the block, a lot more is written about it than gets written about old philosophies. For example, DHH just argued that Rails' all- in-one package is still a huge value add today, even though it doesn't get written about as much as it did a decade ago ([https://www.quora.com/What- makes-Rails-a-framework-worth-lea...](https://www.quora.com/What-makes-Rails- a-framework-worth-learning-in-2017/answer/David-Heinemeier-Hansson?srid=tfS)). It's possible that Scala's value add is as good as it once was, but the people who found that value add useful have long since stopped blogging about it.

I haven't used Scala that much. I like that it has a repl, I like immutability (which should be nice with Shenandoah GC), I like the fact that I can make a basic POJO (case class) without writing a novel of private fields, getters, setters, hash code, and equals. Scala definitely has some great parts that I wish Java had. Scala also has some hell that can make it harder to reason about (gratuitous operator overloading, implicits [http://yz.mit.edu/wp/true- scala-complexity/](http://yz.mit.edu/wp/true-scala-complexity/)).

Scala also came onto the scene at a time when Java didn't look so hot. Java 5/6 era Java (2004 & 2006) just didn't support the cool FP stuff that Scala did. Java 7 didn't come out until 2011 and still didn't have lambdas. It was 2014 before Java got a lambda. So Scala was this new language that ran on the JVM that had features! But maybe people didn't want all the features, but really only wanted a few of them like lambdas, streams, and the ability to make simple POJOs/case classes (which is still missing in Java, though things like [http://immutables.github.io/](http://immutables.github.io/) can help). I'm sure that there are many other reasons to use Scala. I'm not trying to argue anyone away from a language they enjoy using. The point I'm trying to make is that for many people, they might have chosen Scala for some of these simpler features that now mostly exist in Java. Other people might have been enamored with how productive that Scala made them at first and later decided that they were creating things that were harder to debug or for others to read and understand. Still others might not have realized that everything is terrible and there's no amazing new technology that's going to make them 100x happier than they used to be when they actually write real programs. Don't underestimate that last bit. Scala's been around and has plenty of people who have used it and not created anything in a shorter amount of time or more reliably than they had in Java, Python, or whatnot. . .but don't yet realize that everything is terrible. I'm not saying that languages don't matter. I think they do. Still, it's hard to find something that doesn't have huge terrible portions that will drive you nuts on occasion.

Scala isn't as shiny and new as it once was. A new language is always awesome before you have to debug what you write in it. Java 8 has implemented a lot of what people thought was missing from Java. People have dulled on "magic" (really just harder to follow code) that might be hard to discover how it works rather than easy-to-follow code. That doesn't mean Scala is terrible or anything, but it's advantage over Java is probably smaller for people who want some basic FP and the zeitgeist seems to be moving against languages that are more implicit or dynamic (regardless of whether that's happening in terms of LOC).

<comment><USER84> Not following Java very closely and using Scala as a better Java. Is there hope to get case-class POJOs in Java itself?

<comment><USER24> Project Lombok already does that, you should check it out: [https://projectlombok.org/](https://projectlombok.org/)</comment></comment></comment></comment></comment>


JavaScript particle simulator - <AUTHOR> http://www.cake23.de/fmx/turing-fluid-particle-projection-feedback.html <comment><USER2> If you liked this, Chrome Experiments is filled with particle examples: [http://www.chromeexperiments.com/search/results.html?q=parti...](http://www.chromeexperiments.com/search/results.html?q=particles)

Three.js also has some pretty nice to follow particles samples:

[http://threejs.org/examples/#webgl_particles_random](http://threejs.org/examples/#webgl_particles_random)

[http://threejs.org/examples/#webgl_particles_sprites](http://threejs.org/examples/#webgl_particles_sprites)

[http://threejs.org/examples/#webgl_buffergeometry_particles](http://threejs.org/examples/#webgl_buffergeometry_particles)

</comment><comment><USER3> The frame rate is incredible given the number of particles. JavaScript interpreters really have come a long way. The frame rate for JS particle simulation beats the frame rate you get when you tell a browser to append content, which is usually native C/C++ optimized to death.

To the author: great work. It looked very much alive on my screen when I first loaded the page.

<comment><USER4> It's not really JS, shaders are doing all the heavy lifting.

<comment><USER5> Could you explain what's really going on here. What part is JS responsible for and how is native code being used? Thanks.

EDIT: I assume the "native-code" part is something like webgl?

<comment><USER6> WebGL is just a JavaScript API specification that exposes an OpenGL-like interface to scripts running within a webpage. The calls that your JavaScript makes to WebGL functions are translated behind the scenes to actual OpenGL calls (although, it doesn't have to be opengl, i think IE uses directx under the hood). Both opengl and directx are API interfaces that allow you to talk to graphics hardware.

Graphics hardware is incredibly fast and programmable (via shaders), and now that WebGL is part of the standard, Javascript programs can actually use the hardware's capabilities. What we see in a lot of this demos is not the javascript interpreter being fast. Although chrome's V8 actually _is_ fast (compared to other js implementations at least), most of the work is being done by the video card.

<comment><USER7> Firefox and Safari JS compilers are actually fast too. Even faster than V8 in some cases.

For example, I was surprised to find out recently that Firefox 25 is smoother and faster nowadays than Chrome on Mac Os X when running my interactive geometry genereator that is based on javascript/canvas ([http://GeoKone.NET](http://GeoKone.NET)).

</comment></comment></comment></comment></comment><comment><USER8> Does anyone have the theoretical description of what is happening? I'm curious about the fractal patterns being generated and the increasing in entropy and the that results in a catastrophic failure of the stable system. Is this some kind of chaotic system or is just an force field being applied on the particules.

<comment><USER9> half a million particles are rendered to a texture, which is then blurred, and the gradients are used to update the velocity of the particles in a feedback loop. There's no direct interaction between individual particles. There are two words to describe the haphazard in the behavior. Use Google or Wikipedia to learn about "dissipative systems" and "stigmergy".

</comment></comment><comment><USER10> This is beautiful, after watching I feel like I finally understand how the universe developed structure after the big bang.

</comment><comment><USER11> I would love to see a choice of initial conditions, one of which being a couple 'galaxies' of particles on a collision course.

Also, a way to reset the simulation without reloading the page would be nice.

<comment><USER12> Galaxies would require coupling of the particles, interactions through gravity... this would kill the efficiency of the solver. N-Particle simulations are always O(N^2) (or more).

<comment><USER13> Barnes-Hut is O(n log n) [http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation](http://en.wikipedia.org/wiki/Barnes%E2%80%93Hut_simulation)

<comment><USER12> Yes, once you start cutting off long range effects you can improve on the strict O(N^2) limitations.

<comment><USER14> It's not cutting off. It's replacing many long-range effects with a single one weighted more (and done it carefully so that the floating-point error is literally smaller than you could tell).

There's even better methods that take O(n) time, like the fast multipole expansion ones.

<comment><USER15> Btw this goes into numerical analysis, and O(-) is important but so is error convergence. I imagine these big-O figures are for a constant error, but I figure the asymptotic may change behavior as the other parameter changes.

</comment></comment></comment></comment></comment></comment><comment><USER16> The presentation this is from is at [http://www.cake23.de/fmx/](http://www.cake23.de/fmx/) \- there's a lot more good stuff inside than just this.

</comment><comment><USER17> Y U NO SUPPORT OES_texture_float_linear?

Using Version 31.0.1650.57 m Google Chrome is up to date

<comment><USER18> It's not a friend of Safari 7 with WebGL enabled, either.

<comment><USER19> It works fine in Safari 6, although ~30% slower than Chrome and Firefox (which run at 20-30 FPS, 2012 MBA, Intel HD4000).

It complains about the lack of an OpenGL extension, but it looks fine.

</comment></comment></comment><comment><USER20> I find this infinitely more interesting than the recent "X in 2.3 lines of JS" trend lately.

<comment><USER21> Oh come on, the ray tracer was really neat.

</comment></comment><comment><USER22> So how long do I have to wait to see it go back to it's initial position? (Theoretically...)

</comment><comment><USER9> I'm the original author of this little WebGL experiment and i want to try to answer some questions that came up here.

1) implementation there's quite some boilerplate in JS to set up all the textures and the main animation loop, but if you look closely the CPU is mostly idle and the "heavy lifting" is all done on the GPU by several shader programs. There are no libraries used and you can take a copy of the html file and simply start by breaking things apart. For the massive speed I'm updating the particle data with a clever fragment shader trick that i've learned from [https://twitter.com/BlurSpline/status/161806273602519040](https://twitter.com/BlurSpline/status/161806273602519040) And in a DIY fashion, I've mashed this up with my own texture feedback loop. The main idea is that the particle positions (and the velocity vectors too, each 2D only) are stored in a texture's rgba values (float32). So updating the particles data is in fact a render process of a quad in one draw call. Then I had also rendered the particles to another texture to sum up the "density" of the primitive 1 pixel point projections.

2) complexity when it comes to the mere particle count, the complexity really is O(n), but there's a wee bit more to it. The projection of the particles to the framebufferobject or the screen is the most costly in this setup and it's fillrate-limited by the graphics card. There's a noticeable difference when the particles are evenly distributed or when they overlap, but it must stay in the O(n) realm i suppose. Then there's another texture feedback loop system that is also directly dependent on the pixel count. The particles are stored in a 1024x512 pixels wide texture and the hidden texture feedback layer is also of that size, but it could differ too. There is absolutely no direct interaction between any two particles here. I project the particles to a density texture that is then diffused with an optimized two-pass Gaussian blur calculation and several resolution reduction steps. All the textures from the different steps are available as in put sampler to the shader programs, in particular "fs-advance" for the Turing patterns and the density projection (hey there, the blue channel is unused ^^) and "fs-move-particles" where i simply grab the gradient from the diffused density to update the particle's velocity vector and do the verlet integration.

The concepts used here also have names - just ask google or wikipedia for "dissipative systems/structures" and "stigmergy".

3) the fluid simulation code is not by me! Evgeny Demidov is the original author of the WebGL shaders for that: [http://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm](http://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm) I'm only adding to the current advection matrix

4) code size this could possibly fit into a 4k demo but i have no interest in that kind of challenge. i rather like to share something that is easily readable by others.

cheers!

<comment><USER23> This is really very impressive and thanks for sharing!

How many single particles are visible at every moment? Would it be possible to control the movement of the particles by the fluid field to form predefined shapes? to make them cluster into predefined (even moving) areas?

For some time now, i wonder if it would be possible to visualize some population statistics (think the percentile wealth distribution f.e. ;) by using some thing like this and make every single person "visible" within the statistic.

I believe it would make many "distributions" more intuitively understandable. Imagine some several thousand single "very wealthy" entities contrasted by several thousands or millions of "average" entities ;)

Obviously such interactive diagrams easily hit (hardware/software) limits, but even if displayed with some mapping like 1 point equals several (hundreds/thousands) real world entities, i think such display of magnitude in the real world would be very engaging.

Thanks again.

<comment><USER9> 1024x512 = 524288, that's over half a million and they're all visible. So far, they don't carry more individual properties than a position and a motion vector, but i could easily imagine to add another texture for that, and at some point i will also go for more life-like entities with adjustable distributions of status and needs values too, maybe to model behavior in a dynamic system of hunters and gatherers, you know. Give them very basic intelligence, intents, and planning. I had also thought of using a physics simulation for a skeleton model and neural nets for sensors and actuators. But I'm drifting away and I'm helpless in god-mode. Statistics is computationally heavy and i won't add anything like that too soon. It is and will be an abstract cat toy.

</comment></comment></comment><comment><USER24> How is this made?

It's pretty slow on my computer. Would ASM.js work better?

<comment><USER25> I'm getting 15 FPS in Chrome on my Surface Pro.

It uses OpenGL ES it seems, doesn't work in IE 11.

Edit: It would be interesting to know if this would perform better using WebGL and running it in IE 11, anyone has any thoughts on that?

<comment><USER26> 60fps (cap I think) on Firefox 25 on i5 desktop.

<comment><USER19> It's GPU-, not CPU bound.

<comment><USER26> Yeah I assumed this when I noticed even the Retina laptops with the i7s weren't doing as well. I have an Nvidia GTX 560 Ti which must be doing most of the work.

</comment></comment></comment></comment></comment><comment><USER27> Yes, but how many lines of javascript? It seems that's the metric above all metrics lately.

</comment><comment><USER28> but is it done in 30 lines of javascript? (i checked, no)

</comment><comment><USER29> Took me a long time to notice that my cursor movements were injecting disturbances into the fluid. What physical laws govern these points, and how is the cursor perturbing them?

<comment><USER29> Also, why is there a bias towards clockwise orbits in the first few seconds? Is there some asymmetry in the physics?

</comment></comment><comment><USER30> I don't think that's how particles work?

<comment><USER31> Yeah, it's pretty, but I'd like to see some explanation of what exactly is being simulated here.

</comment></comment><comment><USER32> is there anything detailing the maths/programming techniques behind this? can anyone confirm whether this is Barnes-Hut?

I've had a look here: [http://creativejs.com/2013/11/coupled-turing-pattern- and-219...](http://creativejs.com/2013/11/coupled-turing-pattern- and-219-particles/)

but there's no details on the specifics

<comment><USER9> it's not Barnes-Hut, but good tip!

</comment></comment><comment><USER33> Meh. U no support my 6 year old MacBook with crappy integrated graphics? Nothing on Safari 6.1, Firefox 25, Chrome 31..

</comment><comment><USER34> Cute, although not the best performance.

It'd be nice if the color gradually changed.

<comment><USER35> It looked fine to me, and the performance is a factor of your hardware. Get a faster computer.

</comment></comment><comment><USER36> How do you even begin to write something like this?

</comment><comment><USER37> Maybe we're written in 30 lines of javascript, too. You can get - to us - surprisingly and beautiful complexity from simple rules.

</comment><comment><USER38> Is this doing anything smarter than brute force and having the graphics primitives do the heavy lifting?

</comment><comment><USER39> Man I thought we were done with "Look at this 1998 era screen saver I made with webgl"

</comment><comment><USER40> It seems like the ensemble heats up. Could it get a little energy dissipation?

</comment><comment><USER41> Black screen Chrome 31 OSX

<comment><USER19> Works fine here. OS X 10.8

</comment></comment><comment><AUTHOR> To be honest, I would love to play a game out of this.

<comment><USER42> The much beloved Plasma Pong for older versions of Windows can still be found on the 'net. It did something similar, and I spent quite some time playing in its sandbox.

</comment></comment><comment><USER43> In how many lines?

</comment><comment><USER44> No mobile!

<comment><USER45> you need a better browser

<comment><USER44> Chrome on iPad?

</comment></comment></comment><comment><USER46> Does not work.

</comment><comment><USER47> Awesome!

</comment><comment><USER48> I will never get tired of seeing these kinds of posts on HN.

<comment><USER49> I agree. Does anyone know of a website that is just people posting really cool, short code snippets? Things like "Here is a checkers AI in 50 lines of Python" or "Here is a Neural Network in 30 lines of Perl".

<comment><USER50> [http://www.reddit.com/r/tinycode](http://www.reddit.com/r/tinycode)

<comment><USER49> This is exactly what I was looking for, thanks a lot! So much for being productive tonight.

</comment></comment></comment></comment><comment><USER35> Since a load of unfeeling morons have taken over HN, let me say for them that this was amazing. Thank you.

I really _can_ _not_ _wait_ until there is some new community to which these unemotional sociopaths can wander.

<comment><USER44> Beautiful antisocial irony.

I applaud you good sir or madam for your wit.</comment></comment>


Android 2.3 Platform Highlights | Android Developers - <AUTHOR> http://d.android.com/sdk/android-2.3-highlights.html <comment><USER2> I want it just for the sexy improved keyboard. Geesh!

<comment><USER3> Try SwiftKey - it blows away every other soft keyboard I've ever used elsewhere.

</comment></comment><comment><USER4> Does it have a sound api that works well this time ?</comment>


Ask HN: Where to find people to code together with? - <AUTHOR> I wan't to pair with someone to build something together to expand our skills and work in a team.
In the past i have done a few side projects but nothing big and the problem i have is most of the stuff i start i don't finish so i think this would help me a lot.
Are there any communities that offer what i'm looking for? <comment><USER2> We have this Great event Here in Milan called Open Source Saturday.

Roughly once a month we meet and we start a brief round table where whoever propose project he would like to work during the day, then we pair up and each pair (or triplets) works together at whichever project they have decided.

After lunch and before to leave we communicate to the other the "successes" of the day which can be either commits, PR, learn a new thing or just had fun with friends.

Goal of the day is to contribute to open source, sometimes we succeed done other times we just have fun and learn new things.

You could start a similar events in your area...

<comment><USER3> Great idea! Good for you guys!

</comment></comment><comment><USER4> Hey what are your specific skillset and how long have you been coding, I'm willing to pair with someone and work on something if it's interesting enough. I work on side projects in my free time and I work full time as a front-end engineer used to be full-stack.

<comment><AUTHOR> Lately i have been developing with Node.js/Express and React+Redux with rxjs. I also know Rails, some React Native, Java.

If you are interested send me a message and we can talk.

<comment><USER4> I can't send you a direct message on here visit www.udo.com.ng and send me a message from there :)

</comment></comment></comment><comment><USER5> [https://github.com/freeciv/freeciv-web](https://github.com/freeciv/freeciv- web)</comment>


Salvator Mundi and the unreality of the art market - <AUTHOR> https://www.the-tls.co.uk/articles/public/salvator-mundi-da-vinci-art/ <comment><USER2> It's not just the art market, though. The numbers are absurd in the fine art market, since it's a place where rich people go to compete with each other in games the rest of us don't get to play.

But eBay is full of sci-fi memorabilia with certificates of authenticity. A uniform actually worn by Patrick Stewart on screen sells for more than one that was made for him but not worn, which sells for more than a copy made with the same materials. You might actually be able to wear the latter, but the first two would just be set out for display, like the Mona Lisa.

That's a game we can all play, and while I'm not really much into it, I am proud of my author-signed Klingon Dictionary for no good reason -- especially since I never even look at it. It's weird watching hundreds of millions of dollars exchange hands for trinkets, but when you're talking about multi- billionaires, it doesn't really surprise me that they would similarly want to own truly one-of-a-kind things with a poorly-defined "authenticity".

<comment><USER3> I have a running debate with one of my friends about the future outlook of these markets. We both agree that perfect replication of many physical collectibles (e.g. mtg cards, comic books) will become possible over the next few decades. My belief is that this will cause authentic values to decline. His belief is that this will cause authentic values - confirmed by certificates and the like - to skyrocket. I still prefer my position (and it's fed into a growing sense of anti-materialism) but truthfully could foresee either outcome.

<comment><USER4> [https://archive.archaeology.org/online/features/hoaxes/intro...](https://archive.archaeology.org/online/features/hoaxes/intro.html)

The archaeology community has been dealing with this for years, and supplied this interesting read.

The art market, though, I assume is mostly money laundering.

</comment></comment></comment><comment><USER5> The cheat code:

— buy painting for $5 million

— have a museum value it at $15 million a few years later

— donate painting

— write off $15 million in taxes for a charitable contribution

Clearly the museums have an incentive to fudge the numbers for rich donors.

<comment><USER6> Yes, a museum director is fundamentally a _tax guy._ They're not paying for the work that gets "donated," so a museum director is a _negotiable third party_ who is highly willing to appraise works at values the Donor suggests.

The incentive for the Museum to inflate the value of the work that gets donated to them is inflating the supposed value of their holdings. The incentive for the Donor is tax evasion.

OH WAIT I meant "tax avoidance."

<comment><USER5> It gets even crazier — there are people literally buying new paintings at higher prices to inflate the value of existing holdings. So let's say you buy 3 Vassarely's @ $200k each (or insert semi-hot artist here). You wait 4 years and have someone else buy a 4th Vassarely piece for 3x that price point. Now you use the inflated value for that single piece as a comp for the other 3 pieces that will then be donated. Art market reps basically find ways to facilitate these types of things.

This is why you always see wings of museums named after rich folks.

</comment></comment></comment><comment><USER7> Fine art is also the most efficient way to launder money.

The reason for the rapid increase in value is completely inscrutable to regulators or the IRS, so it is the perfect tool of international financial fraud.

<comment><USER8> fraud is one of it but it's also a extremely high density store of value, if world war 111 happens it's easier to take your da vinci knowing when the dust settles it'll have value than 100 bars of gold</comment></comment>