hderms

I'm almost positive that's bullshit because I spent half of my life as a "night owl", convinced it was just something inherent to me. After my wife took a job that had her waking up at 4am, and the requisite adjustments to her bedtime, I found myself totally fine with going to sleep at 10am or earlier everyday.

In a lot of ways an early bedtime, or an average bedtime, is preferable to staying up to the wee hours, but given the context I couldn't see the benefits until I had experienced it myself for a few months. So in my opinion, if there is some kind of genetic marker for chronatype, it's either not very influential, only expressed in a subset of the populace or largely BS.

Presumably people care about write speed because it's typically harder to scale up than read speed as there are just less tricks overall that can be applied.

Like we can assume the overwhelming majority of applications writing to a database are interested in durability. A good portion of those could tolerate eventual consistency on reads, for instance, which means there are considerably more ways outside the database to improve read performance.

It is "code that changes together" but also an expression of which code depends on what and in what kind of manner does it do so (e.g. is one subsumed by the other or is used by 3x other modules). Understanding where things live is also a statement on the composability of the code and how many assumptions about the outside world that the interfaces make.

It's also worth noting that there's likely not one single "correct" organization/taxonomy, and certainly not one that's static and guaranteed to last forever. It truly is one of the most complex parts of programming because it's subjective, subject to change and is in a lot of ways right through the center of what it means to abstract something in the first place. I don't think there are any simple answers because it's equal parts philosophical and mundane.

Software mixes things that model the real world, convenient fictions, abstract truths and guilty hacks and I believe trying to make sense of it is at least as much an art as a science.

I think that would be preferable but depends on the use case

Birthday paradox could play a role if there's enough content out there

This seems like a really great case for property based testing and/or fuzzers. Randomly generated output should virtually never flag copyright (and would be rare enough that you could manually assess if it was accurate or not, likely). The core utility of system like this, which puts an enormous amount of leverage in the hands of automated decision making must be robust against things like this.

It's a challenging book and really pushes abstract thinking on a level rarely encountered.

Yes, it's an introductory text in some sense because it introduces you to a dizzying array of subjects in computing, but imo, it's not the equivalent of a typical introductory course in Chemistry or something. It's hard, especially if the things it goes over are new to you, and I think few people would think failing to grok it the first time around implies anything about your suitability as an engineer.

I think an example of what the commenter is describing is something like:

1. User clicks "buy now" for whatever is in their shopping cart 2. Client generates some kind of transaction ID representing that they wanted to purchase the contents of the shopping cart (could be deterministic ID) 3. Client submits this request to the server 4. Server persists the intention to start processing the purchasing of the shopping cart with transaction ID of X 5. Server synchronously or asynchronously starts handling the side effects of the purchase 6. If at some point the client got an error message it can still submit the same request with the same transaction ID to retry and even if the initial request was received (but perhaps lost before getting to the client) it's cheap and easy to make it idempotent by using the transaction ID

Race conditions would be made more difficult by having everything idempotent based on the transaction ID and having the transaction ID (optionally) generated deterministically.

2 phase commit is an extremely heavy weight pattern and finds far less use than something like the above.

Isn't the whole reason you're mentioning actix-web because the community mostly balked at the amount of unsafe code in it? Surely that should be some evidence that the norms in Rustland are qualitatively different in many ways to what you'd find elsewhere?

Is it really true that concerns around UUIDs as primary keys are wholly irrelevant? Maybe I'm working off outdated information but in high scale environments there are a lot of downsides primarily related to the random write patterns into B-trees causing page splitting and things like that.

Really liked this article. Mechanical-sympathy driven development.

Presumably as long as FFIs are based on C calling conventions and running native instructions it would be unsafe. You could imagine cleaner FFIs that have significant restrictions placed on them (I'd imagine sandboxing would be required) but if the goal is to have it operate with as little overhead as possible, then the current regime is basically what you end up with and it would be decidedly unsafe.

I'd say there's a fair amount of public drama but the actual community is pretty chill nowadays i.e. gitter and the like

Yeah it's unnerving because there are many great, real accomplishments from people in India, and no doubt many more to be found in the future. But dreaming about a special destiny inherited from the past doesn't necessarily require the dreamer to think about the here and now and what responsibility they may have to bring about the future we all desire.

It's dangerous because it simultaneously pacifies people towards the active role they should take in creating the world they will live in but also promises them they are the would-be inheritors of some mythical past, and that others are unlike them in that way.

As always we gotta work together and look towards the future, not the past. Basically, if you want to live in Star Trek, at least.

yeah all the other stuff is fluff if a language doesn't have a compelling story about tests. As much as I love static typing and algebraic data types, they don't really prove that the behavior of the code is actually what is expected.

Doubly so with a language that attempts to bring distributed programming to the base level of the language. How do you test distributed programs in a way that simultaneously doesn't require everything to be an integration test but also gives you certainty that you aren't creating loads of bugs? This is an example of something Ballerina could have excelled at if it was given priority.

One major difference is it's hard to "supe up" an old computer. Harder in general for the layman to repair or modify means you are more likely to need a fully functioning device to be able to use it, less gray area. Also cars are inherently harder to store so there are less of them floating around at any given time if they aren't immediately serviceable they might get junked or otherwise rust into pieces.

That being said writing software for "dead" platforms might level that out

man, I love Alan Watts. We're so lucky to have so much of his actual speech recorded as the tone of his voice and the way he communicates ideas are really fascinating

what about if you throw in async IO into the mix? seems like you'd have to have some kind of vmware-like virtualization where you record all IO interrupts into a linearalizable log

I went once at about 3-4PM and also came away feeling like it was a bit understaffed. One worker and about 8 people in there eating. I didn't have to wait a crazy amount of time so maybe it's fine though, gyudon doesn't take a long time to prepare if some ingredients are prepped

If you like this article you should check out the AWS Builders library https://aws.amazon.com/builders-library

It is absolutely full of really interesting topics that don't get covered frequently enough other than in footnotes or in overly simplified hand-waivey explanations. AWS has done a great job in trying to demystify some complex topics.

Location: Chicago

Remote: Yes

Willing to relocate: potentially, but not immediately

Technologies: Scala, Ruby, SQL, Docker, Kubernetes (using, not operating), Rust (beginner)

Resume: https://www.linkedin.com/in/dermot-haughey-07238b51/ https://github.com/hderms

Email: in bio

What do people commonly discuss on it?

It actually isn't really that unusual to have things like this in a statically typed language. Scala and Haskell have similar limitations with tuples

It's looking like Rust is here to stay

I genuinely have no idea why that would be abhorrent, except to anti-vaxxers. Can you explain?

Yeah I really don't know because OCaml already has async constructs. It doesn't seem like it should be a dealbreaker for most. That being said, it has a reputation for being extremely performant so it might just be that people feel like it's so close to being usable in a lot of situations it currently isn't so there is more aggregate desire to allow for multicore execution

Probably easier to reason about as a programmer, at least in my opinion

Seems like it would either need to be append only or have some kind of snapshot isolation

Wouldn't that presumably cause energy costs to skyrocket because of all the overhead you get from going from multitenant machines to dedicated ones? Even if the capex is compare I'd imagine it would be hard to get the opex to be competitive

The algorithm design manual by skienna is a popular choice. The first half is more instructional regarding different classes of algorithms and datastructures and how they should be used while the second half is like an encyclopedia of descriptions of various algorithms. It's a very approachable read and I've found it to be a great book, all around.

A lot of people recommend the super heavy tome textbooks, which could be useful, but I feel like from your description you'd be better off with this