4 ms·

> Then there are those dyed-in-the-wool non-Rust developers who would prefer to implement Rust's concurrency-related safety mechanisms in their own favorite lan

by mrkeen 4y ago

> Then there are those dyed-in-the-wool non-Rust developers who would prefer to implement Rust's concurrency-related safety mechanisms in their own favorite language. The book's called "atomics and locks". What language doesn't already have those? If I'm touching those, doesn't that mean I'm already trying to reimplement my own concurrency-safety mechanisms? Howabout Rust implements my favourite concurrency-related safety mechanisms, so I don't need to ever know about atomics or locks.

echelon 4y ago
> Howabout Rust implements my favourite concurrency-related safety mechanisms, so I don't need to ever know about atomics or locks. How on earth are you doing concurrency without touching these two key primitives at some point? Lots of lockless?
- peoplefromibiza 4y ago
  > How on earth are you doing concurrency without touching these two key primitives at some point? using one of the many higher level concepts/frameworks available. - actor model - fork join - CSP etc.
  - estebank 4y ago
    Someone has to implement those frameworks, and those people need to understand pretty much everything covered by this book :)
    - peoplefromibiza 4y ago
      not to disagree or antagonize, but the question was > How on earth are you doing concurrency without touching these two key primitives and not how to write high level concurrency frameworks. I wouldn't trust very much a concurrency framework written by someone who just learned about locks and atomics on a book. I wouldn't even trust myself to write low level concurrent code using locks and atomics. I have 26 years of experience as a programmer and if there's something I've learned is that low level concurrency is really hard to get right, even when you perfectly understand the underlying concepts, and it's best left to real experts that dedicated their career to it. edit: I'm sure the book is great and the authors very knowledgeable and I'm really curious to read it.
      - ecnahc515 4y ago
        Sometimes all you need is an atomic counter though (or lock). Like, for the commonly used Prometheus metrics format, you usually just have global, atomic counters, because it's arguably the most efficient/easiest way to do it. Higher level primitives are nice, but even lower level APIs might be "the right choice" for even high-level problems.
    - mrkeen 4y ago
      They predate rust.
estebank 4y ago
The "About this book" tells you what the book covers. The whole book is available for you to peek at if you don't trust it to correctly summarize itself. As you would expect, Rust does have concurrency primitives, which is why the book shows you how they are implemented and why they are implemented they way they are. In doing so it also teaches you how to do low level things for when you can't use the language provided primitives, like if you're interacting with FFI boundaries or implementing your own lockless datastructure. Your comment is like seeing a link to "Learning Rust With Entirely Too Many Linked Lists" and reacting with "what language doesn't have linked lists?" Edit: I see that you might have meant "why would I reimplement Rust's atomic primitives in another language". Well, some documentation is needed for anyone that will have to implement those language primitives, in existing languages (because there are undressed needs) or in new ones. More documentation and explanation of tricky concepts is good.
tialaramex 4y ago
What sort of things are "your favourite" and why ought Rust to specifically do things you favour, rather than what anybody else might like ? Rust got scoped threads (again), that's a rather nice safe concurrency feature, a way to say "This thread shall only live during this object's lifetime". For example you can give a new HttpConnection to a scoped thread, knowing that Rust ensures the thread ends before the HttpConnection ceases to exist. Before scoped threads Rust wouldn't let you (safely) make threads which use outside objects with a finite lifespan, as it can't be sure the thread won't touch an object which no longer exists. But this sort of book is more aimed at people who are interested in the details you apparently don't care about (or don't want to care about). Somebody has to know how it works to build the higher level mechanisms you desire.
infamouscow 4y ago
There are many practical instances where an atomic is the simplest solution, e.g., shared counters.
seanhunter 4y ago
Maybe the book isn't for you then. Not every book has to be.
- mrkeen 4y ago
  Maybe I was criticising the quoted text, not the book.

by mrkeen 4y ago

echelon 4y ago

> Howabout Rust implements my favourite concurrency-related safety mechanisms, so I don't need to ever know about atomics or locks. How on earth are you doing concurrency without touching these two key primitives at some point? Lots of lockless?

peoplefromibiza 4y ago
> How on earth are you doing concurrency without touching these two key primitives at some point? using one of the many higher level concepts/frameworks available. - actor model - fork join - CSP etc.
- estebank 4y ago
  Someone has to implement those frameworks, and those people need to understand pretty much everything covered by this book :)
  - peoplefromibiza 4y ago
    not to disagree or antagonize, but the question was > How on earth are you doing concurrency without touching these two key primitives and not how to write high level concurrency frameworks. I wouldn't trust very much a concurrency framework written by someone who just learned about locks and atomics on a book. I wouldn't even trust myself to write low level concurrent code using locks and atomics. I have 26 years of experience as a programmer and if there's something I've learned is that low level concurrency is really hard to get right, even when you perfectly understand the underlying concepts, and it's best left to real experts that dedicated their career to it. edit: I'm sure the book is great and the authors very knowledgeable and I'm really curious to read it.
    - ecnahc515 4y ago
      Sometimes all you need is an atomic counter though (or lock). Like, for the commonly used Prometheus metrics format, you usually just have global, atomic counters, because it's arguably the most efficient/easiest way to do it. Higher level primitives are nice, but even lower level APIs might be "the right choice" for even high-level problems.
  - mrkeen 4y ago
    They predate rust.

estebank 4y ago

The "About this book" tells you what the book covers. The whole book is available for you to peek at if you don't trust it to correctly summarize itself. As you would expect, Rust does have concurrency primitives, which is why the book shows you how they are implemented and why they are implemented they way they are. In doing so it also teaches you how to do low level things for when you can't use the language provided primitives, like if you're interacting with FFI boundaries or implementing your own lockless datastructure. Your comment is like seeing a link to "Learning Rust With Entirely Too Many Linked Lists" and reacting with "what language doesn't have linked lists?" Edit: I see that you might have meant "why would I reimplement Rust's atomic primitives in another language". Well, some documentation is needed for anyone that will have to implement those language primitives, in existing languages (because there are undressed needs) or in new ones. More documentation and explanation of tricky concepts is good.

tialaramex 4y ago

What sort of things are "your favourite" and why ought Rust to specifically do things you favour, rather than what anybody else might like ? Rust got scoped threads (again), that's a rather nice safe concurrency feature, a way to say "This thread shall only live during this object's lifetime". For example you can give a new HttpConnection to a scoped thread, knowing that Rust ensures the thread ends before the HttpConnection ceases to exist. Before scoped threads Rust wouldn't let you (safely) make threads which use outside objects with a finite lifespan, as it can't be sure the thread won't touch an object which no longer exists. But this sort of book is more aimed at people who are interested in the details you apparently don't care about (or don't want to care about). Somebody has to know how it works to build the higher level mechanisms you desire.

infamouscow 4y ago

There are many practical instances where an atomic is the simplest solution, e.g., shared counters.

seanhunter 4y ago

Maybe the book isn't for you then. Not every book has to be.

mrkeen 4y ago
Maybe I was criticising the quoted text, not the book.