Storing the stack frame between break and boundary on the heap and then returning to it, is conceptually very similar to how an actor stores state and can pipe a future to itself. Perhaps delimited continuations are a special case of actor behavior being embedded in the language.
I don't know, all that "syntax" feels a bit weird, and I like "monads" much more. I'd rather write traverse instead of that stuff at 11:23 backed by exceptions. Not a fan of Rust error handling either, I think it's not very FP approach, I felt downgraded in a sense when writing code in Rust (but it's a revolutionary language considering its capability with borrowing checking, etc).
I'm inclined to agree. Sometimes more code that's simpler and more self explanatory is good - at some point the syntax feels like there's some magic going on. But ultimately 90% of the code we write is hiding some magic so its down to. your comfort level with the paradigm. Seeing this for the first time my head was hurting quite a bit 🙂
[...] I refuse to use Either for errors, I think Either is terrible. And I want a Future that gives me as a result either a list of T or the error. [...]
The people who first approach Scala say it's too complicated, so what do they do, they add more. Their rational is that they're "completing" the picture as is necessary, not on a whim. But most of those newbies leave. So, there's a trade-off. Now, if any new things make it harder (as with perhaps debugging) on current Scala users, will that chase them away or will they seek some other way of working around difficult features? Time will tell.
@@markhathaway9456 It'll be interesting to see how this gets used in non-trivial examples, but multiple exit points for loops/functions rarely increases the ability to mentally trace code when reading it (and help when debugging even less). I'm also really curious to see how `Break` will (or won't) avoid the issues with abstractions leaking that have lead non-local returns to be considered a code smell. When any try block can potentially break your abstraction, corner cases proliferate.
@@MorgenPeschke Why would it be a headache? Current effect libraries are already a headache. The stack is incomprensible without some serious tricks. AFAICT continuations will restore the stack to how it was so it looks as you would expect.
@@jasonpickens9839 Yes, current effect libraries can be a headache, however this will likely be worse. The first (and least important) is that, depending on what you do with it, the stack is going to be mangled by patterns like the one at 16:52 or 19:00 so there isn't necessarily going to be an improvement there. This is without taking into account that effect libraries aren't obliged to ignore things like project Loom, so it's more likely than not that they'll be able to leverage it's capabilities to improve their stack traces, shrinking the gap even further. The bigger issue is that effect libraries (particularly monadic ones) are easier to mentally model and debug than imperative/mutable code because they actively limit the space of possible states the programmer has to keep track of. This is such a benefit that we put up with the mangled/unusable stack traces because we can mostly get along without them. Yes, the ability to break across effects is powerful, but the cost of that power is the loss of the predictability and composability that monadic effects offer. Even worse, it means you can exit a block in as many places as you could possibly imagine (including inside of function calls of arbitrary depths), which explodes the search space of possible states you have to keep track of when debugging. It's kind of like the difference between writing a tail recursive function and using foldLeft to accumulate a calculation over a collection. The tail recursive function is inarguably more powerful, however it's also much harder to debug, so it's a bad choice when you don't need that power. This is fine because the foldLeft is usually also easier to use. In this case, the ability to break across things like foreach instead of using something like traverse makes it look like this is the simpler approach. However, this is only the case when everything works correctly, and when in our industry has assuming things will always work correctly ever ended up in anything other than a massive headache?
Haha there is some truth to this but I do think that the Scala team do a good job of finding the most powerful abstractions that give us the greatest capabilities (can't wait for capture checking 😉). So yes the language does grow but I want a language that grows rather than one that grows stale. So long as redundant/obsolete features also get removed (there is evidence in this talk that they do).
Rust is amazing. It is just not for everything. Obviously, a garbage collector is preferred for most of the use cases of functional languages, but when you NEED a manually managed language, it doesn't get better than rust.
![ค้างคืนโรงเก็บกระสวยอวกาศร้างกลางทะเลทราย [Around The World Ep. 3]](http://i.ytimg.com/vi/E5bWZQhABJE/mqdefault.jpg)
The man just proclaimed the end of the monad era
"My new Scala is much more user-friendly than Haskell. I don't like that." ~ Sheldon
Thanks a lot for sharing it!!
Game changer.
That was so cool
Could you provide a reference for the papers? Is the first one "monads and composable continuations"?
Effect systems are the future of programming
Storing the stack frame between break and boundary on the heap and then returning to it, is conceptually very similar to how an actor stores state and can pipe a future to itself. Perhaps delimited continuations are a special case of actor behavior being embedded in the language.
I don't know, all that "syntax" feels a bit weird, and I like "monads" much more. I'd rather write traverse instead of that stuff at 11:23 backed by exceptions. Not a fan of Rust error handling either, I think it's not very FP approach, I felt downgraded in a sense when writing code in Rust (but it's a revolutionary language considering its capability with borrowing checking, etc).
I'm inclined to agree. Sometimes more code that's simpler and more self explanatory is good - at some point the syntax feels like there's some magic going on. But ultimately 90% of the code we write is hiding some magic so its down to. your comfort level with the paradigm. Seeing this for the first time my head was hurting quite a bit 🙂
[...] I refuse to use Either for errors, I think Either is terrible. And I want a Future that gives me as a result either a list of T or the error. [...]
What's wrong with Try?
Doesn't Try only support Throwables as errors?
taticu, el padre, BO$$
This looks like it will quickly become a massive headache to debug.
The people who first approach Scala say it's too complicated, so what do they do, they add more. Their rational is that they're "completing" the picture as is necessary, not on a whim. But most of those newbies leave. So, there's a trade-off. Now, if any new things make it harder (as with perhaps debugging) on current Scala users, will that chase them away or will they seek some other way of working around difficult features? Time will tell.
@@markhathaway9456 It'll be interesting to see how this gets used in non-trivial examples, but multiple exit points for loops/functions rarely increases the ability to mentally trace code when reading it (and help when debugging even less). I'm also really curious to see how `Break` will (or won't) avoid the issues with abstractions leaking that have lead non-local returns to be considered a code smell. When any try block can potentially break your abstraction, corner cases proliferate.
@@MorgenPeschke Why would it be a headache? Current effect libraries are already a headache. The stack is incomprensible without some serious tricks. AFAICT continuations will restore the stack to how it was so it looks as you would expect.
@@jasonpickens9839 Yes, current effect libraries can be a headache, however this will likely be worse.
The first (and least important) is that, depending on what you do with it, the stack is going to be mangled by patterns like the one at 16:52 or 19:00 so there isn't necessarily going to be an improvement there. This is without taking into account that effect libraries aren't obliged to ignore things like project Loom, so it's more likely than not that they'll be able to leverage it's capabilities to improve their stack traces, shrinking the gap even further.
The bigger issue is that effect libraries (particularly monadic ones) are easier to mentally model and debug than imperative/mutable code because they actively limit the space of possible states the programmer has to keep track of. This is such a benefit that we put up with the mangled/unusable stack traces because we can mostly get along without them.
Yes, the ability to break across effects is powerful, but the cost of that power is the loss of the predictability and composability that monadic effects offer. Even worse, it means you can exit a block in as many places as you could possibly imagine (including inside of function calls of arbitrary depths), which explodes the search space of possible states you have to keep track of when debugging.
It's kind of like the difference between writing a tail recursive function and using foldLeft to accumulate a calculation over a collection. The tail recursive function is inarguably more powerful, however it's also much harder to debug, so it's a bad choice when you don't need that power. This is fine because the foldLeft is usually also easier to use.
In this case, the ability to break across things like foreach instead of using something like traverse makes it look like this is the simpler approach. However, this is only the case when everything works correctly, and when in our industry has assuming things will always work correctly ever ended up in anything other than a massive headache?
nice, but I like Unison approach better
expand on this please
Need actor model locally
It looks like Scala is on its way to becoming the C++ of functional programming.
Haha there is some truth to this but I do think that the Scala team do a good job of finding the most powerful abstractions that give us the greatest capabilities (can't wait for capture checking 😉). So yes the language does grow but I want a language that grows rather than one that grows stale. So long as redundant/obsolete features also get removed (there is evidence in this talk that they do).
On its way? Always has been!
@@fredoverflow And Clojure is in what way better?
@@encapsulatio Clojure and Scala/C++ are on complete opposites of the complexity spectrum (imho)
11:14 - Why mention Rust, Rust is horrible. "I shall makest thy life unbearable by promising to solve the problems that thou dost not hast".
Rust is amazing. It is just not for everything. Obviously, a garbage collector is preferred for most of the use cases of functional languages, but when you NEED a manually managed language, it doesn't get better than rust.
what scala is going to?... ah wait, it is the same direction :)
And what is your alternative, simpler solution?
I don't like it 😬
Too raw talk. The main thought is tough to be tracked.
Are you saying it's hard to debug or just hard to understand the overall ideal final product?
Way too complicated. I will stick to Kotlin.