3,920 karma · joined August 29, 2015
the parts I was most proud of was (a) your score was directly related to the number of tests passing, so you know in advance what your score would be and could decide how much effort. (b) every assignment came with a relevant visualization that showed things like the routing table as a directed graph, or the TCP sequence diagram. I was available in the lab for a good 2-3 hours a day on weekdays to answer questions.
I think some of the students got a pretty good picture of how things worked, but the overwhelming opinion was that it was just too much work. a lot of the students just copied off each other. we also had quarters, so ...
its been very sad for me to see standardization get ignored, and the implementation become the point of reference. for a long time the only way to implement QUIC was to try to extract it from the Chromium code base - a pointless waste of time. but they spec for years was a couple of pages of meeting notes and a sample compression dictionary.
if we continue down this road we are impeding our own ability to evolve. if compatibility is defined by the implementation then were left with nasty balls of antiquated source that we carefully move around and try to plumb into our new environments, but no one really understands.
at the core, things like IP are very straightforward. we can and should specify the semantics of every bit, and have a wide variety of other implementations to test against. this provides a path for us to build new techniques and environments that are still useful in the world that exists today.
my shop is next to a cabinet maker who does most of is work in that same birch hard-ply. he's got the full sheet router, but he only really uses it for special projects. its mostly just the big table saw. he's got a subcontractor that just does drawers. most cities have several of his kind of shop, and while they don't have a design website they generally work from napkins. I think that birch ply has gotten really expensive in the last 5 years though.
the other really handy thing here is that it very straightforward to differentiate datalog rule sets. so if you change a fact, you can run a smaller solution that tells you which consequences are affected by the change. under the assumption that the evaluator is pure, we don't need to keep the support graph as you suggest, we can just generate the deltas from evolution of the differentiated form.
detailed provenance can be of real application utility, but if you just care about the accounting, keeping track of the number of supports for each fact is sufficient.
another model which is fun is to make the version of the database (monotonic time) an explicit field in your base facts, assuming you can afford to keep the whole history. a deletion then is just a negative-support, and you can ask questions about the state of the world at any time.
what I find strange is the adoption of a standard synchronous dram interface. that's a horrible left over piece of architecture that severely constrains the applicability of this device. control flow on the dram side can't initiate any transactions on its own, or respond after work has been done - its like usb, except with a hard limit on the response.
that severely limits the utility of the in-memory processors to doing things like encryption and compression - but even then those impose delays that effect the consistency model across that interface.
idk how much NOx a GW or two of low efficiency (20%) gas turbine units produces, how wide that plume might be, and what the envionmental impact might be. but if we employed a few people that practice doing this kind of I'm sure they could tell us with high confidence.
I grew up in the 70s, and my father was a Nixon supporting environmental engineer. At the time the amount of nitrogen and sulfur being emitted into the air in the northeast was turning surface water into acid. a ph of 6 was getting quite common, 4 wasn't unusual, and if you were in a bad spot it was approaching 1. Not only would that water not support life, or be unsafe to drink, but it was actually unsafe to touch.
So if we were reasonable people we would look at the economic activity and the upside of burning these gasses, and add up the numbers and based on past experience make a very reasonable estimate of the impact, and make a decision.
but we fired all those people, and we're very much not interested in having this discussion. I fail to see how that's a win for anyone except the polluter.
but to say that the laws and precedence aren't largely concerned with building some semantic context, and that lawyers don't build chains of reasoning in that framework to prophet their positions is absolute nonsense.
you're positing a world where a judge just rules entirely on feels, and I think most judges would be quite offended by that notion.
but that was still way too much to ask. I'm afraid that if you insist on reducing the solution space to just 'it magically goes away and no one has to think about it', even the mighty AI might struggle. why don't fire up Claude and ask it?
ok, I have a large local container of records that I want to stream over a back pressured channel. now we clearly have a problem that the iterator needs to be long lived, and I don't really want to serialize all accesses to the collection for a streaming operation that may never terminate.
for this particular domain I don't actually care about serializability of the iterators view of the collection. I clearly don't want the container to be left in an erroneous or inconsistent state, but otherwise anything goes.
all the iterators for all the standard rust containers have lifetimes bounded by the container (batch), and because they all represent internal state, they all have to be mutable. and in this case they need to be async also.
I don't think there is an 'idiomatic' way to represent that access pattern, and it kind of necessitates writing ones own container. if there is a good answer to this I'd be curious to hear it, but I consider this one of the major personal failure modes for rust, which is 'oh, yeah, well, in order to figure that out to need to understand [long list of compiler instristic property types and runtime behaviour], which isn't super pragmatic.
since I'm here, I've already wasted words here talking about the dismal async situation, but I think more important to me as a systems programmer is the lifetime abstraction. It think its great to put a name to it and try to put rules around lifetimes - these are traditionally implicit things that we reason about _outside the program text_, and that's a real bother. however everything I do is state management, and the lifetimes of those states (files, connections, higher level sessions) don't directly correspond to the lexical calling stack. the only tools that rust gives me is Arc, which some with a whole set of busy caveats, or trying to thread several lifetimes through the entire call path - a road that I've been down and abandoned for readability and maintenance.
now you can argue that rust would prefer that I use a thread per object, and while that might be workable, that a pretty strong and side-effecting constraint to apply to all of the programs in my domain.
anyways I ended up keeping the last key issued, and for every new record, paying the logn cost to get to approximately where I was perviously. which brings up another general complaint. as imperfect as it is, sometimes I want to just stand sometime up and look at it. I don't want to spend 3 weeks coming up with sharing policies and structures that work well with rust. I want to look at it and measure it and count its defects in my head and decide what to do next. in rust I kind of have to decide up front what I'm building, and while that might be an excellent thing to encourage in some contexts, I don't think it is in all contexts.
if the base domain is sets we do get a lot of nice constraints, particularly with semantics around projections and if we want to support bags, its trivial to add a counter for the number of identical records as an additional column.
if we want to support sets in bag-land, we could imagine an extension which support 'row unique' on insertion. or we can use a 'unique results' post-filter. so there are paths, but its a lot less clear in a SQL context.
you insist that your data demands bags. I really prefer to work in sets and bagginess is always just a source of crappy errors for me. shouldn't we really support usable models for both regardless of the underlying storage?
I've also had the converse experience, where I know full well that the structure I'm trying to impose is correct and quite efficient, but its part of the space that rust doesn't cover.
Rust is great. It's a noble attempt to bring a degree of correctness to a problem space that suffers from a great deal of slop. But to pretend that the model is complete, or that the design decisions that were made are perfect in every way, is just wrong. That the rust compiler and runtime can't support my construct isn't really an absolute value judgement on that idea in the first place. The rust compiler isn't really an oracle that tells you whether something is right or not in an arbitrary value system.
we can't seriously believe that if we just adjusted the story a little bit this way or that, that the message would actually click and people would begin to try to minimize the tragic cost to future generations.
this is happening now. blaming the messenger for not being appropriately fawning, or curt, or amusing is kind of irrelevant at this point. maybe we can learn to do a better job next time there is an issue that's going to radically effect everyones lives for the foreseeable future.
you can mock my beliefs, you can try to convince how misguided they are, but its really outside the minimum rules of discourse to tell me what I actually believe