Oh man, I would hate to be the speaker following up here. Hey guys... so uhh... I added another feature, the virtual inheritence monad! ... for my thesis
It sounds inappropriate, but John De Goes has the balls. You ain’t gonna see everyday someone speaking about problems of programming language you built your career upon.
It's been two years since this awesome talk. I would love to hear an updated view from John A. De Goes or like minded Scala thought leader. Kotlin has grown more popular since 2018. It now has a single FP enhancements library called Arrow. My question now is, how close can Kotlin get to Scala's features? If Kotlin offers enough of the benefits of mixing OO and FP, does that create an opportunity for Scala to evolve toward FP and deemphasize OO (if reducing OO makes Scala better)?
Caveat: I teach an undergrad Scala course, as well as a little Kotlin in another unit. I think the comparison to Kotlin was a bit misleading, given how heavily Android has promoted Kotlin. Of course the world's most popular mobile platform wading in was going to skew the market share figures. I think it also missed the USPs that Scala does have, and what's holding it back. Most developers don't see scalaz vs Cats discussions until quite deep into their development trajectory. They do hit every bump with sbt right from their first project. Usually, the escape-hatch that Scala enables FP but does not compel it, turns out to be very useful. Cross-compile to JS is also very useful, but painful to set up.
I didn't mean that as as harsh criticism as perhaps it's come across. It's all comparative. It's just that in this case the comparison is something even easier to set up. For instance in a Scala Play project, if you wish to enable CoffeeScript or another compile-to-js language at the client side, you can just drop in the appropriate sbt-web plugin. To enable scala.js, however, you need to split the project. I use it pretty often (most of the time), and it works exceptionally well once you've set it up -- I'm far from a critic -- but it does put the level of "fiddliness" for students up a small notch compared to the other client-side languages they're likely to consider in a web course I also teach.
Most scary is to remember operator overloading. Too many operators with combination of multiple operators.. If the person leave org.. very tough to understand the code.
"it's looking at what's working in the ecosystem and sucking those things up to keep people on Java, and this is a strategy that works very very well for big dominant language because they can give you JUST enough reason to stick with Java. They don't have to make it amazing. They don't have to make it clean, perfect, beautiful......." That's how the status quo crushes innovation and taking ideas from innovators who deserve more credits and recognition.
Try this tagline for a change: "Scala is an open source programming language that lets you choose the best possible approach for a variety of business needs, and helps you quickly write correct concise, easily scaleable, and safely modifiable code."
Except that’s not targeting any one specific pain point. Why would someone choose a language to solve a problem that requires you to make another choice?
So we have a group of people who really wanted Haskell and adopted Scala just because it was the closest thing they could find on the JVM. OOP and FP are frankly not at war, and from a software engineering viewpoint they complement each other well. I think the pure FP crowd made some cool (but not very accessible) libraries but ended up really doing a heck of a lot of damage to the Scala community because they did not understand and were unwilling to learn why Scala adopts a unity of both points of view. Now on the way out the door they are angry and want to do as much damage as possible. I am very much inspired by by Scala 3 as it is and I think it is the right direction.
Interesting talk. I wish John had made one point more clear: the comparison with other languages was not about PLs strengths, it was about Marketing. He makes a very good point that Scala's tagline can be improved a lot.
The reason why a programming language was created has no relationship with how it ends up being used. Industry uses programming languages as they see fit, and then they feed the resources to make them better at their use cases. This is how real-world engineering in programming languages work. Scala's tagline can be improved and it will, to represent what Scala is being used today: to build high-performance scalable systems in many different platforms, with access to a huge ecosystem of libraries.
No. The tag lines are just a marketing spin that describe the use cases it optimizes for, they don't describe what the language actually solves in the real-world. You can solve problems or address use cases without actually aiming at solving them specifically, but just by accident or taking a more general approach.
Oh come on. Looking at current taglines of several languages I conclude that 1) Rust has great marketing team (which is not an insult btw, if you're trying to make a language a product you better do a good job selling it) and 2) FP languages can use better Marketing consultants. Haskell: An advanced, purely functional programming language [Mostly descriptive, buzzword: "advanced"] OCaml: OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles ["Industrial strength": BASIC is industrial strength.] Scala: Scala combines object-oriented and functional programming in one concise, high-level language. Scala's static types help avoid bugs in complex applications, and its JVM and JavaScript runtimes let you build high-performance systems with easy access to huge ecosystems of libraries. [Lots of words. "let you build high-performance systems": no self respected language prevents you from doing so] Rust: Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety [Good stuff, highlights 2 rare qualities (although not unique). "blazingly fast": OK] Go: Go is an open source programming language that makes it easy to build simple, reliable, and efficient software ["Open Source": Probably needed in this context coming from Google. "makes it easy to build simple, reliable, and efficient software": every other language claims that as well, so why would I believe it?] PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. [Mostly descriptive] Dart: Dart helps you craft beautiful, high-quality experiences across all screens [...] Python: Python is a programming language that lets you work quickly and integrate systems more effectively [This is clever in that it plays with the perception that Python is easy to learn and you can hack scripts quickly. But it is arguably false after you cross certain complexity size and if you consider "total cost of ownership" over a project's lifetime] Ruby: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write. [Interesting phrase: It seems to describe the intentions of the creator: "focus on simplicity and productivity". It has no assessment as to wether the goal as achieved or not. " elegant syntax that is natural to read and easy to write.": not for me]
Spot on! After flirting with Scala due to the need to use Spark, I came to the conclusion that the surface of the language was too large to argue a switch from Java to Scala notwithstanding all the advantages of Scala. Having the language focused around FP makes sense: do one thing well.
Python and Spark: lots of serialization/deserialization. Expensive with large data sets. Though Java gives me the creeps, it is still my recommended approach for the enterprise
why dont you use Clojure then , its pure FP; oh but wait , you dont know who went after Scala; we went after Scala, we are the C++ programmers who hated JAVA, and Scala even looked like C ish .
I *love* Clojure but I wouldn't recommend it in the context of Apache Spark: there is hardly anyone using Clojure/Spark together (yes, you could do it and there is a package out there but without a lot of participation in the mailing list to which I am subscribed). I think Scala is vastly superior to C++ if one can afford the overhead. Having said all of this, I think there is room to refocus Scala around FP. Kotlin is not a bad choice if you like C++.
Ktolin is for sheeple who dont know how intellJ killed scala to make Ktolin a success, so those who dont care about whats right or wrong , be their guess , err i mean slaves
@@andresmoreno7947 "lots of serialization/deserialization" I believe this is much less of an issue (or maybe not an issue at all) now that Java/Scala/Kotlin and Python on Spark can share the same in-memory and on-disk binary format: Apache Arrow/Parquet. arrow.apache.org/
Very informative talk, sensible from both business and technical point of view. I found Scala to be confusing for newcomers, however it's is a springboard that brings people to FP community.
A lot of this talk made sense to me, although it did discourage me from continuing to learn Scala. I'm not sure if others see it this way, but I think the whole talk would have been more constructive without the drama queen attitude. A lot of comments about the strategies for Scala's growth are just opinions: for the most part, they seem pretty informed opinions, but they are opinions nonetheless. Maybe dropping the OO is a good idea, but is that necessary? The truth is that we don't have a model that describes e.g. why Python became so popular. We all have some opinions or guesses, but we don't know.
I'm sorry it discouraged you from learning Scala. Come back - we're really nice! :) I agree that the haskell-in-scala subcommunity can be pretty condescending, and it unfortunately makes Scala seem uninviting. I love scala, and I disagree with De Goes' polarizing stance here. Framing things as OO devs vs. FP devs seems artificial to me, and antithetical to Scala's role in the world of programming languages. Scala's raison d'etre, according to Odersky, was to combine OO and FP, using the strengths of each to complement the other - OO providing modularity around FP's expressiveness, clarity and reasonability. Odersky's talks are a much better introduction to scala, and I use his comments as my guide. Odersky has clearly been careful with the language's evolution to facilitate newcomers' advancement into FP, particularly those coming from Java (why it's on the JVM in the first place is my guess), and with Scala 3 he's reigning it in further to make FP even more accessible, for example by simplifying typeclasses. With Scala 3's exports he's moving the world of OO forward - gently eliminating the tendency to use inheritance by making composition just as easy to implement. Watch this talk by Odersky on Scala 3 - I think you'll find it more welcoming. ua-cam.com/video/Z0w_pITUTyU/v-deo.html
What a drama talk !! ... so many weak analogies and also with contradictions ... but anyway, an interesting talk for learning a couple of good things (like the Eta language)
I think one interesting question is: what would be the important differences between Eta and the idealized FP-Scala discussed in the talk? I'm not a Haskell programmer as yet, but I know a bit, so I'm curious about this point. If Eta satisfies the requirements (other than being new and rough around the edges), then I have to ask why further splinter the typesafe-FP ecosystem on the JVM? I have loved Scala for 3 years that I've used it off and on, but I can say that in the past few months, I seem to be following something of the trajectory mentioned in the talk: once you learn too much FP, you begin to see the issues with OO. Further, Eta/Haskell syntax is quite concise. Is there a reason to prefer the somewhat more Scala syntax? I'm going to keep on learning Haskell/Idris slowly while continuing on with Scala for some of my day work, and remain optimistic for Scala's future as suggested in the talk.
I'll also say that despite some of the community issues mentioned in the talk, I have at least found my interactions with the community to be very positive, and I have many, many people to thanks for their time in one form or another.
Re: Eta vs Scala. Scala has been known as a way to sort of onboard devs into FP ("Haskellator" as mentioned in the talk). Can it still be that, compared to Eta, even if it drops OO featuers? Is this enough of a reason to continue to exist? I don't think so. Then it would sort of be "Eta with training wheels", but it is something to consider and may at least be another point in favor of Scala FP.
I speak from my experience: Scala should build native (and browser) and stop focusing so much in the JVM. For a non-Java programmer JVM stinks. If your reach all the Java-leavers with JVM you are left with no one wanting to implement JVM In their backend. Why adding another layer of abstraction when other backend options don't have it? It makes no sense. The capitalization of interest based in usage of large companies is running off, you should make a major major leap in the language to make it desirable for programmers (loving programming experience) and manager (making more with less resources). FP has an already appeal for managers (and maybe programmers) programing stateless make your code less prone to errors (thus, more time and less money), is time to solve the others issues
Rather than focusing on language, it's better to focus on framework because frameworks are the solutions for business. Take Java and Kotlin which are riding on Android. Or Javascript and Node. For Scala one great framework is Akka which I think does concurrency in much better way than Java's Rx or similar Reactive framework. The job of the community is to apply these frameworks in real business applications. From there the language can better itself by listening to feedback instead of predicting the future or throu political powerplay.
What would help people learn Scalaz/Cats would be more books and professional instructional videos. It is embarrassing how few coherent resources there are. Doesn't help that many of the online resources are already out of date, as Scalaz/Cats change constantly
I doubt anything specific was cut, there are a couple of those little "fade cuts" throughout the presentation. His body position barely changed so maybe he was fiddling with slides or something very minor?
Scala 3 is not a different programming language because the fundamentals are the same. On top of that, all features, removals and additions will be reviewed by the Scala Improvement Process Committee (SIP Committee) in a rigorous review process. A new compiler is not a new language. Just have a look at the C++ community where both Clang and gcc are mainstream compilers, and the former was developed much more later than gcc.
I think this is a good point, and the opposing point in the talk was probably overstated. It sounds as though 2.14 and Scala 3.0 should essentially converge , maybe with some number of (hopefully minor) differences. However, I think the talk may actually be asserting that Scala 3 *should* be a different language than Scala 2, since ideally the hope (presented here) is to drop OO, which, I have to say, I largely agree with.
Thumbs up to this, but John does also have a point on things like macros-parts that aren’t in the language specification but have accrued a not-insignificant body of usage in the OSS ecosystem and industry are likely to have a real impact on the upgrade rate that concerns me.
We'll assess how big that cost will be when the prototype of macros in Dotty is finalized, but this is pretty much taken into account in the new design which is, to be honest with you, not so different with Scala Reflect in the large scheme of things. Also note that many things people used to do with macros, like the lazy macro in shapeless, for example, have been merged into the language and there will be baked in ways to do derivation in a saner and user-friendlier way.
Yeah, that's essentially what he wants: a Scala without sub typing and that looks pretty much FP oriented. I'm sorry to say this won't happen and that I don't agree with his thesis, which seems completely unrelated to the problems he points out and to the definition of industry that essentially anybody else has. Changing the fundamentals of the language is not on the table. The good thing is that if they want a subset of Scala that only uses the FP parts, they can enforce it thanks to the metaprogramming facilities and tools that Scala provides them. It's never been so easier.
scala.meta still has a *massive* problem of not being sufficiently steerable with types though. There's no way I can write a macro that will e.g. generate delegates/proxies based on the type info of some annotated member. There's a large class of problem that therefore can't be solved with scala.meta as it currently stands, and still requires macro paradise
Kotlin is widely regarded as very easy to use. Scala has an entrenched reputation of being arcane, fiddly, and hard to use from both a language perspective and a tooling perspective.
Jorge Vicente of course not, but that is an important dimension when you want to maximize problem solving while minimizing fighting your syntax and/or tooling. Never underestimate the ergonomic needs of the average developer because language adoption requires average developers en masse.
The ergonomics of a language are improved with tooling (and I believe that, in the Scala community, we're getting to a point where we'll have excellent tooling soon). The only benefit of being a simpler language is that tooling for it is easy to improve and ship. Of course, there's more cognitive overhead in Scala than, say, Go, but that's because fundamentally they tackle different problems.
Ironically, that "wide regard" didn't match my own experience of Kotlin. Day two of trying it on a new project I discovered that it's something of a frankenstinian monster - lots of bits that are good for their own use-cases, and look good in examples, but don't work so well together. Even trivial stuff like using Kotlin's property syntax to override an abstract getter from a parent class will fail. Try to make it lazily evaluated and it fails even harder, you end up having to fall back to standard Java syntax too soon and too often in far too many places.
@@Hoowwwww It won't (well didn't)... Seems like John crammed all the announced features into the Java 11 column. Should have read Java 11+, most likely.
i gave a thumbs up for mentioning Rustlang, since i went after the sexy multicore thread safe features of Rust. But for the rest left behind, all the best beating the dead horse; over the years with every release Scala insulted Genius men who came from platforms other than JVM, and now JVM itself is dieing, since Go took a first jab at JVM by having a GC without a VM and then Rust nailed it by not requiring any VM. WOW.
He is the one who causes political turbulence. He is a lot like Trump. The talk itself gave me an opportunity to think about some negative possibilities but I needed to put a huge of grain of salt. Scala has a great framework called Akka that John hates. With Akka, you can stand anywhere between OOP & FP and still can build a vastly concurrent and distributed system.
Scala is one of the worst languages I have come across. Why on earth would someone take on such unnecessary "functional" abstractions in the real world when you are faced with far greater concerns. The customer certainly doesn't care about the product being developed in a "functional" way. More importantly, the developer experience is absolute shit. It takes months of mentorship to successfully onboard a new developer onto the team such that they can begin being productive with the language. I almost threw up when reading about implicits! What a cluster fuck... Learn the fundamentals of Computer Science and Networking people. Don't waste your time being clever with these niche languages; you won't gain job security this way. With that said, I highly recommend looking into Golang as an alternative to Scala if your company is looking to migrate away. As far as I am concerned, you are introducing significantly unnecessary technical complexity if you introduce this god awful language to your organization's tech stack.
Most of the people working on these projects have already solved most of these "concerns" you're talking about, and they realise you can solve most of them (if not all) better with FP. Do you really think John as a CTO just fluffs around all day being unproductive in functional abstractions?
I am not going to burden (new) employees with learning a niche language when they could be far more productive and happier using something else. Go and Ruby come to mind. Functional abstractions belong in an undergraduate classroom, not in serious distributed systems. "can solve most of them (if not all) better with FP" - that makes zero sense. What do you mean by better?
What rubbish. Any developer worth their salt knows full well that different languages and paradigms are better suited and a more natural fit for different classes of problem - making them simpler in that context (just compare Hadoop map-reduce in native Java vs Spark) The FP paradigm is a much better fit for working with large data sets and immutability + pure functions offers a much nicer model than explicit locking/synchronisation for dealing with multi-threaded concurrent code. In a world where you can now buy single-die server processors with over 40 cores off the shelf, you can expect to run face-first into the wall of what your customers expect when they buy a shiny new server to scale your code and discover that you're at the wrong end of Amdahl's law, and it'll only get worse with climbing core counts (even mobiles come with 8 cores now) So... by all means... be mindful of what is "necessary" in the "real world". Just be honest with yourself with what that *actually* is though. Because from where I'm sitting it's about a very strong trend of increasing demand for data analytics and about exponentially growing CPU core counts.
My intention was not to hate on functional programming, I find it interesting academically! It's just that I think Scala is a horrible nasty language. Glad to see shit languages like this die quickly. Waste of human resources.
Java was shit so i went after Scala only to know after years of trying that its hopelessly useless, what a waste of my time, but it let me understand the value of Rust
Dear Mr De Goes, it is hypocritial to say that on the one hand FP programmers hate Scala because there are so many better ways to do things in Haskell, and on the other hand, that the OO Community needs to be sacrificed and Scala needs to focus entirely on FP. If you go that direction, the next logical step is for all the FP programmers to leave for Haskel anyway. Any visision of the future of Scala that does not include the *Entire* community including the OO people is narrow minded. Your industry goal of 'Write correct code, with type-safety, and JVM reuse' easily encompases totality of the Scala community's passion. There is no need to sacrifice or exclude anyone.
Apparently, John wanted to justify the title of his presentation so badly that he decided to distort facts a little bit. I did some research in 2016 and back then Scala had 5150 jobs, which was about 1/18x of Java. Now Scala has 6725 and is only 1/10x of Java. For comparison, PHP has only a little more than 14000 jobs, let that sink in. As for RedMonk and PYPL, they are hister-biased ratings favoring "new and hot" languages and I would not take them seriously, but even in PYPL Scala was #15 in 2016 and it's still #15. It seems that my old article is still quite relevant: appliedscala.com/blog/2016/scala-popularity/
Indeed. The data does not back up his thesis at all. I have not yet seen any data that justifies this whole mentality of "Kotlin is taking over Scala", quite the opposite.
Go transparently decides whether to use threads or processes and decides what to do for you. Scala's conciseness doesnt save complexity it just means you can write complex code with less lines.
Oh man, I would hate to be the speaker following up here. Hey guys... so uhh... I added another feature, the virtual inheritence monad! ... for my thesis
It sounds inappropriate, but John De Goes has the balls. You ain’t gonna see everyday someone speaking about problems of programming language you built your career upon.
Exactly.
It's been two years since this awesome talk. I would love to hear an updated view from John A. De Goes or like minded Scala thought leader.
Kotlin has grown more popular since 2018. It now has a single FP enhancements library called Arrow.
My question now is, how close can Kotlin get to Scala's features? If Kotlin offers enough of the benefits of mixing OO and FP,
does that create an opportunity for Scala to evolve toward FP and deemphasize OO (if reducing OO makes Scala better)?
Caveat: I teach an undergrad Scala course, as well as a little Kotlin in another unit. I think the comparison to Kotlin was a bit misleading, given how heavily Android has promoted Kotlin. Of course the world's most popular mobile platform wading in was going to skew the market share figures. I think it also missed the USPs that Scala does have, and what's holding it back. Most developers don't see scalaz vs Cats discussions until quite deep into their development trajectory. They do hit every bump with sbt right from their first project. Usually, the escape-hatch that Scala enables FP but does not compel it, turns out to be very useful. Cross-compile to JS is also very useful, but painful to set up.
I didn't mean that as as harsh criticism as perhaps it's come across. It's all comparative. It's just that in this case the comparison is something even easier to set up. For instance in a Scala Play project, if you wish to enable CoffeeScript or another compile-to-js language at the client side, you can just drop in the appropriate sbt-web plugin. To enable scala.js, however, you need to split the project. I use it pretty often (most of the time), and it works exceptionally well once you've set it up -- I'm far from a critic -- but it does put the level of "fiddliness" for students up a small notch compared to the other client-side languages they're likely to consider in a web course I also teach.
there is too much ceremony for getting a Scala web project up and running
Most scary is to remember operator overloading. Too many operators with combination of multiple operators..
If the person leave org.. very tough to understand the code.
Android only promoted Kotlin after it was already good.
Too many people see whatever happens around themselves as either "war" or "beauty contest" or both.
Good comprehensive talk that talks about the economy's impact on the language, the community and so much more
I sure would like to see an effect system in Scala.
"it's looking at what's working in the ecosystem and sucking those things up to keep people on Java, and this is a strategy that works very very well for big dominant language because they can give you JUST enough reason to stick with Java.
They don't have to make it amazing. They don't have to make it clean, perfect, beautiful......."
That's how the status quo crushes innovation and taking ideas from innovators who deserve more credits and recognition.
Try this tagline for a change:
"Scala is an open source programming language that lets you choose the best possible approach for a variety of business needs, and helps you quickly write correct concise, easily scaleable, and safely modifiable code."
Except that’s not targeting any one specific pain point. Why would someone choose a language to solve a problem that requires you to make another choice?
So we have a group of people who really wanted Haskell and adopted Scala just because it was the closest thing they could find on the JVM. OOP and FP are frankly not at war, and from a software engineering viewpoint they complement each other well. I think the pure FP crowd made some cool (but not very accessible) libraries but ended up really doing a heck of a lot of damage to the Scala community because they did not understand and were unwilling to learn why Scala adopts a unity of both points of view. Now on the way out the door they are angry and want to do as much damage as possible. I am very much inspired by by Scala 3 as it is and I think it is the right direction.
Interesting talk. I wish John had made one point more clear: the comparison with other languages was not about PLs strengths, it was about Marketing. He makes a very good point that Scala's tagline can be improved a lot.
No, that wasn’t the point. The tag lines aren’t just marketing spin, they capture pretty accurately what problems each language was designed to solve.
The reason why a programming language was created has no relationship with how it ends up being used. Industry uses programming languages as they see fit, and then they feed the resources to make them better at their use cases. This is how real-world engineering in programming languages work.
Scala's tagline can be improved and it will, to represent what Scala is being used today: to build high-performance scalable systems in many different platforms, with access to a huge ecosystem of libraries.
No. The tag lines are just a marketing spin that describe the use cases it optimizes for, they don't describe what the language actually solves in the real-world. You can solve problems or address use cases without actually aiming at solving them specifically, but just by accident or taking a more general approach.
Oh come on.
Looking at current taglines of several languages I conclude that 1) Rust has great marketing team (which is not an insult btw, if you're trying to make a language a product you better do a good job selling it) and 2) FP languages can use better Marketing consultants.
Haskell: An advanced, purely functional programming language
[Mostly descriptive, buzzword: "advanced"]
OCaml: OCaml is an industrial strength programming language supporting functional, imperative and object-oriented styles
["Industrial strength": BASIC is industrial strength.]
Scala: Scala combines object-oriented and functional programming in one concise, high-level language. Scala's static types help avoid bugs in complex applications, and its JVM and JavaScript runtimes let you build high-performance systems with easy access to huge ecosystems of libraries.
[Lots of words. "let you build high-performance systems": no self respected language prevents you from doing so]
Rust: Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety
[Good stuff, highlights 2 rare qualities (although not unique). "blazingly fast": OK]
Go: Go is an open source programming language that makes it easy to build simple, reliable, and efficient software
["Open Source": Probably needed in this context coming from Google. "makes it easy to build simple, reliable, and efficient software": every other language claims that as well, so why would I believe it?]
PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML.
[Mostly descriptive]
Dart: Dart helps you craft beautiful, high-quality experiences across all screens
[...]
Python: Python is a programming language that lets you work quickly and integrate systems more effectively
[This is clever in that it plays with the perception that Python is easy to learn and you can hack scripts quickly. But it is arguably false after you cross certain complexity size and if you consider "total cost of ownership" over a project's lifetime]
Ruby: A dynamic, open source programming language with a focus on simplicity and productivity. It has an elegant syntax that is natural to read and easy to write.
[Interesting phrase: It seems to describe the intentions of the creator: "focus on simplicity and productivity". It has no assessment as to wether the goal as achieved or not.
" elegant syntax that is natural to read and easy to write.": not for me]
Read again my comment, I'm not saying that it cannot be improved and that a marketing consultant would not be of use :)
very good and relevant observations. thanks.
Spot on! After flirting with Scala due to the need to use Spark, I came to the conclusion that the surface of the language was too large to argue a switch from Java to Scala notwithstanding all the advantages of Scala. Having the language focused around FP makes sense: do one thing well.
Python and Spark: lots of serialization/deserialization. Expensive with large data sets. Though Java gives me the creeps, it is still my recommended approach for the enterprise
why dont you use Clojure then , its pure FP; oh but wait , you dont know who went after Scala; we went after Scala, we are the C++ programmers who hated JAVA, and Scala even looked like C ish .
I *love* Clojure but I wouldn't recommend it in the context of Apache Spark: there is hardly anyone using Clojure/Spark together (yes, you could do it and there is a package out there but without a lot of participation in the mailing list to which I am subscribed).
I think Scala is vastly superior to C++ if one can afford the overhead. Having said all of this, I think there is room to refocus Scala around FP. Kotlin is not a bad choice if you like C++.
Ktolin is for sheeple who dont know how intellJ killed scala to make Ktolin a success, so those who dont care about whats right or wrong , be their guess , err i mean slaves
@@andresmoreno7947 "lots of serialization/deserialization" I believe this is much less of an issue (or maybe not an issue at all) now that Java/Scala/Kotlin and Python on Spark can share the same in-memory and on-disk binary format: Apache Arrow/Parquet.
arrow.apache.org/
Really great talk!
Very informative talk, sensible from both business and technical point of view.
I found Scala to be confusing for newcomers, however it's is a springboard that brings people to FP community.
I agree with several points, but concerning academia: I wonder if John knows how academic Haskell is (since that seems to be his pure FP ideal).
What a great man, I love this guys passion. I wish Scala all the best!
Great talk.
It's a shame Mark Hibberd wasn't on the list of notable Scala FP contributors who have left :p
A lot of this talk made sense to me, although it did discourage me from continuing to learn Scala. I'm not sure if others see it this way, but I think the whole talk would have been more constructive without the drama queen attitude. A lot of comments about the strategies for Scala's growth are just opinions: for the most part, they seem pretty informed opinions, but they are opinions nonetheless. Maybe dropping the OO is a good idea, but is that necessary? The truth is that we don't have a model that describes e.g. why Python became so popular. We all have some opinions or guesses, but we don't know.
Yeah. I could not get why "dropping OO" is a fix. His description of current problems were great, but he could not give a proper solution also.
There's always Clojure if you need the JVM
I'm sorry it discouraged you from learning Scala. Come back - we're really nice! :) I agree that the haskell-in-scala subcommunity can be pretty condescending, and it unfortunately makes Scala seem uninviting. I love scala, and I disagree with De Goes' polarizing stance here. Framing things as OO devs vs. FP devs seems artificial to me, and antithetical to Scala's role in the world of programming languages. Scala's raison d'etre, according to Odersky, was to combine OO and FP, using the strengths of each to complement the other - OO providing modularity around FP's expressiveness, clarity and reasonability. Odersky's talks are a much better introduction to scala, and I use his comments as my guide. Odersky has clearly been careful with the language's evolution to facilitate newcomers' advancement into FP, particularly those coming from Java (why it's on the JVM in the first place is my guess), and with Scala 3 he's reigning it in further to make FP even more accessible, for example by simplifying typeclasses. With Scala 3's exports he's moving the world of OO forward - gently eliminating the tendency to use inheritance by making composition just as easy to implement. Watch this talk by Odersky on Scala 3 - I think you'll find it more welcoming. ua-cam.com/video/Z0w_pITUTyU/v-deo.html
@@jakemiles999 I was thinking of learning scala but I now doubt.
What a drama talk !! ... so many weak analogies and also with contradictions ... but anyway, an interesting talk for learning a couple of good things (like the Eta language)
I only saw the last bit, but holy hell does he sound like a preacher. I do mean a literal preacher.
I think one interesting question is: what would be the important differences between Eta and the idealized FP-Scala discussed in the talk? I'm not a Haskell programmer as yet, but I know a bit, so I'm curious about this point. If Eta satisfies the requirements (other than being new and rough around the edges), then I have to ask why further splinter the typesafe-FP ecosystem on the JVM? I have loved Scala for 3 years that I've used it off and on, but I can say that in the past few months, I seem to be following something of the trajectory mentioned in the talk: once you learn too much FP, you begin to see the issues with OO. Further, Eta/Haskell syntax is quite concise. Is there a reason to prefer the somewhat more Scala syntax? I'm going to keep on learning Haskell/Idris slowly while continuing on with Scala for some of my day work, and remain optimistic for Scala's future as suggested in the talk.
I'll also say that despite some of the community issues mentioned in the talk, I have at least found my interactions with the community to be very positive, and I have many, many people to thanks for their time in one form or another.
Re: Eta vs Scala. Scala has been known as a way to sort of onboard devs into FP ("Haskellator" as mentioned in the talk). Can it still be that, compared to Eta, even if it drops OO featuers? Is this enough of a reason to continue to exist? I don't think so. Then it would sort of be "Eta with training wheels", but it is something to consider and may at least be another point in favor of Scala FP.
I now see the presenter (John) has already addressed this query on twitter: twitter.com/jdegoes/status/1017072420350406656?s=19
@@brandonbarker5448 Thank you for posting this!
Solid talk 👏
There should be a BEST FP way to solve hard production problems, and it should beat other language, that is the Survival game for Scala.
I speak from my experience: Scala should build native (and browser) and stop focusing so much in the JVM. For a non-Java programmer JVM stinks. If your reach all the Java-leavers with JVM you are left with no one wanting to implement JVM In their backend. Why adding another layer of abstraction when other backend options don't have it? It makes no sense. The capitalization of interest based in usage of large companies is running off, you should make a major major leap in the language to make it desirable for programmers (loving programming experience) and manager (making more with less resources). FP has an already appeal for managers (and maybe programmers) programing stateless make your code less prone to errors (thus, more time and less money), is time to solve the others issues
It is weird that there is not a single mention of Clojure which is already a rock solid pure FP language on the JVM.
Pure FP is the part you're wrong about there
John, and all pure FP evangelists focus on type driven development though he didn’t explicitly mention it. But obvious. !
Probably because it is inferior for FP compared to the other FP languages (Haskell, OCaml, F#, SML), and inferior as a Lisp to Common Lisp.
You forgot to add "in my opinion".
Nikolai Collushnikov hmm right ,Clojure could not become Scala even though it became popular way before Scala caught on
Rather than focusing on language, it's better to focus on framework because frameworks are the solutions for business. Take Java and Kotlin which are riding on Android. Or Javascript and Node. For Scala one great framework is Akka which I think does concurrency in much better way than Java's Rx or similar Reactive framework. The job of the community is to apply these frameworks in real business applications. From there the language can better itself by listening to feedback instead of predicting the future or throu political powerplay.
Hard to argue against Erlang for concurrent programming, though. If the requirement is to be on the JVM then, yes!
That Trophy has been secured by Rustlang since JVM platform sucks at tackling multicore programming.
When I think Scala, I think reactive. Maybe there could be a business benefit to approaching the market that way
Python is #3 on that TIOBE index as of Sept 2018, if history repeats itself Scala Devs are in luck ;)
What would help people learn Scalaz/Cats would be more books and professional instructional videos. It is embarrassing how few coherent resources there are. Doesn't help that many of the online resources are already out of date, as Scalaz/Cats change constantly
Not to mention the barrier to entry for newcomers and beginner programmers.
Who know what was cut around 25:56?
I doubt anything specific was cut, there are a couple of those little "fade cuts" throughout the presentation. His body position barely changed so maybe he was fiddling with slides or something very minor?
Scala 3 is not a different programming language because the fundamentals are the same. On top of that, all features, removals and additions will be reviewed by the Scala Improvement Process Committee (SIP Committee) in a rigorous review process.
A new compiler is not a new language. Just have a look at the C++ community where both Clang and gcc are mainstream compilers, and the former was developed much more later than gcc.
I think this is a good point, and the opposing point in the talk was probably overstated. It sounds as though 2.14 and Scala 3.0 should essentially converge , maybe with some number of (hopefully minor) differences. However, I think the talk may actually be asserting that Scala 3 *should* be a different language than Scala 2, since ideally the hope (presented here) is to drop OO, which, I have to say, I largely agree with.
Thumbs up to this, but John does also have a point on things like macros-parts that aren’t in the language specification but have accrued a not-insignificant body of usage in the OSS ecosystem and industry are likely to have a real impact on the upgrade rate that concerns me.
We'll assess how big that cost will be when the prototype of macros in Dotty is finalized, but this is pretty much taken into account in the new design which is, to be honest with you, not so different with Scala Reflect in the large scheme of things. Also note that many things people used to do with macros, like the lazy macro in shapeless, for example, have been merged into the language and there will be baked in ways to do derivation in a saner and user-friendlier way.
Yeah, that's essentially what he wants: a Scala without sub typing and that looks pretty much FP oriented. I'm sorry to say this won't happen and that I don't agree with his thesis, which seems completely unrelated to the problems he points out and to the definition of industry that essentially anybody else has. Changing the fundamentals of the language is not on the table.
The good thing is that if they want a subset of Scala that only uses the FP parts, they can enforce it thanks to the metaprogramming facilities and tools that Scala provides them. It's never been so easier.
scala.meta still has a *massive* problem of not being sufficiently steerable with types though. There's no way I can write a macro that will e.g. generate delegates/proxies based on the type info of some annotated member. There's a large class of problem that therefore can't be solved with scala.meta as it currently stands, and still requires macro paradise
so like his talk.
Discussion happening at www.reddit.com/r/scala/comments/8xreuv/keynote_the_last_hope_for_scalas_infinity_war/
Kotlin is widely regarded as very easy to use. Scala has an entrenched reputation of being arcane, fiddly, and hard to use from both a language perspective and a tooling perspective.
Go and Python widely regarded as very easy to use too. I don't think a programming language should be only judged by how easy to use is.
Jorge Vicente of course not, but that is an important dimension when you want to maximize problem solving while minimizing fighting your syntax and/or tooling. Never underestimate the ergonomic needs of the average developer because language adoption requires average developers en masse.
The ergonomics of a language are improved with tooling (and I believe that, in the Scala community, we're getting to a point where we'll have excellent tooling soon). The only benefit of being a simpler language is that tooling for it is easy to improve and ship. Of course, there's more cognitive overhead in Scala than, say, Go, but that's because fundamentally they tackle different problems.
Python is easy and then hard: one has to pay attention to write performant Python. Leaky abstractions strike again!
Ironically, that "wide regard" didn't match my own experience of Kotlin. Day two of trying it on a new project I discovered that it's something of a frankenstinian monster - lots of bits that are good for their own use-cases, and look good in examples, but don't work so well together. Even trivial stuff like using Kotlin's property syntax to override an abstract getter from a parent class will fail. Try to make it lazily evaluated and it fails even harder, you end up having to fall back to standard Java syntax too soon and too often in far too many places.
value type for java 11 ? i missed something ?
There's an initiative called Project Valhalla which is trying to bake in value types into the JVM.
Yes i know, but i didn't know it'll be released for Java 11, what's the source of this ?
@@Hoowwwww It won't (well didn't)... Seems like John crammed all the announced features into the Java 11 column. Should have read Java 11+, most likely.
What do you mean you can't profit off a programming language? This is excatly what Oracle and Jetbrains are doing.
Yes, you are right.
i gave a thumbs up for mentioning Rustlang, since i went after the sexy multicore thread safe features of Rust.
But for the rest left behind, all the best beating the dead horse; over the years with every release Scala insulted Genius men who came from platforms other than JVM, and now JVM itself is dieing, since Go took a first jab at JVM by having a GC without a VM and then Rust nailed it by not requiring any VM. WOW.
Who was the picture next to paulp?
soc.github.io/scala/departure
Am I the only one here who wants both FP and OO in one language? By OO i mean classes, and mutability and side effects.
He is the one who causes political turbulence. He is a lot like Trump. The talk itself gave me an opportunity to think about some negative possibilities but I needed to put a huge of grain of salt.
Scala has a great framework called Akka that John hates. With Akka, you can stand anywhere between OOP & FP and still can build a vastly concurrent and distributed system.
I don't believe Martin will listen to you. (Or to anybody.)
LOL, popular than the programming for kids.
Given how insanely ubiquitous Scratch is in schools now, any language being more popular than it is doing very well indeed.
he made sound like "engineering managers" and "CTO"s like him are the only important ppl. give me a break.
fuck scala 3 only zio !!!11!
Scala is one of the worst languages I have come across. Why on earth would someone take on such unnecessary "functional" abstractions in the real world when you are faced with far greater concerns. The customer certainly doesn't care about the product being developed in a "functional" way. More importantly, the developer experience is absolute shit. It takes months of mentorship to successfully onboard a new developer onto the team such that they can begin being productive with the language. I almost threw up when reading about implicits! What a cluster fuck...
Learn the fundamentals of Computer Science and Networking people. Don't waste your time being clever with these niche languages; you won't gain job security this way. With that said, I highly recommend looking into Golang as an alternative to Scala if your company is looking to migrate away. As far as I am concerned, you are introducing significantly unnecessary technical complexity if you introduce this god awful language to your organization's tech stack.
Most of the people working on these projects have already solved most of these "concerns" you're talking about, and they realise you can solve most of them (if not all) better with FP. Do you really think John as a CTO just fluffs around all day being unproductive in functional abstractions?
I am not going to burden (new) employees with learning a niche language when they could be far more productive and happier using something else. Go and Ruby come to mind. Functional abstractions belong in an undergraduate classroom, not in serious distributed systems.
"can solve most of them (if not all) better with FP" - that makes zero sense. What do you mean by better?
What rubbish. Any developer worth their salt knows full well that different languages and paradigms are better suited and a more natural fit for different classes of problem - making them simpler in that context (just compare Hadoop map-reduce in native Java vs Spark)
The FP paradigm is a much better fit for working with large data sets and immutability + pure functions offers a much nicer model than explicit locking/synchronisation for dealing with multi-threaded concurrent code. In a world where you can now buy single-die server processors with over 40 cores off the shelf, you can expect to run face-first into the wall of what your customers expect when they buy a shiny new server to scale your code and discover that you're at the wrong end of Amdahl's law, and it'll only get worse with climbing core counts (even mobiles come with 8 cores now)
So... by all means... be mindful of what is "necessary" in the "real world". Just be honest with yourself with what that *actually* is though. Because from where I'm sitting it's about a very strong trend of increasing demand for data analytics and about exponentially growing CPU core counts.
My intention was not to hate on functional programming, I find it interesting academically! It's just that I think Scala is a horrible nasty language.
Glad to see shit languages like this die quickly. Waste of human resources.
Java was shit so i went after Scala only to know after years of trying that its hopelessly useless, what a waste of my time, but it let me understand the value of Rust
shallow review, the author is a clown
Dear Mr De Goes, it is hypocritial to say that on the one hand FP programmers hate Scala because there are so many better ways to do things in Haskell, and on the other hand, that the OO Community needs to be sacrificed and Scala needs to focus entirely on FP. If you go that direction, the next logical step is for all the FP programmers to leave for Haskel anyway. Any visision of the future of Scala that does not include the *Entire* community including the OO people is narrow minded. Your industry goal of 'Write correct code, with type-safety, and JVM reuse' easily encompases totality of the Scala community's passion. There is no need to sacrifice or exclude anyone.
Is it possible that Mr. Do Goes' proposed solution is not to completely remove OO from Scala, but only to some how de-emphasize OO?
Apparently, John wanted to justify the title of his presentation so badly that he decided to distort facts a little bit. I did some research in 2016 and back then Scala had 5150 jobs, which was about 1/18x of Java. Now Scala has 6725 and is only 1/10x of Java. For comparison, PHP has only a little more than 14000 jobs, let that sink in. As for RedMonk and PYPL, they are hister-biased ratings favoring "new and hot" languages and I would not take them seriously, but even in PYPL Scala was #15 in 2016 and it's still #15. It seems that my old article is still quite relevant: appliedscala.com/blog/2016/scala-popularity/
Indeed. The data does not back up his thesis at all. I have not yet seen any data that justifies this whole mentality of "Kotlin is taking over Scala", quite the opposite.
may be you guys are reading biased articles that are harming you
Why is "simple" in Go's pitch a positive and useful statement while "concise" in Scala's is worthless and laughable?
Go transparently decides whether to use threads or processes and decides what to do for you. Scala's conciseness doesnt save complexity it just means you can write complex code with less lines.
Scala is convoluted. It's not the goal, it's the failure in attaining it.
yo lo if Scala is convoluted then what are C# and Typescript?
strongly disagree :)
Naftoli Gugenheim how other languages make Scala a different language? That is just making stuff up. Look, there is something worse! OK, who cares?