4 ms·

I think one more problem with Scala, apart from the lack of stability and having to solve the language's problems instead of your application ones, is one of lo

I think one more problem with Scala, apart from the lack of stability and having to solve the language's problems instead of your application ones, is one of local maxima. Most of the ecosystem uses monads. And the way most projects end up using monads is have "the one monad" that every function returns. ZIO is an example of that. Understandable, since the alternative is to have tons of different function colors. However, since in that case the monad really is just a configurable semicolon semantic, you've just gone full circle and chosen a single global one. And in that case, why not just choose a language where that semantic already is the core semicolon semantic of the language? You're living with a ton of complexity for very limited gain.

azernik 4y ago
1. Because different projects will want different monads 2. In my experience, having up-conversions between different monads is intuitive low-noise
- cube2222 4y ago
  > Because different projects will want different monads It doesn't look like that to me, based on how the ecosystem currently converges on a single one. I understand there may be some projects that do that, but if the majority converge, then it's still needles complexity. However, I might be wrong. I've been an external observer for a while already.
  - valenterry 4y ago
    History proofs this wrong. Just look at it: first there were Scala Futures and Twitter Futures. Then there came Scalaz and Monix, later Cats-effect. Now ZIO also joined. And each library even brings different kind of effect types. And all of that works, even in combination! This is as if you mix angular and react. Sure, you should try to not do that as much as possible, but the mere fact that you can do this in Scala is a sign of awesome language and library design that is far outstanding compared it the majority of other languages. You could never come up with the "one true solution" from the very beginning.
    - auggierose 4y ago
      > You could never come up with the "one true solution" from the very beginning. I think I can! I mean, that's what science is for, right?
      - valenterry 4y ago
        I'm not so sure. The problem is that the world is moving, including hardware, software, interfaces but also people and process. Languages have to optimize against a moving target. So naturally it's a good idea to optimize for something moving and not something static. This is what makes Scala good. The language itself is not very complex actually, but it enables complex and powerful libraries.
        auggierose 4y ago
        We are still in the phase where concepts are settling. Pretty sure nobody in a 100 years will think that Monads are a good idea.
        valenterry 4y ago
        Monads are like numbers. You can think they are not a good idea, but they are just a matter of fact and existence. Also, in a 100 years maybe our brains will be completely different. How do you optimize your programming language for that? I don't think you can.
        auggierose 4y ago
        Given that our brains have been the same for a few thousand years, maybe I don't need to optimise for that. Anyway, what we currently have as programming languages are all workarounds. Necessary for now, because how else would we program? But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type system. I am sure the concept of number will outlive the concept of monad in terms of popularity.
  - azernik 4y ago
    One example: Any project using a transactional database will want a monad for actions that occur within a single transaction (see e.g. the Slick `DBIO` monad).
lupire 4y ago
> why not just choose a language where that semantic already is the core semicolon semantic of the language? The semicolon isn't semantic. A "semicolon" monad is essentially a single global context object. Most languages let anyone anywhere introduce a global context accessible from everywhere else. At least a monad lets you track it all.
- cube2222 4y ago
  It's not just context. It's also asynchronicity and error handling for example. The semicolon semantic is how operations separated by semicolons (or newlines) are evaluated and how they impact the general state the program is in. Which is also what a monad's flatMap does, in a configurable way.
  - valenterry 4y ago
    No, it is just context. Which context you choose in which part of your code is up to you. Somewhere I might choose ZIO. Elsewhere I might just choose an error-context. Or a state-context. Or a "let me accumulate some extra information while doing data-rprcessing"-context. And it is always explicit when you are in a context and which one it is. This is really the strengths over languages where this concept is missing. Those languages will just merge and mushup contexts and you never know exactly which things are safe to use and not.
    - cube2222 4y ago
      I know you can do it, the question is whether it's mainstream to do it, or whether in practice you end up with a single one in 95% of the cases. Based on using it a bit and talking to many, more or less disillusioned, scala developers, my opinion is: it's not worth it. It's fine for us to disagree though. There's enough programming languages and projects for everybody.
      - valenterry 4y ago
        It is very mainstream to do that. Show me a project that is not just a small playground that uses either ZIO or cats-effect and does NOT use another context such as Either/Try or Option or List, ...
wbillingsley 4y ago
It seems (to me) less complex to have that as "just a library". In most of my little projects, I don't use ZIO, I just have a tiny library I wrote years ago that lets me write stuff that works ok whether it's a Future[Seq] or a Seq[Future] or a Future[Seq[Future[Seq]]] underneath. https://github.com/wbillingsley/handy https://github.com/wbillingsley/handy If ZIO (or some other choice) were baked into the language, I'd be using their choice of async libnrary for everything whether I want to or not. And I wouldn't be able to switch to the new-shiny-and-exciting-thing that comes out when I want to explore it because "sorry, X was what the designers chose when the language was written, so X it must be". In Scala, I can use my little thing I'm familiar with, or I can try out ZIO, or Cats-Effect, or Akka Streams (before the licence change). I get to explore concepts very quickly and very easily without having to shift languages and learn a new set of build tools and syntax at the same time.
deleted 4y ago
[deleted]

