Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Concurrency in Haskell: Fast, Simple, Correct

bitbashing.io

Post reply on HN
Print view View original

61–70 of 129 posts

Re: Concurrency in Haskell: Fast, Simple, Correct

#61

Post by aeonik »

wodenokoto wrote: post #54

I don't know how async is in other languages but I find Pythons async incredibly difficult to use, and I kinda feel validated about how poor chatGPT is at it as well. Is it because it is just a very hard thing, or is it because its a synchronous language, with async bolted on? (I'm talking about a purely language point of view, not from a python VM / GIL point of view)

The easiest language I’ve used for async is Clojure—mostly because the language is immutable by default and ~99% of the code is referentially transparent. That doesn’t magically solve async, but it removes an entire class of headaches by nudging you away from shared state and side effects. You don’t need locks if there’s nothing to lock.

Async is hard, no doubt—but some languages are designed to reduce the surface area of what can go wrong. I’ve heard great things about Erlang, Elixir, and BEAM-based languages in general. They treat async not as an add-on, but as a core architectural principle.

Re: Concurrency in Haskell: Fast, Simple, Correct

#62

Post by alatriste »

internet_points wrote: post #26

https://www.oreilly.com/library/view/parallel-and-concurrent... is a great resource for those who want to go deeper into this

I read that book many years ago, but I haven't looked into Haskell for a long time. Is it still relevant today? I imagine many things have changed in 12 years!

Re: Concurrency in Haskell: Fast, Simple, Correct

#63

Post by Starlevel004 »

wodenokoto wrote: post #54

I don't know how async is in other languages but I find Pythons async incredibly difficult to use, and I kinda feel validated about how poor chatGPT is at it as well. Is it because it is just a very hard thing, or is it because its a synchronous language, with async bolted on? (I'm talking about a purely language point of view, not from a python VM / GIL point of view)

It's because ``asyncio`` is a dogwater library that's barely functional and full of footguns. The ecosystem is about the same quality too.

Re: Concurrency in Haskell: Fast, Simple, Correct

#64

Post by TacticalCoder »

anonzzzies wrote: post #38
declan_roberts wrote: post #21

Earlier quoted context omitted.

I love it because I can spend all my time noodling over types and never ship a product that would have been great shipped in a late night wine-fueled session of 1999 PHP.

Now you would vibe it and ship it during the ol' drink.

[dead]

Re: Concurrency in Haskell: Fast, Simple, Correct

#66

Post by nesarkvechnep »

michalsustr wrote: post #46
nesarkvechnep wrote: post #29

Earlier quoted context omitted.

No reason. OC probably thinks that immutable data structures are always copied when being operated on.

Yes indeed, unless you use ropes or other specialised structures

Not really. You might want to look into “ Purely functional data structures” by Chris Okazaki.

Re: Concurrency in Haskell: Fast, Simple, Correct

#67

Post by speed_spread »

ykonstant wrote: post #42
ilrwbwrkhv wrote: post #4

Rust has a bunch of these while being maintainable.

Isn't concurrency in Rust a notorious pain point? Or am I confusing it with async which is different? [I am stuck in an era before parallelism, so I don't really understand these things]

Correctness in concurrency is actually one of Rust's strong suit. Any pain felt is because Rust is low level and does not prescribe a single concurrency mechanism, leaving each coder to figure out the benefits and constraints of each library.

Re: Concurrency in Haskell: Fast, Simple, Correct

#69

Post by zozbot234 »

mrkeen wrote: post #35
ilrwbwrkhv wrote: post #4

Rust has a bunch of these while being maintainable.

STM is Haskell's feature for safe shared&mutable state. What is Rust's feature for safe shared&mutable state?

Relevant: https://github.com/Marthog/rust-stm which has usage instructions. It's memory safe as defined in Safe Rust, but unlike the Haskell implementation it's not "safe" in a correctness sense, because Rust does not afford the same control about mutability and purity. (At least, not yet - future additions to the language may improve this somewhat.)

Re: Concurrency in Haskell: Fast, Simple, Correct

#70

Post by Philpax »

tasuki wrote: post #49
revskill wrote: post #7

Earlier quoted context omitted.

Why not python ?

No one wants to be a python programmer. It's a practical language to get things done. It isn't a language to make you feel proud of yourself nor about the current state of our industry.

The concept of "the Pythonic Way" indicates to me that there are people who are proud of being Python programmers.

May God have mercy on their souls.

Post reply on HN