Live data from Hacker News

What's Next for Scala

lihaoyi.com

191–200 of 203 posts

Re: What's Next for Scala

#191
post #156

Earlier quoted context omitted.

> I switched from scala to python and oh man what a relief. I did a bit of Python, then did a bit of Scala, and now do both at work. Oh what a pain Python is! And what a joy Scala is! > Way too many theoretical concepts, monads, monoids , isomorphisms ect that make you feel stupid. Concepts are theoretical in their nature, aren't they? Perhaps these concepts are useful and you just haven't yet found out why? Wrt feel…

> Perhaps these concepts are useful and you just haven't yet found out why? Or maybe they are not that useful? If they were really that useful we would see those concepts everywhere.

You do see those concepts everywhere.

monads : stuff which kind of encapsulate other things, but you can still nicely manipulate both the thing and the stuff. Let's say, lists.

monoids : set of things where you kind of can add one to another. Let's say, numbers

isomorphisms : functions where there is exactly as many outputs possible than there are possible inputs. Let's say, adding 1 to a number. It's kind of useful knowing whether or not a function is an isomorphism (hello, hash collisions !).

Those concepts aren't specific to any programming language in fact, and are in fact everywhere. You just don't need to explicit them to use them, expliciting them is an option (even in Scala) which allows you to do meta manipulations on them (which Scala doesn't require, and doesn't even really suggest since none are part of the standard lib).

Re: What's Next for Scala

#192
post #191

Earlier quoted context omitted.

> Perhaps these concepts are useful and you just haven't yet found out why? Or maybe they are not that useful? If they were really that useful we would see those concepts everywhere.

You do see those concepts everywhere. monads : stuff which kind of encapsulate other things, but you can still nicely manipulate both the thing and the stuff. Let's say, lists. monoids : set of things where you kind of can add one to another. Let's say, numbers isomorphisms : functions where there is exactly as many outputs possible than there are possible inputs. Let's say, adding 1 to a number. It's kind of useful…

oh ok. Any thoughts on why scala conferences have this "Describable, typesafe computations for the less monadically inclined" but python conferences don't ?

Re: What's Next for Scala

#193
post #113

Earlier quoted context omitted.

Not understanding why they exist is the first error trying to sell to enterprise.

Seeing how .Net is being sold to enterprises without such libraries I would say that they exist because business happily buys into any promise that something increases productivity even if that is just salesmen's lies. But it requires good salesmen not good engineers.

Actually it does have many of those libraries, they just come with a different name, or in commercial only form, without the FOSS variants from Java.

Re: What's Next for Scala

#194
post #52

Earlier quoted context omitted.

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.

thanks

Re: What's Next for Scala

#195
post #191

Earlier quoted context omitted.

You do see those concepts everywhere. monads : stuff which kind of encapsulate other things, but you can still nicely manipulate both the thing and the stuff. Let's say, lists. monoids : set of things where you kind of can add one to another. Let's say, numbers isomorphisms : functions where there is exactly as many outputs possible than there are possible inputs. Let's say, adding 1 to a number. It's kind of useful…

oh ok. Any thoughts on why scala conferences have this "Describable, typesafe computations for the less monadically inclined" but python conferences don't ?

Because doing something like that without a type system (which Python doesn't have) to guide your hand is practically impossible.

I would expect Clojure programmers (while still functional) don't use these abstractions either.

On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.

Re: What's Next for Scala

#196
post #127
post #76

I’ve been using Scala as my main programming language for over 5 years. I’ve found my “plateau of enlightenment” by sticking to a subset of the features: case classes, for comprehensions, futures, immutability, pattern matching. By avoiding things like implicit, overly complex types, defining/overloading operators, and being dogmatic about FP/OOP I find the language stays out of your way and lets you write code that…

I've done the same by being lazy, mainly treating it as a better Java and only learning new stuff when necessary or obviously beneficial. I want to write good programs, not fancy code. My advice: - Options, immutability, pattern matching, and list comprehensions are all awesome and better than the default Javaesque way - Scala concurrency abstractions all better than Java, but concurrency is still hard. Proceed with…

> concurrency is still hard. Proceed with caution

> No Scalaz or any other FP-crusader stuff ever

That stuff which some people might consider FP-crusader vanity is something which can make concurrency manageable, maybe even joy.

I encourage you to open your mind, at least for a bit, and have a look at ZIO or Monix.

> Enforce coding rules with linters

Absolutely! Scalafmt and Scalafix for the win!

Re: What's Next for Scala

#197

Earlier quoted context omitted.

oh ok. Any thoughts on why scala conferences have this "Describable, typesafe computations for the less monadically inclined" but python conferences don't ?

Because doing something like that without a type system (which Python doesn't have) to guide your hand is practically impossible. I would expect Clojure programmers (while still functional) don't use these abstractions either. On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.

Oh I was asking if they( monoids, monads ect) are everywhere like GP claimed then how come monads isn't something that talked about in clojure or python conferences.

Re: What's Next for Scala

#198

Earlier quoted context omitted.

oh ok. Any thoughts on why scala conferences have this "Describable, typesafe computations for the less monadically inclined" but python conferences don't ?

Because doing something like that without a type system (which Python doesn't have) to guide your hand is practically impossible. I would expect Clojure programmers (while still functional) don't use these abstractions either. On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.

Oh I was asking if they( monoids, monads ect) are everywhere like GP claimed then how come monads isn't something that talked about in clojure or python conferences. But its always talked about in scala conferences.

Re: What's Next for Scala

#199

Earlier quoted context omitted.

I know people who would be sold on NO JEE, NO Spring, NO Hibernate. I am one of them. :)

I have to say if they add generics without type erasure to go then Java is likely in trouble.

A language feature alone doesn't replace an ecosystem with 25 years of production experience across platforms that aren't even supported by Go.

After getting generics, Go still needs to offer JFR/JMX/VisualVM like monitoring and dynamic code loading capabilities (Go plugins are very limited), JEE/Spring like Web tooling, Liferay/AEM/Magnolia like CMSs, an OS of its own and real time GC, card chips, M2M hardware gateways, printer enterprise configuration appps, and plenty of other use cases that many on HN seem unaware of its existence in enterprise scenarios.

Re: What's Next for Scala

#200

Earlier quoted context omitted.

Because doing something like that without a type system (which Python doesn't have) to guide your hand is practically impossible. I would expect Clojure programmers (while still functional) don't use these abstractions either. On the other hand, typed languages, like Haskell, Scala, OCaml, F#, do employ these abstract concepts. Their type system makes these worthwhile endeavour with great payoff.

Oh I was asking if they( monoids, monads ect) are everywhere like GP claimed then how come monads isn't something that talked about in clojure or python conferences. But its always talked about in scala conferences.

Well, maybe scala conferences are hosted and attended by people who are interested in those concepts and find them attractive to talk about ? "conference people" just develop their own meta over time

Also, I just clicked on the most recent conference on clojure.org : https://clojured.de/schedule/ , and there is a talk mentioning monads while promising to not talk about monads :-D So it kind of reinforce my point that basic theoretical concepts are silently everywhere ^^ (and fully not necessary for almost everything).

But I don't think conferences are representative of the "on the ground production experience" that you have, or at least can have.

I personnaly wouldn't submit a paper to a conference with a talk "Here's how I made a whole backend stack using boring scala, and it just works" because as you say, I feel it's just full of theoretical speakers and that wouldn't interest anyone. Meanwhile, I also did code a whole backend in boring scala, and it in fact just works, and it feels good :-)

Post reply on HN