azernik 4y ago

1. Because different projects will want different monads 2. In my experience, having up-conversions between different monads is intuitive low-noise

cube2222 4y ago
> Because different projects will want different monads It doesn't look like that to me, based on how the ecosystem currently converges on a single one. I understand there may be some projects that do that, but if the majority converge, then it's still needles complexity. However, I might be wrong. I've been an external observer for a while already.
- valenterry 4y ago
  History proofs this wrong. Just look at it: first there were Scala Futures and Twitter Futures. Then there came Scalaz and Monix, later Cats-effect. Now ZIO also joined. And each library even brings different kind of effect types. And all of that works, even in combination! This is as if you mix angular and react. Sure, you should try to not do that as much as possible, but the mere fact that you can do this in Scala is a sign of awesome language and library design that is far outstanding compared it the majority of other languages. You could never come up with the "one true solution" from the very beginning.
  - auggierose 4y ago
    > You could never come up with the "one true solution" from the very beginning. I think I can! I mean, that's what science is for, right?
    - valenterry 4y ago
      I'm not so sure. The problem is that the world is moving, including hardware, software, interfaces but also people and process. Languages have to optimize against a moving target. So naturally it's a good idea to optimize for something moving and not something static. This is what makes Scala good. The language itself is not very complex actually, but it enables complex and powerful libraries.
      - auggierose 4y ago
        We are still in the phase where concepts are settling. Pretty sure nobody in a 100 years will think that Monads are a good idea.
        valenterry 4y ago
        Monads are like numbers. You can think they are not a good idea, but they are just a matter of fact and existence. Also, in a 100 years maybe our brains will be completely different. How do you optimize your programming language for that? I don't think you can.
        auggierose 4y ago
        Given that our brains have been the same for a few thousand years, maybe I don't need to optimise for that. Anyway, what we currently have as programming languages are all workarounds. Necessary for now, because how else would we program? But in the end we need to converge programming, math and logic, and once this is done, we will be ready for anything. And we won't need monads as a crutch, forced upon us by a type system. I am sure the concept of number will outlive the concept of monad in terms of popularity.
- azernik 4y ago
  One example: Any project using a transactional database will want a monad for actions that occur within a single transaction (see e.g. the Slick `DBIO` monad).

lupire 4y ago

> why not just choose a language where that semantic already is the core semicolon semantic of the language? The semicolon isn't semantic. A "semicolon" monad is essentially a single global context object. Most languages let anyone anywhere introduce a global context accessible from everywhere else. At least a monad lets you track it all.

cube2222 4y ago
It's not just context. It's also asynchronicity and error handling for example. The semicolon semantic is how operations separated by semicolons (or newlines) are evaluated and how they impact the general state the program is in. Which is also what a monad's flatMap does, in a configurable way.
- valenterry 4y ago
  No, it is just context. Which context you choose in which part of your code is up to you. Somewhere I might choose ZIO. Elsewhere I might just choose an error-context. Or a state-context. Or a "let me accumulate some extra information while doing data-rprcessing"-context. And it is always explicit when you are in a context and which one it is. This is really the strengths over languages where this concept is missing. Those languages will just merge and mushup contexts and you never know exactly which things are safe to use and not.
  - cube2222 4y ago
    I know you can do it, the question is whether it's mainstream to do it, or whether in practice you end up with a single one in 95% of the cases. Based on using it a bit and talking to many, more or less disillusioned, scala developers, my opinion is: it's not worth it. It's fine for us to disagree though. There's enough programming languages and projects for everybody.
    - valenterry 4y ago
      It is very mainstream to do that. Show me a project that is not just a small playground that uses either ZIO or cats-effect and does NOT use another context such as Either/Try or Option or List, ...

wbillingsley 4y ago

It seems (to me) less complex to have that as "just a library". In most of my little projects, I don't use ZIO, I just have a tiny library I wrote years ago that lets me write stuff that works ok whether it's a Future[Seq] or a Seq[Future] or a Future[Seq[Future[Seq]]] underneath. https://github.com/wbillingsley/handy https://github.com/wbillingsley/handy If ZIO (or some other choice) were baked into the language, I'd be using their choice of async libnrary for everything whether I want to or not. And I wouldn't be able to switch to the new-shiny-and-exciting-thing that comes out when I want to explore it because "sorry, X was what the designers chose when the language was written, so X it must be". In Scala, I can use my little thing I'm familiar with, or I can try out ZIO, or Cats-Effect, or Akka Streams (before the licence change). I get to explore concepts very quickly and very easily without having to shift languages and learn a new set of build tools and syntax at the same time.

deleted 4y ago

[deleted]