Lindsey KuperMar 19

I've gotten like four emails now from a professor in France who watches my distributed systems videos. The most recent one, today: "With time passing, I came a fan of your class on distributed systems CSE138. It is an amazing work, and I am recommanding it to my students as a class very consistent with what we are teaching. Also your american is slow and very understandable, so it is also a reason to listen your videos !"

My American is slow and very understandable 👍

Show threadLindsey KuperMar 19

Questions he's asked me:

- can he use one of my blog posts to help design an exam? (yes)
- does Liquid Haskell have any particular support for reasoning about physical time? (nope)
- are the sequence numbers used by Paxos the same thing as Lamport clocks? (not quite)
- do I have a video on Chord? (not specifically, but I have one on consistent hashing)

I love this guy

Show threadalecsMar 19
@lindsey What would "reasoning about physical time" look like? Is there a PL that allows that?
Show threadLindsey KuperMar 19
@bool Well, some languages have a more or less "native" notion of "time", which might or might not correspond particularly closely to physical time. There's stuff like the ChucK language, but I honestly don't really understand it!
Show threadTed MielczarekMar 19
@lindsey @bool would it be fair to read "physical time" as like "unix timestamps" or something similar?
I'm not familiar with the distributed systems side of things but Rust, for example, has a distinction between `std::time::Instant`, an opaque monotonically-increasing timer from which you can calculate durations, and `std::time::SystemTime`, which is basically "a timestamp I got from elsewhere" (e.g. the filesystem).
Show threadLindsey Kuper
@tedmielczarek @bool yeah, various languages have standard library functions that provide access to some monotonic clock source provided by the OS. I think that's what `std::time::Instant` is; I wasn't thinking of it as a language-level concept.
Mar 19 at 8:32pmWeb