[deleted]
The Road to Scala 3
51–60 of 196 posts
Re: The Road to Scala 3
#52The way I look at modern Scala is a mix of Python and Java. Do it badly, and you end up with the unmaintainability of Python and the clunkiness of Java. Awful. Do it well, and you end up with the convenience and interactivity of Python and the typesafety, performance, and toolability of Java. This lets you implement your code quickly the first time, and have it run blazing fast on a hot JVM, with the compiler having…
> I’m personally very happy with my Python-like language with Python-like libraries, with static typing for maintainability, orders of magnitude better runtime performance, excellent parallelism and concurrency, one of the best compile-to-JS experiences in the world, and the best tooling (IDEs, profilers, monitoring, etc.) on the market.
Hey lihaoyi, completely agree with you on this. (Coming from someone who recently stopped writing scala).
That said, in my opinion, if you got to write “python-like scala” with static typing and hof on a regular basis, you should count yourself as one of the lucky ones. In the context of a diverse team, with interests and experiences ranging from Java to Js to python To all the way to Idris, how would you reconcile how different team members want to write Scala?
What I’ve seen this lead to is just because you understand one portion of the codebase, doesn’t mean you can understand another one (both on similar levels of domain complexity), and just because intellij works great on one module, doesn’t mean it’s going to work at all in another one.
EDIT: and I have to say, I love your contributions to Scala library ecosystem, and have used many of them. :) they really do reflect the simplicity of python-like scala.
Re: The Road to Scala 3
#53The way I look at modern Scala is a mix of Python and Java. Do it badly, and you end up with the unmaintainability of Python and the clunkiness of Java. Awful. Do it well, and you end up with the convenience and interactivity of Python and the typesafety, performance, and toolability of Java. This lets you implement your code quickly the first time, and have it run blazing fast on a hot JVM, with the compiler having…
> I’m personally very happy with my Python-like language with Python-like libraries, with static typing for maintainability, orders of magnitude better runtime performance, excellent parallelism and concurrency, one of the best compile-to-JS experiences in the world, and the best tooling (IDEs, profilers, monitoring, etc.) on the market. Hey lihaoyi, completely agree with you on this. (Coming from someone who recentl…
I’d say you deal with it the same as in any other language(s): with consensus, coordination, and code review.
After all, if you are a Go shop, what’s stopping someone implementing their code in Haskell? Or someone in a Python shop deciding they want to use Clojurescript on Node.js for scripting? Or even within a language, if you are a Spring shop and someone wanted to implement their service on WebLogic?
Scala definitely had a culture of crazy experiments and bifurcation in the past, but it’s always been a matter of team culture rather than of the language itself: something that applies to all languages, especially as polyglot codebases become more common
Without Scala, but with the same lack of coordination, quite likely you would end up with 4 separate silos in your polyglot codebase, written in JS, Java, Python, and Haskell/Idris. Would that really be a better state?
Re: The Road to Scala 3
#54Earlier quoted context omitted.
The marketing is very impressive indeed, I won't argue against that. I can only think of Angular 1.0 as an equally impressive feat of advertising (I totally bought into that - for a while). But logically, what you suggest implies that either generics aren't absolutely needed, and shouldn't be in Go, or it's absolutely needed, and Go has been lacking them for a long time.
I’m sorry, I don’t think you can state absolutes like this with respect to languages. After 5 years of programming in Scala, professionally, writing and debugging a cli tool in Go-Lang felt like a breath of fresh air. I agree with about go marketing, in that I think the creators of go found a larger “market” of devs and understood them better.
haha yup, Go actually understands its community, Scala is more concerned with doing really "smart" stuff
Re: The Road to Scala 3
#55Earlier quoted context omitted.
proof is in the pudding on that one, sorry don't think there are academics studying this but it's an obvious outcome from the war that was Go/Scala/Node. Go is eating Scalas lunch because its easy to understand and communities are stronger than individuals. Sure Scala has more 'features' but Rob Pike would say every feature has a cost and you need to weigh that, didn't see that ever happen in Scala. Go is taking the…
Adoption isn't everything and google has incredible marketing sway. Tensorflow almost won the ML framework wars despite being clearly outclassed by Torch and it took until recently for Torch to overcome the Google brand name
Marketing and they understand how to build communities, this is actually the most important thing. TF isn't a great product so thats showing through now, Go and K8s are and you don't see the backtick there.
Re: The Road to Scala 3
#56Earlier quoted context omitted.
no it just implies the don't willy nilly throw in any feature into the language like Scala, and I am incredibly grateful for it after writing Scala for a couple years, what a mess
Scala tends to be more of a kitchen sink, kind of an academic experiment brought to industry, whereas Go is way too far down the path of having only “absolutely needed” features - they promoted it as a “pragmatic, boring” language to focus on your business and write consistent code. As a result, this approach makes the language less expressive, really boring for many engineers, and also, unfortunately, it brought som…
Sure there are use cases for Scala, they are just few and far between nowadays. If your looking to experiment with crazy functional stuff have fun, just don't write actual software in it, which was unfortunately the outcome, and a bunch of companies paid the price
Re: The Road to Scala 3
#57I often see comparisons to Go, Kotlin, Rust, etc, and I agree that it's unlikely for Scala to have a second renaissance and have an steep upward trajectory like those languages, but is that really a death of a language? I'm actually fine with Scala narrowing its scope and focus at being really good at just a couple of things. Such as embracing its FP-side more so than its OO-side. Not to say there is no value in its…
What is the story with Scala on Android? Years ago I thought it was a matter of using too much memory. There’s not much talk about it but it does seem to be possible:
Will Scala 3 help?
Re: The Road to Scala 3
#58The more I read about Scala it makes me wonder why (1) I am not using it (or my team) (2) Java teams across the world are not at least seriously considering changing to Scala. It seems likes it's miles ahead of both Java and even Kotlin.
Re: The Road to Scala 3
#59I'm sorry to be this negative, but I sincerely believe Scala to be the worst seriously used programming language of modern times. It should just end.
Why? This seems to be an uncommon opinion.
Re: The Road to Scala 3
#60I really love Scala, but I worry about its future given Google putting its weight behind Kotlin, and the two offering a lot of the same features and philosophy. Does anyone know if the Scala maintainers have addressed this directly?
* If you use even half of Scala's functional capabilities, Kotlin isn't really an alternative.
* What Google does with Kotlin and Android is completely irrelevant to the Scala ecosystem and its users.
* On the back-end side, Kotlin doesn't intersect that much with Scala. I haven't met anyone migrating from say, Play to Spring thanks to Kotlin's support.
* In the big data world, if you rely heavily on Spark, Scala is still the preferred option on the JVM. Python is a much bigger threat there.
* Lightbend and the Scala center have been seriously working on tooling, which is the biggest issue to address compared to Kotlin (Jetbrains has a huge advantage here).