15 ms·

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitat

by yetkin 6y ago

The problem is not the threads, it is the mutations of variables which boost the complexity of the code. So a tutorial on creation of theads actually an invitation to hell. Nothing is cool about it. Cool thing is achieving concurrency without threads/race conditions/shared memory

agumonkey 6y ago
Do you use other paradigm / languages ? (clojure comes to mind, but maybe others)
- itronitron 6y ago
  For Java at least, the Java Concurrency API is preferred.
- mrjoelkemp 6y ago
  Actor model with Elixir/Erlang and the BEAM VM.
- abhishekjha 6y ago
  Akka actor framework comes to mind. I am in the process of learning it and it is definitely simpler to wrap your head around it.
- rowls66 6y ago
  I'll add Pony to the list. This language uses the actor model like Akka and Erlang, but allows for the safe sharing of data between actors enforced by an an ingenious use of the type system. The result is an actor programming model with better performance than Erlang because mutable data can be safely shared. I have been a long time Java developer, and I have worked a lot with highly concurrent code. Pony really opened my eyes to what was possible. Unfortunately, the language, standard library and runtime is still pretty immature. It does however have very good 'C' interop. So for some problems it would be a very good fit.
FpUser 6y ago
The concepts of threads and concurrent data access is simple enough for any decent programmer to comprehend. There is no hell here. Sure there are some complex cases but complex cases will arise in many situations when programming things. And achieving concurrency without shared memory is impossible in general case. Sure it is possible to isolate such access to a separate layer and make it transparent for the rest of the program but someone still has to program such layer.
- JackFr 6y ago
  The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.
  - FpUser 6y ago
    If the resource is shared and being accessed from many threads and is both written to and read from then it is the correct behavior to to lock it with the proper type of lock at access time. Depending on resource it might be possible to split it into few with more granular access. As for novices: they are called that for reason and supposed to be under supervision rather than allowed running wild.
    - secondcoming 6y ago
      Why is this being downvoted? It's the truth. HN needs to only allow downvotes that have an accompanying explanation comment.
      - teslalang 6y ago
        As with most other compromised social sites, no badthink allowed here and how dare you.
      - FpUser 6y ago
mrfox321 6y ago
Can databases be efficiently implemented without shared access? Can message passing accomplish this at the same level of performance? although I agree that simplifying resource access should probably be considered before fully shared state.
- mrkeen 6y ago
  > Can databases be efficiently implemented without shared access? Let me ask a different question: Why did databases take off in the way they did? Sure they persist stuff to disk, but so do files. What they offer is a concurrency model so good that you almost never think about it. Beginner programmers can competently write large, concurrent systems by writing single-threaded programs which are backed by a central DB, without even knowing the term "race condition". If beginner database articles told users how to make database Threads, Thread groups, and how to signal and catch interruptions, I don't think databases would have enjoyed nearly as much popularity. While Threads are fundamental to Java concurrency, I kinda agree with yetkin's point. It introduces the Thread footgun without even paying lip service to the problems of shared, mutable state.
deleted 6y ago
[deleted]
Nursie 6y ago
There's a lot cool about threads, and you can learn to implement them well. Threads handled well do not need to have race conditions, and race conditions/deadlocks are also very possible in distributed, message-passing systems.
cle 6y ago
A computer is a mutation machine, you cannot escape mutation by hand-waving it away. If you are writing programs in which you can achieve concurrency without threads and shared memory, it’s because you’re building on the shoulders of all the engineers who didn’t hand-wave it away. Many of us, due to product requirements, don’t have the luxury of using higher level abstractions like that.
- mrkeen 6y ago
  And yet we're comfortable hand-waving GOTO away - that is, not calling computers GOTO machines.
  - cle 6y ago
    There are thousands of engineers (at least) who use it or its equivalent every day. Just because they’ve built abstractions that allow you to ignore it, doesn’t mean nobody has to deal with it anymore.
    - lostcolony 6y ago
      But that's identical to what he's saying; he's not saying no one has to deal with mutable memory. Just that most developers who need concurrency shouldn't have to. Same as registers, GOTO, etc.
      - cle 6y ago
        That's not what they said. They said "nothing is cool about a tutorial on creation of threads", and that the cool thing is "achieving concurrency without threads/race conditions/shared memory" which ironically is only enabled by all the engineers who spend their time working on and maintaining those "uncool" things. If they don't need to use threads, then good for them. But to dismiss threads and learning material about threads as "uncool" is just silly. The thing that enables that misunderstanding is all the work that's done on them in the first place.
