Next Step for Scala: Shutdown.
What's Next for Scala
91–100 of 203 posts
Re: What's Next for Scala
#92Earlier quoted context omitted.
Go is a competitor to Java in that most of the things people do with one, they could do with the other. As a Java guy, i would agree that Go is not actually competitive with Java. But then, a Go guy would probably say the opposite.
Really? Where are the Go versions of Spring, JEE, Android, Solr, Liferay, Kafka, Gemalto, microEJ, PTC, Aicas, Ricoh, Kyocera, Java Card, VisualVM, JFR, JMX and plenty of other stuff I haven't bothered to type?
Isn't Kyocera, like, a printer company?
Re: What's Next for Scala
#93Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains…
IMO, it really depends on the team you join, as with most programming projects. Scala can be used in a classic mutable OOP manner, as if you were writing Java in 2005, or if you heavily buy into pure FB libraries it can be used basically like it's Haskell, but IMO neither of these approaches embrace the strengths of the language. It's meant to be a true mix of OOP and functional paradigms, not going extreme one way or the other. The object oriented aspects let you embrace great OOP software architecture patterns like Domain Driven Design, so that you can really model the business domain clearly and faithfully. Then the functional aspects allow you to implement a "functional core, imperative shell" style, that's really easy to reason about, and easy to make concurrent (safely), while also having excellent/safe/descriptive types like Future/Option/Try and ADTs.
It sounds like you've worked with a group of people who want to treat Scala like it's Haskell, but that's a minority community that IMO isn't really embracing the strengths of the language. I've worked on projects that go all-in on libs like Cats and Scalaz, and I agree that they're mostly unnecessary complexity that also obscure the modelling of the business domain. You're going to massively confuse newcomers with all the Applicative/Effect/Monad/Monoid/Functor/etc. talk, for next to no benefit. Actors are a bit of a different story - excellent for the 1% of times where you really need them (lots of mutable state and lots of concurrency), but 99% of the time you don't need them. Some devs are enamoured with the mathematical purity of pure functional programming, without properly considering how hard it is to understand for most other devs. If you let these types take over your company, that’s a cultural problem, not really a language problem.
Odersky describes why he created the language here: https://www.signifytechnology.com/blog/2018/01/why-scala
> ... programmers are increasingly facing new challenges for high-level domain modeling, rapid development, and, more recently, parallelism and concurrency. It seemed to me that a unification of the traditional object-oriented model with functional programming concepts was feasible and highly desirable to address those challenges.
I completely agree, and have yet to find a better language than Scala for the above demands, assuming you really embrace the OOP/functional mix. I've been writing lots of Scala at my day job for the past ~5 years, and it's my favourite language. I've worked on backends in Scala, Java, Go, Python, PHP and Node, and prefer Scala to all of them.
I also agree with Li Haoyi - it's becoming a really solid, stable, reliable language, with improvements focused on the build tools, compiler, and the odd language wart, without significant changes to syntax/style, which is great. It does take awhile to learn, and you do have to be careful about what style you program in, but I think if you just embrace the language's OOP/functional fix, and for "core style" mostly stick with the standard library (Future/Try/Option/etc.) vs. going crazy with Cats/Scalaz/Akka/etc. (unless you REALLY need Akka specifically), it's an outstanding language.
Re: What's Next for Scala
#94Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains…
I must say this comment reminded me of LISP and the many criticisms put against it. Perceived as overly flexible ("custom architectural patterns") with snobbish people ("colleagues will not allow to"). But at the same time many people will find LISP (or Scala) their "superpower" that allows them to perform really well.
Re: What's Next for Scala
#95For context see Lightbend secures 25MM funding round, proceeds to layoff Scala contributors https://news.ycombinator.com/item?id=22842166
I don't follow Scala (never wrote a single line), so I didn't realize the company changed names from Typesafe to Lightbend. Here's a question: how on earth do they make any money? The Wikipedia article makes an offhand mention of something called Lightbend subscription; is that what keeps them afloat?
A lot of it is consulting, and they also have some proprietary and/or hosted services, and even akka plugins that they charge for.
Re: What's Next for Scala
#96I very recently (about a year ago) joined a shop that is primarily into functional programming (FP) and I got my first exposure to Scala as well as F# through work projects. As a long time user of Java/OOP here are my thoughts on Scala and why it has so many things things going against it. Consider the following: 1) First, Scala is designed and developed by "ivory" tower academics primarily for research/PhD thesis pu…
I’m surprised you had such a bad experience with scala. Or do you think these are problems with how scala is perceived versus how it actually is to use? Personally I liked it. I spent a while doing java web dev with the play framework, and also spent a while doing scala web dev with the play framework, which allowed me to compare directly. I have to say scala is a far nicer OOP language than java. The collection clas…
I had the same experience as you on the beginning. I started with a project in play framework, I was really excited about an improved java, etc. Then some FP hardcore developers came and started to influence younger developers that OOP was not cool anymore, all our system should be composed of Actions and monads of all kinds, and all business logic should be just a big composition of map and flatMaps.
After a while the project became just a dick measuring context of who could do the best trick shots. Declaring a lot of implicit parameters, implicit conversions automatically applied, crazy type inference that makes compiling 10x slower, you name it. Just to make the code unreadable enough that other developers need days to understand a three lines of code change.
And after all of that the more they do it, the more they are seen as the best Scala developers on the team.
Re: What's Next for Scala
#97Since the post mentions Scala Native, all these guest language projects that eschew the platform that made them famous and try to pursue the dream of being their own platform, while building an ecosystem, GC and optimising compiler from scratch (even if they build on LLVM or compile via C/C++), would be much better taking advantage of AOT and JIT caches from several JVM implementations instead of pretending they don'…
In my mind, GraalVM native compilation has superseded scala-native. GraalVM native compilation works really well. Many projects will compile to native out of the box. Many more with a bit of reflection config that's autogenerated. The native executables are slim, statically linked so they "just work", and startup instantly as one would expect. Scala is now a great choice for CLI tools.
> statically linked so they "just work"
If I remember correctly you have to redistribute some .dll (VC something) file alongside your .exe on Windows since fresh Windows installations don't have the .dll. Did that change?
Re: What's Next for Scala
#98> It's not Clojure-dead
It never ceases to amaze me. Almost every single time, whenever there's a post or a comment on HN that mentions Clojure or Clojurescript, there's always someone from outside of the Clojure community attacking the language, saying things that are simply untrue. Like people are afraid of it becoming too successful. It's not some zero-sum game - the success of one language ecosystem doesn't mean that your other, the more favorite tool would be immediately forgotten.
Somehow I don't see Clojure people attacking other languages; they instead learn and borrow from them.
- Python people would be like: "you can't do machine learning stuff...", and what Clojure people say? Instead of fighting Python, they're like: "We can¹, and also We have nothing against Python, we'll figure out a way to talk to it from Clojure.²"
- Golang people would be: "CSP be is cool," Clojure people: "Awesome, we'll borrow it just the way how you did it. Also, we like Golang, we're going to write a Clojure interpreter and linter in it.³"
- R people: "Clojure is data-driven? Pfff... you know nothing about statistics ...." Clojure people: - "Oh yeah R is cool, btw. we've just figured out a way to interop from Clojure⁴."
- Elixir people: "BEAM is way better than your JVM crap...", Clojure people: "Not really, but okay, we see your point, we'll build Clojure on BEAM⁵"
- JS/TS people say things like "Modern Javascript is so nice, who needs Clojure now?" They get excited about stuff like React Hooks, and Clojure people: "Hmmm... actually we had a better way of dealing with stateful UI components for a few years now. We've been trying to tell you, but you never listened..."
They've been saying, "Clojure is dead" for years now. But despite all the odds, Clojure is very much alive and thriving. It's the most popular language within languages with a strong FP emphasis. Just look around - it has more books, more jobs, more podcasts, more conferences, and meetups than of Haskell, OCaml, Purescript, Elm, Elixir, F#.
I suggest people from other PL communities learn from Clojure people. It is a small but diverse and very friendly community of pragmatists - while others keep shoveling the same shit from one corner to another, trying to re-invent things over and over again, Clojurists keep borrowing good ideas and filtering out bad ones. And calmly and quietly keep building cool stuff and getting paid for it⁶.
² https://github.com/clj-python/libpython-clj
³ https://github.com/candid82/joker
⁴ https://github.com/scicloj/clojisr
Re: What's Next for Scala
#99Earlier quoted context omitted.
Go is a competitor to Java in that most of the things people do with one, they could do with the other. As a Java guy, i would agree that Go is not actually competitive with Java. But then, a Go guy would probably say the opposite.
Really? Where are the Go versions of Spring, JEE, Android, Solr, Liferay, Kafka, Gemalto, microEJ, PTC, Aicas, Ricoh, Kyocera, Java Card, VisualVM, JFR, JMX and plenty of other stuff I haven't bothered to type?
Avoiding the necessity for libraries like many of these would be a key success criteria for a new language were I judging.
Re: What's Next for Scala
#100Scala is a beautiful and elegant language. I really thought that it would be one of my favourite languages when I first started working with it. However, after some time I got disenchanted. First, Scala is hard. Projects written by one person quickly become a deep functional labyrinth and custom architectural patterns because Scala is so expressive and you can do all kind of twists. Second, the entrance level remains…
no one flavor of scala will ever be a standard. you have to adopt coding styles and stick to them. once you get to the point where you have a pattern and you’re just coding-by-number scala isn’t the problem anymore