joostdevries

Being able to take an instance Person and make it be an Employee without changes to the Person class definitely sounds like ad hoc polymorphism. In Scala the equivalent of Haskells type classes is implicits though. Not traits. I do wonder if this 'extension interface implementation' feature would support the same inferencing that type classes in Haskell and implicits in Scala do. So that might be a difference.

Interesting, the new type IAsyncEnumerable is like an Observable. But it's pull instead of push. Ie it supports backpressure like the Reactive Streams [1] standard in the JVM world. I seem to recall that Erik Meijer had some strong opinions when that standard was forming on backpressure and anything that's not purely push based.

Personally as a developer I really like having the choice whether to buffer in one place in my system (using a persistent queue f.i.) and have the rest of the system cooperate in tandem without running out of memory f.i. Or to choose to ignore elements when stuff is just going to fast. Etc. I feel more in control of the behaviour under load of my system.

I guess Lightbend was onto something when they took the old EAI notion of backpressure (as f.i. described in Gregor Hohpes book) and implemented it in stream processing and started an interoperability standard around it.

[1] http://www.reactive-streams.org/

"green eyed monster" it's hard to discuss the merits of these old and extremely influential texts. Some texts are so foundational to a language that even their mistakes have gotten imbued with beauty. In my native language, Dutch, that's the case f.i. with our equivalent of the King James bible. There are a lot of phrases in there that don't make sense because they're errors of translation. But still they carry a stately splendour for a lot of people. Perhaps that's also the case with Shakespeare. Basically by now it's beautiful because it's so much like Shakespeare. :-)

I hear you.

In my experience with quite a few Scala project with mixed teams it's not a problem though.

You just maintain some shared culture of "don't do X if not absolutely necessary". You need that for any language. In this case it's: don't do typelevel tricks if you can help it. And it turns out that 99.9 % of non-framework code doesn't need it. And the large majority of devs are fine with writing clear code.

Then there are some smart devs that are at a stage of personal development where they are intrigued with typelevel tricks. I've only had one colleague who didn't wasn't open to the "hey, that's not really necessary there. Let's not add complexity if we can help it" type of code review comment.

To each his own. But for the teams I've worked with Scala was the typed-FP-on-the-JVM lets-get-shit-done language.

That's a result of the Curry Howard Lambek isomorphism. So I'm afraid it's not a new rule. :-)

That reminds me of how, back in university, a mate said to me over beers: "Happiness is the derivative of well being"

He's a professor of statistical econometrics now.

What are the issues you're facing with RabbitMQ? I'm about to start a new project and we still have choice which queueing to use...

I love using Scala on the server and Typescript in the browser. And adjusting ts type definitions by hand gets tiresome very quickly. So I look forward to trying this out.

No it isn't http://www.slideshare.net/yoozd/union-types-and-literal-sing...

It's funny to see that singleton types are within the highest level: 'expert'. While in Typescript they're, together with union types, the most intuïtive thing ever. I guess that's because to express them in a language that doesn't have native support requires advanced deftness in typelevel programming. Like f.i. implementing them yourself in Scala 2.x. So I expect the coolness factor of singleton types and union types to fall precipitously as soon as Scala 3.x/Dotty becomes prevalent. They'll be 'just' a powerful feature that everybody understands and uses all the time.

There's Async Await. Which makes asynchronous code look like regular blocking code. But the calling code needs to know about it.

I recognise your concern: asynchronicity is infectious if it's manifested as monads. Which sucks. Client code needs to know whether the code it is calling is blocking or asynchronous.

Maybe effect systems can trace through code whether it is 'infected' with blockingness. Without any change showing in the intermediary source code. The blockingness/non-blockingness only manifesting itself at the top of the call graph.

Have you heard any of his presentations on the new compiler architecture?

I'm incredibly impressed with the stewardship of Scala: they did a thorough assessment of the strengths and weaknesses of language and compiler and are working on a complete refoundation of the language semantics and a rewrite of the compiler while also steadily progressing along a multi year roadmap for the current compiler.

Compilers that have a language service api are awesome. The Typescript compiler does and it makes for high quality low latency refactoring, code completion, show expression type etc across ediors and IDEs. Since my other day to day language is Scala I was glad to find out that the upcoming Dotty Scala compiler will also feature a language service api. Yay.

This article is the lowest form of FUD.

Java has been sloooowly adding features that Scala championed in the JVM world; lambdas and type inference within them in Java 8, REPL in Java 9, partial cases clases in Java 10 (yes to the syntactic sugar, no to the ADT semantics and pattern matching). Adding those features underscores the validity of Scalas vision. But if you've experienced the real thing Java is just too little too late.

Good luck waiting for hobbled cases class for the next 3 to 4 years. By the time Java has those the rest of the world will be accustomed to union types and literal types.