Igelau 6y ago
All the cool people are in Hell. Only go to Heaven for the climate.

by yetkin 6y ago

agumonkey 6y ago

Do you use other paradigm / languages ? (clojure comes to mind, but maybe others)

itronitron 6y ago
For Java at least, the Java Concurrency API is preferred.
mrjoelkemp 6y ago
Actor model with Elixir/Erlang and the BEAM VM.
abhishekjha 6y ago
Akka actor framework comes to mind. I am in the process of learning it and it is definitely simpler to wrap your head around it.
rowls66 6y ago
I'll add Pony to the list. This language uses the actor model like Akka and Erlang, but allows for the safe sharing of data between actors enforced by an an ingenious use of the type system. The result is an actor programming model with better performance than Erlang because mutable data can be safely shared. I have been a long time Java developer, and I have worked a lot with highly concurrent code. Pony really opened my eyes to what was possible. Unfortunately, the language, standard library and runtime is still pretty immature. It does however have very good 'C' interop. So for some problems it would be a very good fit.

FpUser 6y ago

The concepts of threads and concurrent data access is simple enough for any decent programmer to comprehend. There is no hell here. Sure there are some complex cases but complex cases will arise in many situations when programming things. And achieving concurrency without shared memory is impossible in general case. Sure it is possible to isolate such access to a separate layer and make it transparent for the rest of the program but someone still has to program such layer.

JackFr 6y ago
The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.
- FpUser 6y ago
  If the resource is shared and being accessed from many threads and is both written to and read from then it is the correct behavior to to lock it with the proper type of lock at access time. Depending on resource it might be possible to split it into few with more granular access. As for novices: they are called that for reason and supposed to be under supervision rather than allowed running wild.
  - secondcoming 6y ago
    Why is this being downvoted? It's the truth. HN needs to only allow downvotes that have an accompanying explanation comment.
    - teslalang 6y ago
      As with most other compromised social sites, no badthink allowed here and how dare you.
    - FpUser 6y ago

mrfox321 6y ago

Can databases be efficiently implemented without shared access? Can message passing accomplish this at the same level of performance? although I agree that simplifying resource access should probably be considered before fully shared state.

mrkeen 6y ago
> Can databases be efficiently implemented without shared access? Let me ask a different question: Why did databases take off in the way they did? Sure they persist stuff to disk, but so do files. What they offer is a concurrency model so good that you almost never think about it. Beginner programmers can competently write large, concurrent systems by writing single-threaded programs which are backed by a central DB, without even knowing the term "race condition". If beginner database articles told users how to make database Threads, Thread groups, and how to signal and catch interruptions, I don't think databases would have enjoyed nearly as much popularity. While Threads are fundamental to Java concurrency, I kinda agree with yetkin's point. It introduces the Thread footgun without even paying lip service to the problems of shared, mutable state.

deleted 6y ago

[deleted]

Nursie 6y ago

There's a lot cool about threads, and you can learn to implement them well. Threads handled well do not need to have race conditions, and race conditions/deadlocks are also very possible in distributed, message-passing systems.

cle 6y ago

A computer is a mutation machine, you cannot escape mutation by hand-waving it away. If you are writing programs in which you can achieve concurrency without threads and shared memory, it’s because you’re building on the shoulders of all the engineers who didn’t hand-wave it away. Many of us, due to product requirements, don’t have the luxury of using higher level abstractions like that.

mrkeen 6y ago
And yet we're comfortable hand-waving GOTO away - that is, not calling computers GOTO machines.
- cle 6y ago
  There are thousands of engineers (at least) who use it or its equivalent every day. Just because they’ve built abstractions that allow you to ignore it, doesn’t mean nobody has to deal with it anymore.
  - lostcolony 6y ago
    But that's identical to what he's saying; he's not saying no one has to deal with mutable memory. Just that most developers who need concurrency shouldn't have to. Same as registers, GOTO, etc.
    - cle 6y ago
      That's not what they said. They said "nothing is cool about a tutorial on creation of threads", and that the cool thing is "achieving concurrency without threads/race conditions/shared memory" which ironically is only enabled by all the engineers who spend their time working on and maintaining those "uncool" things. If they don't need to use threads, then good for them. But to dismiss threads and learning material about threads as "uncool" is just silly. The thing that enables that misunderstanding is all the work that's done on them in the first place.

Igelau 6y ago

All the cool people are in Hell. Only go to Heaven for the climate.