zlacker

When writing some IO bound application, async Rust is great. Less great for libraries that want to support both async and sync without having to make an async runtime a dependency if you just want the sync interface. Mutually exclusive features are taboo unfortunately. One thing I really love about Haskell is you can make any function run in a green thread by simply composing it with the 'async' function. There's nothing special about it. This works much better than say Go, because Haskell is immutable.

>>xedrac+(OP)
I'm not clear what your last sentence has to do with anything else? What does immutability have to do with Async/sync conversions?

>>XorNot+S
Immutability is great for multithreaded/async programs because every thread can rest assured knowing no other thread can sneakily modify objects that they are operating on currently.

>>polyga+f4
Go can prevent this with the race detector among other things

>>XorNot+S
you can fearlessly run code on another thread if you're not worried it's going to cause a data race or mutate anything

>>candid+o4
Sometimes.

>>throwa+v4
This is very much not free though. Predicting memory usage in Haskell programs is notoriously tricky (and all the memory copies aren't free either).

>>XorNot+k5
It's also the case with OCaml, Elixir, clojure, etc. Non lazy languages can also have a rich collection of immutable data structures and have more predictable memory usage than Haskell. On the other hand, Go doesn't have a culture or features that encourage immutability.

>>candid+o4
The race detector needs to actually encounter a race in order to detect it, it's not a complete static analysis.

>>XorNot+k5
it's not free, but it is explicit. it's nice for the code to explicitly define how the memory is being modified. there are copies in java too, you just have to know how the runtime works to know what each line does.

>>bippih+gc
Copies in haskell are not explicit at all, though?

>>polyga+f4
How Haskell deals with access to shared resources which are mutable by their nature, like file system, or the outside world?

(A honest question, I start to think that I'd like to learn more on this language)

>>xedrac+(OP)
All threads in Haskell are green. Async just gives you another way to get return values from threads without having to use MVars or Chans.

>>IlliOn+tf
AFAIK they tend to operate through the IO monad, which serves to order read/write events and mark parts of your code as interacting with the global mutable state that lives outside your program.

So the mutable (or is it “volatile”?) environment is there, but you explicitly know when and where you interact with it.

>>xedrac+(OP)
> This works much better than say Go, because Haskell is immutable.

The immutability has nothing to do with async. Async is for IO threads. If you want pure parallelism you use `par`. But Haskell IO threads (forkIO and friends) are also green when run with GHC.

>>polyga+f4
Immutability is, quite possibly, the dumbest “silver bullet” solution ever to be praised as a solution to anything.

Congratulations, nobody is going to sneakily update an object on you, but also, nobody knows about your updates either.

It’s not a worthwhile trade off given the massive extra work it causes.

>>candid+o4
Detectors detect, they don’t prevent. All detectors suffer misses.

>>anon29+mk
Async is definitely nicer when things are immutable. On modern CPUs, async green threads can easily be backed by different OS threads running in parallel on different CPU cores, making data races a real problem for many languages. Async does not guarantee that things will not be run in parallel, although you shouldn't rely on it for explicit parallelism.

>>wredue+Ql
Completely uninformed take. Some of the most impressive update notification systems are built off of pass-as-immutable runtimes (for example: phoenix live view + phoenix pubsub). Try implementing that in just about a y other language. You will trip over yourself eight ways to hell

The whole idea of CQRS is to build separate (segregated) pathways for updates. Immutable passing plays extremely well with CQRS. The alternative is the complete clusterfuck that is two way data bindings (e.g. out of the box angularjs)

>>wredue+Ql
Immutability frees the mind from so much baggage when developing that i'm always shocked it didn't become mainstream

>>throwa+0w
I think you both are referring to the same point: you can't update an immutable object, so you have to set up some mechanism to keep changes in sync.

>>tgv+XF
Yeah, and update mechanisms are not created equal. two way data bindings suck because they elide the challenges of distributed consistency.

When you're immutable, you can still delete or replace data.

>>xedrac+Eo
Haskell async is run in IO though in which mutability is allowed. Async itself is mutable.

>>xedrac+(OP)
I'm not sure it's worth it even for most IO bound applications. The first couple of IO bound examples that come to mind (an app doing bulk disk or network IO, eg sequential file access or bulk data transfer) would logically seem to work just as well without async since the bottleneck is the disk or network card or connection.

I'd guess it could be an advantage for high concurrency applications that are CPU bound, but could be made IO bound by optimizing the userspace code. But OS threads are pretty efficient and you can have zillions of them, so the async upside is quite bounded, so this niche would seem smallish.

>>throwa+BI
Immutability “maybe” (and that’s a massive grain a salt, because this is not a specific thing I’ve ever worked on to say any different) having certain use cases where it works well is not the same thing as making literally every single object in your entire application immutable.

I agree that immutability is a tool. My issue with it is when you treat it as a rule.

>>IlliOn+tf
Haskell has full support for IO and mutability. It even has software transactional memory in its standard library.

>>wredue+Ql
> Congratulations, nobody is going to sneakily update an object on you

I've seen Heisenbugs where some random code calls a setter on an object in a shared memory cache. The setter call was for local logic - so immutable update would've saved the day. It had real world impact too: We ordered a rack with a European plug to an American data center (I think a human in the loop caught it thankfully).

Also, how often do you even use mutability really? Like .. for what? Logic is easier to express with expressions than a Rube Goldberg loop mutating state imo.

>>XorNot+k5
Predicting memory usage in Haskell programs isn't actually tricky. At least, I stopped thinking so once I became an intermediate Haskeller. It's not that hard to have a mental model of the Haskell RTS the same as you'd have the JVM.

Having the ability to do so generally is tablestakes for being an intermediate professional programmer imo. In university, I had to draw diagrams explaining the state of the C stack and heap after each line of code. That's the same thing. And I was 19 lmao. It's not hard.

Maybe you're referring to space leaks? I've run into like 2 in my ten year Haskell career, and neither hit prod

I've actually seem more Go and Java space leaks/OoM bugs hit prod than Haskell - despite having fewer total years using those languages than Haskell! Nobody blamed the language for those though :/

>>whatev+X22
>how many Heisenbugs

I suspect, given the real, actual measurements, the number of difficult to deal with bugs is pretty consistent between immutability and mutability. Actual measurements does not support claims of “easier to reason about”, or “reduced bugs”.

>how often do you use mutability

Whenever something should change and I don’t specifically need functionality that immutability might provide (literally 99.99999999% of every state change).

>>wredue+j64
I'm just confused as to what you need mutability for exactly? I get needing it for communicating between processes (STM has you covered there). But for "normal" code that is doing pure logic, what is the benefit of using mutability?

Immutability has some big advantages for pure logic, such as allowing containers to be treated as values the same as numbers. And efficient immutable data structures of all kinds are commonplace now.