Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
acconsta
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
121.
▲
by
acconsta
11y ago
>Rust is targeting more than one domain. Concurrent IO is not important in all domains. Well, what domains is Rust targeting? Rust still isn't a good fit for embedded/kernel stuff without allocators and OOM handling (not to men
122.
▲
by
acconsta
11y ago
Since A doesn't have quorum, writes on the A side of the partition are impossible, and the data in B cannot go stale (but operations can continue through the new master in B). That's the essence of the CAP theorem's consisten
123.
▲
by
acconsta
11y ago
>The C/C++ libraries you're holding up as examples get no compiler support. You can open VS 2015 today and use C++ coroutines backed by Microsoft (and their compiler, which is developed alongside their standard library). And
124.
▲
by
acconsta
11y ago
>Forget to update that 3 after fiddling with the channels? Deadlock To be fair, how long would that take to debug? >Forget to unlock a mutex when dealing with shared data? You'll note there are no mutexes. RAII mutexes are great
125.
▲
by
acconsta
11y ago
>The same approach can and does exist in Rust Without the documentation, stability, portability, quality guarantees, and compiler support (that's a big one — code generation for coroutines needs to be good) of a standard library. &g
126.
▲
by
acconsta
11y ago
>Rust originally did have the same thread model as Go baked into the language and standard library Ehhhhhh not quite. Go provides one threading API, and it's green threading. Rust tried to provide the both green threading and na
127.
▲
by
acconsta
11y ago
Let me be more precise then. Goroutines enable a fan out pattern in which each task, even small ones, is a separate asynchronous routine. Tasks fan out from a coordinator routine and their results fan back in: https://talks.golan
128.
▲
by
acconsta
11y ago
>your apparently-perfect channels I've never used Go, but it has some interesting concurrency ideas. So do Node and Erlang. I naively expect Rust to adopt the best ideas from each. >One can use channels to get all four of the con
129.
▲
by
acconsta
11y ago
Putting the word "semantically" in front of deadlock doesn't change its meaning: https://en.wikipedia.org/wiki/Deadlock Either way, redefining the word does nothing to make mutexes and native threads saf
130.
▲
by
acconsta
11y ago
If deadlocks are so easy to fix why do they happen so often ? Seriously, how many applications have you seen hang in your life? (not to discount the role of other race conditions in causing hangs, which the borrow checker also can't c
131.
▲
by
acconsta
11y ago
>You act as though deadlocks in Rust are trivial and pervasive, but they aren't Writing nontrivial multithreaded code using thread and mutex primitives is very hard to get right (not only due to data races, but also race conditions
132.
▲
by
acconsta
11y ago
>An infinite loop is a deadlock It isn't. I don't know what else to say: https://en.wikipedia.org/wiki/Deadlock
133.
▲
by
acconsta
11y ago
>That is definitely too much runtime Is it incompatible with native threads? (no) Does it affect non-coroutine functions? (no) Does it have any effect whatsoever when not using the library? (no) I encourage you to look over the code befo
134.
▲
by
acconsta
11y ago
This is all a response to: https://news.ycombinator.com/item?id=10192042 Reasonable people can disagree about what "safe" and "easy" mean, but I don't think Rust's concurrency primitives are ei
135.
▲
by
acconsta
11y ago
SIMD, lock free data structures, and ARC pointers are great. But what's the timeline for concurrent IO (either async or coroutines)? Preferably one that is stable, portable, and efficient (mio isn't the first two). >Statically
136.
▲
by
acconsta
11y ago
>Rust tries to avoid stuffing everything into the standard library That's a valid philosophy, but also one that leads to problems with fragmentation, quality, portability, dependency management, and compiler support. Concurrent IO i
137.
▲
by
acconsta
11y ago
And that's a great achievement! If there were a Nobel prize for practical use of a type system, the Rust team would get it. But overselling it ("Rust goes out of its way to make it easy and safe to write multithreaded code&quo
138.
▲
by
acconsta
11y ago
That's great. I look forward to seeing them evolve and hopefully become standardized. >(And the language can't have exactly the same stuff as Go or Erlang without adding a runtime, which is contrary to the goals of the project.
139.
▲
by
acconsta
11y ago
>It's incorrect to say that Rust hasn't prioritized higher-level concurrency tools I think it's a fair characterization given 1.0 shipped without them, and there doesn't seem to any timeline for standardization (pleas
140.
▲
by
acconsta
11y ago
In general, there are many reasons (fragmentation, quality, portability, dependency management, compiler support) it's preferable to have concurrency tools standardized. Standardization is only going to get harder in the future. Specif
141.
▲
by
acconsta
11y ago
The Rust community makes a car: "Check out our awesome new car! It makes driving ' easy and safe '!" "Does it prevent crashes?" "No, that's impossible! But here, look at our onboard computer that pr
142.
▲
by
acconsta
11y ago
>Rust provides many higher-level concurrency mechanisms I'm looking at the standard library and I see only threads and channels. Is there anything higher level? Parallel map, reduce, etc., something like OpenMP?
143.
▲
by
acconsta
11y ago
Does Rust do anything to prevent deadlocks?
144.
▲
by
acconsta
11y ago
Interesting. How does Rust prevent the cyclic reference counting issues that led Chrome to adopt Oilpan?
145.
▲
by
acconsta
11y ago
I feel like there's a disconnect between the HPC community, which has publicly deployed these techniques for years, and the broader tech community. Even some enterprise hardware uses InfiniBand (with kernel bypass) these days. Yet you
146.
▲
by
acconsta
11y ago
The cost of kernel I/O isn't just the direct cost of time spent in the kernel. Even a really, really fast kernel will pollute the CPU caches and TLB.
147.
▲
by
acconsta
11y ago
The Arrakis team did it with Haproxy, Reddis, and Memcached, but in a research operating system: http://people.inf.ethz.ch/troscoe/pubs/peter-arrakis-osdi14.... BSD has had userland networking for a while: http:&
148.
▲
by
acconsta
11y ago
>But as others noted, for most people who aren't cloudflare this doesn't really matter. Aren't most web applications I/O bound? The Arrakis team sped up Memcached and Haproxy quite a lot by bypassing the kernel. It se
149.
▲
by
acconsta
11y ago
>trying to delete old messages is complex and sometimes impossible I'm not familiar with ZeroMQ's data structures, so forgive my ignorance. At the high water mark, why can't the consumer throw away old messages instead of
150.
▲
by
acconsta
11y ago
ZeroMQ is a C++ library written by a guy who hates C++: http://250bpm.com/blog:4 He later rewrote the whole thing in C: http://nanomsg.org/
More ›