Good point. I guess there's more that should be a shared commonly funded resource: probably the core engine.

Sounds like the Docker container format should be split of into an independent foundation. Because everybody wants to use it but there's no money to be made of it. Then companies can compete on how to run Docker in production.

That Elm talk is really interesting. Tx.

When it comes to Monad et al I'm reminded of this talk by Gilad Bracha. He points out that the function names and type names that stem from category theory are not very good at communicating their intent in programming. (my words) Monad could be named Flatmappable f.i. 'unit' and 'bind' can have more intuïtive names as well.

At the moment I get the impression that as Scala is becoming a safe and productive and widely used tool there are developers moving to more Haskell like pastures within Scala. Perhaps because that kind of programming is required for some specific problems. But quite likely as well because they hope that it will make them stand out as smarter programmers.

Some people may remember the so called "Peters principle". Informally it states that people get promoted until they've reached their level of incompetence.

Similarly some smart developers tend to increase the complexity of their code to keep themselves amused until they're struggling to understand it themselves. Joosts principle. :-)

Edit: the link to the talk https://www.infoq.com/presentations/functional-pros-cons

From what I hear the JVM still has a funded team at Oracle. It's Java EE that has been put in the fridge. See fi this article on the upcoming Graal vm: https://medium.com/@octskyward/graal-truffle-134d8f28fb69#.9...

For posterity's sake: I just noticed this thorough comparison between Akka and Orleans from the Akka team. [1]

https://github.com/akka/akka-meta/blob/master/ComparisonWith...

I myself am mostly aquainted with Akka for Scala. So I was wondering what different design decisions they made, if any. After all a second implementation of a framework is often better than the first.

They do go into that in the research paper [1].

"Actor platforms such as Erlang [3] and Akka [2] are a step forward in simplifying distributed system programming. However, they still burden developers with many distributed system complexities because of the relatively low level of provided abstractions and system services. The key challenges are the need to manage the lifecycle of actors in the application code and deal with inherent distributed races, the responsibility to handl e failures and recovery of actors , the placement of actors, and thus distributed resource management. To build a correct solution to such problems in the application, the developer must be a distributed systems expert. To avoid these complexities, we built the Orleans programming model and runtime, which raises the level of the actor abstraction."

It's an interesting question how hard it would be to offer such a often-good-enough option in Akka for the cases when you don't have the need or the time or the team to develop a custom distributed computing model.

Edit: maybe Lagom is meant to fit that space. I think it's wider in scope than 'easy actors' though.

..and it's flat instead of nesting.

I'm a static types kindaguy. So I've rewritten some of this code using Typescript to see what that looks like.

https://github.com/joost-de-vries/typescript-ramda/blob/mast...

On second thought: I guess Async Await are like a `do` notation specifically for Promises...

I was recently thinking while working with ES6 Promises that I liked to have something equivalent to Haskells `do` notation. Or Scalas `for` comprehension.

Does something like that exist?

If not maybe I should try Kleislis instead. But I'd like my code to be accessible for my colleagues. And it's my rule of thumb that I try not to use point free constructions (like Kleislis) because a lot of colleagues will no longer understand my code easily.

I use Slick to access Postgres and it does support postgres window functions: https://github.com/tminglei/slick-pg#details

These big companies don't like uncertainty in their IT platform though. And this apparent lack of commitment to Java EE without any communication could scare them away.

We can only speculate what's going on at Oracle. Some options come to mind: 1) the JCP is moving too slowly to keep up with the changing IT landscape 2) Oracle no longer sees benefit in standard APIs with competing implementations and interoperability. Maybe it's eyeing enviously Salesforces cloud lockin...

I prefer to use functional frameworks. They 1) express the sql with map, flatmap, filter, groupBy etc functions 2) use classes that are equivalent to tuples.

Since I develop in Scala both are very intuïtive to write.

Apparently Linq for F# is really good as well. As someone else mentioned in a comment.

I get a programming interface that doesn't attempt to hide sql and still my code is fully typed. And it's really easy to make your query logic modular: make the sql fragment a function that you can call. Like any other code you reuse.

I can't think of an advantage of ORM over this functional approach. Apart from ORM being more well known.

As a Dutch citizen I very much feel kinship with people who happen to be from the other founding countries D, F, B, L, I. I speak their languages, I know their typical strengths and foibles, I've visited their cities, I know their history. We've been together for 70 stable years. The ministers of those countries are convening right now. And I very much agree with the words of the German minister Steinmeier "that those countries won't let anybody take that union away from them".

I recently wrote an sbt plugin. And I found that sbt became much easier after learning the core concepts. The book 'Sbt in Action' explains it very well and also contains a great comparison of build tools; what they historically brought to the table.

As codablah said: the availability of type definitions is a major difference in ease of use. The other reason is that I can add a specialised frontend dev to the team and reasonably expect them to be able to work in Typescript.