carllerche

What if the system freezes between reading the current time from the hardware and the stead_time function returning?

In short, you CANNOT rely on time in any way shape or form for safety. You can only use it as advice & to get liveliness.

Martin's point is that Redlock pays the cost of other safe locking algorithms w/o the benefit of safety.

Martin made no mention of strong vs. eventual consistency.

If you write to a store like cassandra using a monotonic token, the result will converge correctly. If you require to never read "stale" data, you can read / write w/ quorum. There is no linearization in the storage layer in this case.

In this case the lock is not superfluous and you have safety.

Regarding CAS, I said that your argument (in support of redlock) was wrong. I would be happy to respond to a proposed algorithm, but as someone else mentioned, either the storage layer can provide a CAS operation, in which case your lock is not required and the workers read, mutate, CAS, OR if the storage layer has any weaker semantics then it is not possible to ensure safety with a token.

I don't need to, Martin did an excellent job touching on this in his original post, including real world references.

This response is incorrect at a very fundamental level.

First, Antirez claims that requiring the "materialization" store to be able to tie break with a monotonically increasing token requires linearization? This is completely false. The monotonically increasing token allows for eventual consistency. That's the entire point of it. It's monotonically increasing.

For anyone who claims that once you have coordination (locking) in your system you already lost is completely ignoring the research coming out of BOOM (Berkeley Orders of Magnitude). You can design your system to push the coordination out to the edge and way from your "choke points" and use these monotonically increasing tokens to keep your bottlenecks coordination free.

Secondly, Antirez's argument that you can use a compare & swap in a transactional storage layer is also wrong. This is not possible to write safely.

I'm not even going to touch his argument that using system clocks in a distributed locking algorithm is safe...

Looks good. The post did not mention HA (that I saw), which caused the confusion.

Looks interesting. There is definitely a need for something secure to manage secrets easily & efficiently.

I'm not super familiar with Shamir's secret sharing. The post says that the master key is split up across a number of people. One thing that I am confused about is if Vault goes down (possibly in the middle of the night), does it require a quorum of humans to boot it back up?

Here is how we bind the Skylight gem to the Rust bit: https://github.com/skylightio/skylight-ruby/blob/master/ext/...

`thread::scoped` attempts to use lifetimes in order to enforce that values on the parent thread's stack would live throughout the life of the child thread, such that it would be safe to pass references to values on the parent thread to the child thread. However, the actual implementation used unsafe blocks. While this is unfortunate (thread::scoped was pretty cool), it isn't a hit against the Rust borrow checker.

Well, Rust doesn't have any opinions regarding blocking or not. Currently, std::io implements blocking IO, but as you pointed out, Rust allows libraries to implement non-blocking / async paradigms.

Rust has definitely been a pleasure to work with. I have been experimenting with a Future & Stream [1] abstraction in Rust that would allow easily describing complex concurrent and async operations and to allow easy composition, not unlike ES 6 promises.

The interesting thing is that, thanks to Rust's ownership system, it is easy to discover when handles to a future value go out of scope. This allows the library to reuse internal resources to make the overhead of using the library as light as possible.

For example, a Stream is modeled as a sequence of futures (more specifically a future of the next value and a new stream representing the rest of the values, kind of like lazy-seq in clojure but async), but instead of allocating one future for each iteration of the stream, the same internal structure is reused while still being able to expose this API.

[1] https://github.com/carllerche/eventual

Well, http://github.com/carllerche/curl-rust has been working great for me. Sure, it uses libcurl so it isn't pure Rust, but that doesn't make it not work :-)

This would only be possible on very new linux kernels (that provide user namespacing)

Rust uses LLVM for all code generation and optimization. So, in that respect, it is very mature and I personally have never hit an issue.

Actually, Rust is much closer to the system than Go is making it possible to implement lighter weight web services using Rust than Go. Rust features like not having a GC allows for much more predictable performance.

Go's concurrency features are nice if it's your kind of thing, but will get in your way when hitting that "last mile" of performance. For example, if you were to implement something like haproxy, you would probably want to use Rust over Go for performance.

a) no to cargo exec b) If you have a better solution for bundler, please open an issue and suggest it. c) There are few simple solutions to avoid `bundle exec`, which is mostly there to make things easier when getting started. I'm sure you spent a few moments to get to know your tools, so you must already be aware of these.

Ordinary users would do it because many corporate sites used to direct them to do this as a fix for their browsers displaying invalid characters.

Instead of memoizing in the server you could memoize in the browser and use socket.io to ask connected browsers if they have a memoized value for a given fib number. That would get you around the limitations that bascule mentioned.

I don't think I would consider package dependencies to be magic. Also, the solution to this whole problem is simply `bundle install --binstubs && bin/rake test`. I don't really think there is much to freak out about.

Have you ever actually taken part of an online discussion?