haimez

Generating code at runtime is often an anti-goal because you can’t easily introspect it. “Build-time” generation gives you that, but print often choose to go further and check the generated code to source control to be able to see the change history.

Are we the baddies?

Java is both compiled (first to bytecode, then to machine code by the JIT) and fast (once JIT compiled).

It stands for “Advanced Persistent Threat” - https://en.m.wikipedia.org/wiki/Advanced_persistent_threat

Delete API calls are free, listing the objects in a bucket to know what to delete is not.

Let’s be a little charitable here- having and raising children has been a much, much more dangerous proposition health wise even at your parents generation to say nothing of your grandparents generation.

10x reduction in latency, higher storage costs with lower access costs (SSD instead of spinning disks). So high I/O, small files situations (with no need for cross AZ access) are where the benefits can be found.

Or like SSD’s vs spinning disks…

Counterfeiting parts, including passing even a small part off as an original OEM one, absolutely enters into it

Yikes. I did have to go down a little rabbit hole to understand the semantics of that builtin (I don’t normally write C if that wasn’t immediately obvious from the question) but that seems like a really questionable interpretation of “this should never happen”. I would expect the equivalent of a fault being triggered and termination of the program, but I guess this is what the legacy of intentionally obtuse undefined behavior handling in compilers gets you.

This seems like a bad idea, because the whole point of an assert is that something shouldn't happen, but might due to a (future?) bug.

And so it’s a bad idea because…?

The whole idea is to notice a bug before it ships. Asserts are usually enabled in test and debug builds. So having an assert hit the “unreachable” path should be a good way to notice “hey, you’ve achieved the unexpected” in a bad way. You’re going to need to clarify in more detail why you think that’s a bad thing. I’m guessing because you would prefer this to be a real runtime check in non debug builds?

…or the nature of the question and corpus?

LLM’s are spitting out responses based on their inputs. It is (or was) shockingly effective, but there is no generalized math processing going on. That’s not what LLM’s are, that’s not how they work.

The other “tabs” here are other airplanes in flight, depending on being able to land before they run out of fuel. You don’t just ignore one and move on.

"Pick two randomly" requires no state. Every thread and server can run the same algorithm without regard for each other.

That’s not quite true. Picking between two “buckets” still requires knowing how many “balls” are in each which is state. That state can be local to each server or global, that state can be accessed concurrently or synchronously, but you still have the same problem to solve.

Hopefully they end up with a German market only SKU before the next generation of hardware ships, otherwise it’s a real missed opportunity.

The cost of time from the interviewers is likely to be more expensive since you have senior people interview candidates for senior roles.

News is just what’s “New”. It’s name is already prefectly descriptive :)

Except basically everyone who takes that sabbatical immediately quits after it’s over. Seriously.

It’s not only uninteresting- it’s wrong. Linear costs of bad decisions can kill a business in so many ways.

They already did, it’s called working from home

My guess is equity holders in Linode fully expect Akamai to destroy the brand, and that’s fine because they’re cashing out today.

His article on the matter from 2021 is quiet helpful in understanding what’s (probably) going on here: https://www.thedrive.com/the-war-zone/40054/adversary-drones...

They didn’t say they weren’t balloons, just that they were calling them “objects” and not balloons. Sure, that could be because they definitely want to emphasize the “we don’t know who owned them” aspect and calling it a balloon would immediately evoke China associations, or maybe they already know they’re not balloons. Either way, they also didn’t say “it wasn’t a balloon”

I think declaration vs use Sue distinction is much more helpful to reason about in this context, and named tuples are a classic example of “if you didn’t declare these tuples to be compatible at definition time, it’s probably a bug to let you pass them around as if they were”

Maybe a low latency hybrid cache & query engine where data is mostly in memory but some computation (eg: aggregation at different percentiles on the fly) with low latency requirements would benefit.

Generally speaking, something where:

1. The data is in memory or can be made to be, for the duration of the need.

2. The overall throughput isn’t limited by some external I/O operation (eg: cache servers might seem like “memory hungry” things, but will bottleneck on network throughput before memory throughput [note: latency is definitely not throughput here]). - the CPU operations involved once data is fetched from memory are very cheap, but also generate a sequential but high volume of writes. Maybe an ideal example is incrementing every integer in a large array by 1 since reads and writes are predictable and SIMD instructions can push the theoretical per clock CPU throughput even higher.

Disclaimer: I might be missing some other scenarios from a lack of creativity. The question you asked got more interesting the longer I thought about it, and I think it might have something to do with why this “Memory Bandwidth Beast” hasn’t yet had its day in the sun.

I don’t think anyone should be shocked that Apple isn’t currently prioritizing adding new features to iPhone 5’s over functionality for newer and forthcoming devices.

They don’t even learn, they confabulate. “Correct” responses are an accident, and there is no notion of (especially medical) correctness involved.

My basic suggestion is that the standard library _should_ be useless at supporting multiple languages, because it’s not a goal that can be achieved for almost anyone’s actual use case. You’re going to have to actually design internationalization into your own codebase in a way that makes sense for your application, and a half-measured implementation just doesn’t have a place at the language core.

Format strings, for example- are essentially compile time macros in rust in order to avoid all the fun kinds of string handling bugs that C’s implementation allowed- but that means no runtime customization without also defining were alternate formats live (and how they’re verified, etc). Not supporting multiple languages is a feature, not a bug. If you need multi language support, you need to a library to define those semantics in a way that fits or use case.

It seems reasonable to me that this is not a compile time constraint, but rather one of tooling and the deployed environment- ie: is the Japanese translation available here at runtime? How? Is there a runtime configuration flag? Is the translations file available at runtime? Is the date formatter configured appropriately?

Maybe if you bake in assumptions about the deployed environment at compile time you can catch errors earlier for your specific environment, but all environments? No. That’s not the responsibility of the standard library and given the language lacks a single specific runtime target- definitely not the responsibility of the language/compiler. This is instead a classic use case for tests and opinionated (optional/third party) libraries instead.