bitwalker

They seem to be much less active on hot days compared to cooler days in my experience - though I can't say why. I've definitely observed a difference over the years though.

That said, whether it is hotter or cooler doesn't make much of a difference in terms of how you go about your day - you pretty much have to assume you can encounter them regardless.

The benefit is that floats are allowed to be unboxed values - without NaN-boxing, you must heap-allocate them. The tradeoff is that immediate/unboxed integer values end up being smaller than the full machine word range (i.e. you have either a 24-bit or 48-bit mantissa you can use to hold data), but that's usually worthwhile because most integers are small anyway, so you box larger ones. Similarly, pointer values can't use the full address space, but that's also usually worth it since rarely do you actually need to do so in VMs where this technique is used.

Using unsigned integers is only a better choice if your VM doesn't need efficient floating-point operations.

AIUI, that is what the MIR formalization work is about, and it seems to be moving along fine. My impression is that covers essentially all the interesting parts of Rust worth specifying formally.

Nobody is out here arguing that privacy is important because they want to make it easier to get away with things that are immoral or criminal. The importance of privacy is in retaining as much control over what information you share with others as possible, especially with the public at large, corporations, and the government. The information you wish to control is typically the kind that is sensitive in nature: PII; browser history, authentication secrets; what banking institution(s) you use; what accounts you have and their identifiers; financial information (what assets do you have, what are they, and how much are they worth, likewise with debts); spending patterns (where you shop, how often, how much do you spend); political affiliation and activities; religious beliefs and activities; how often do you travel, where do you go, and how do you get there; what is your daily routine/schedule, and how frequently do you deviate from it, etc. The list goes on and on.

Some of that information you might be totally fine with anyone knowing, such as your political leanings or religious beliefs. Others might be deeply uncomfortable with that being shared with just anyone. I assume you'd agree with me that at least some of the information I listed above is unambiguously of the variety that deserves privacy, i.e. you control who has access to it, and when.

Some things that should be generally private (e.g. financial activity), might need to be conditionally shared with certain parties (e.g. the government) - you might be fine with the IRS knowing details about your financial activity for purposes of taxation, but be understandably pissed if you found out that they were then making that information freely available to anyone that asked - because they have taken away your control over that information. I'm not saying that is actually the case, it is just an example.

Lastly, the more information about yourself that is effectively public information (either because you don't keep it private, or someone else has made it public without your consent), the easier it is to uncover other things that you do consider private. If someone can monitor everywhere you go, they can build a picture of you as an individual. Maybe you don't share your religious beliefs with others unless asked, but if someone knows that, e.g., you go to a specific church every Wednesday and Sunday, they now know your specific denomination and that you are more involved than the sort of person that only shows up on Sunday mornings, or only once a month, or only on holidays, etc. That information can be used to target you, either for innocuous purposes like advertising products to you that sell predominantly to that demographic - or for more malicious purposes, like running a scam against you that appeals to your specific beliefs, or in some cases, violence. That may seem unlikely to you, but you may also benefit from not being a minority that is prone to being targeted in such a way - the right to privacy ensures that we retain control over the information that can be used to target or hurt us according to our own risk tolerance.

There is a separate concern around denied data environments in the software realm but that is not on many people's radar. Most software devs would not know where to even start to protect systems from this.

The concept of a denied environment is pretty clear to me when it comes to physical space, or radio communications - but could you clarify what you mean by a "denied data environment"? I have some notion of what you _might_ mean, but I can't find a clear definition of the idea anywhere.

That's surprising, I have a '23 X6, and the built-in navigation is actually really nice. The maps have more detailed information than both Google and Apple Maps in many areas. I also haven't observed any lag/stuttering, but perhaps the hardware is worse or something on newer models.

Anyway, for me at least, the benefit of the built-in nav is not about routing, which is basically always worse than Google/Apple at this point, but about having detailed, offline maps. In my experience, offline Google/Apple maps are less detailed, and you have to download them in advance.

I use all three, depending on my needs at the time - each of them have their strengths. I prefer Google/Apple maps for day to day routing and things like that, but if I'm somewhere with poor signal, I use the native maps to navigate, because they are just more reliable.

It's all subjective though, and probably highly specific to location.

At least to me, the difference is that one is ostensibly an explanation of how the AI arrived at the joke, the other is a post-hoc explanation of the joke.

It really sucks the heat out of it.

One of the problems with halon, and the write-up mentions this, is that it is super effective at starving the fire of oxygen, but has zero effect on the heat of the fuel that was burning. So the fire goes out, but if oxygen is reintroduced before the fuel has a chance to cool sufficiently, it reignites - and now not only are you back where you started, but you have all the toxic byproducts that burning halon produces, which will kill you in a hurry if you breathe them in.

Some societies optimize for the individual. If 8 lights is better for me then I get 8 lights. The experience gor other drivers us a "them" problem not a "me" problem. > Other societies optimize for public good.

That is, frankly, bullshit. Societies, by definition, only exist when their members act, in aggregate, for the good of the community. A society cannot exist where everyone only acts in self-interest at the expense of everyone else. If you make self-interested choices for no other reason than "I did it because I could", that's just pure selfishness.

Society is forced to tolerate some degree of self-interest, but it isn't an optimization problem, because nobody is tweaking the parameters - things work until they don't anymore. That's why every society that has collapsed, did so either due to war, due to greed and self-interest causing it to turn on itself, or some combination of the two.

It isn't important that you make choices that benefit others, but rather that you at least care about how your choices affect others, and attempt to reduce the harm of your own self-interest. If you don't even bother to do that, then you don't deserve to be part of our society, or any other, IMO.

If only people that believed they stand alone, that everyone should fend for themselves, actually had to do so, maybe the world would be a better place.

I'll disagree only a tiny bit here: To me (also a compiler engineer), a transpiler is shorthand for source-to-source translation from one language to another at a similar level of abstraction (e.g. Lua to Ruby, Java to C++). The implementation of a transpiler meeting that definition is generally a simpler project than a compiler, by virtue of the fact that you get to offload a lot of things to the compiler of the target language. That doesn't mean they aren't incredibly complex in their own right though - compilers are just enormously complex projects for anything approximating a production-ready toolchain. Anyone using the term as a pejorative should be laughed out of the room.

In any case, I 100% agree that this is obviously a compiler. The fact that the compiler emits WASM as text, i.e. WAT, doesn't mean it is source-to-source translation - the output is still assembly code for the target machine.

And as an aside, does it really emit WAT? or is that just a debugging view of its output? If you can emit WAT, there is zero reason you can't emit WASM too.

In 2008 gas cost as much as it does now and fast food did only pay $8/h

Did you deliberately pick the time where the cost of gas skyrocketed before eventually coming back down to more normal levels? Gas where I lived at the time went from like $2/gal to $4/gal for months, then came back down to ~$2.75 but never fully returned to where it was. You're cherry picking your facts.

your entire post is an example of the dramatic doomerism waxing on the anxieties of normal life. Complaining about anxiety is one of the hallmarks of a millennial.

Where was I complaining about anxiety? I do think many people are anxious, and have reason to be - but if I'm complaining about anything, it's greed. Dismissing the extensive evidence of its pervasiveness in our society today, and the negative outcomes it is producing, is the mindset of someone that doesn't care about anyone or anything that doesn't affect them personally.

It it apparently _is_ an actual problem, which is why an attempt at solving it is being made. A black market for reservations is bad not just for customers, but for the establishment that loses out on business if the reservations aren't actually sold, and therefore nobody shows up.

So the NY government shouldn't be trying to solve problems for NY residents? Make it make sense.

You might not need to go to college, but you're going into significant debt if you do, so now one has to decide which disadvantage they want to start their career with: no degree, or crippling debt.

A fast food job might be $17/hr, but the cost of gas is >2x what it was when that same job paid $8/hr, not to mention other basic costs like groceries, rent, and buckle up if you have to go to the doctor. Pay has simply not kept up with the cost of living for most Americans.

Why would anyone be happy that everything is ephemeral? That implies a lack of stability, more anxiety about the future, less confidence that you can weather bad times.

Humans are tactile creatures, everything being digital leads to a counter-intuitive sense of isolation - more connected, but less personal. There are positives too, but as an older Millennial, it has been interesting to be along for the ride as the potential of the internet and social media went from a superpower, to kryptonite. Who knows where things will be in 5-10 years, but it's hard not to see how some of our greatest tools are being turned against us in the search for more profit.

Millennials are, if anything, brutally realistic - a trait required to navigate the last 16 years. We were forced to watch as the last bit of life in the idea of a strong middle class was snuffed out, and had to enter the workforce right as the GFC hit. Our parents were the last generation where one could reasonably expect to live a life that truly lived up to the ideal of the American Dream - that one could get educated, get a job, buy a decent house and raise a family, without it being especially noteworthy to do so. For many Millennials, if not every generation following, it is essentially nothing more than a dream at this point. Corporate greed, and a government fully captured by it, has all but killed the middle class, and I fully expect that the advent of AI - rather than being a boon for the middle class - will drive a nail in its coffin. Those with the most to gain are already on top, and I've already heard way more people here talk about what they'll be able to do without needing to hire anyone, than I have about how the people left jobless will benefit. It is readily apparent that nobody with any power is going to do anything about it before a significant amount of suffering is felt - maybe not even then. All you have to do is listen to how people talk about it, as if everyone will magically figure out something else to do when every sector starts losing jobs simultaneously. Our society has a greater chance of eating itself alive first.

I consider myself lucky amongst most Millennials - I entered the workforce before the GFC, then joined the military shortly after it (not due to the GFC, but the timing worked out). I was able to get far enough along in my career in those first years though that I never had to struggle with finding a job like many did. I was able to get a house in my 30s thanks to the GI bill. Very few of those I grew up with are in the same boat, many are living much the same as they were 15 years ago - unable to save enough to buy a house, facing reduced job prospects in the future. What reason do they have to be anything _but_ pessimistic?

For me personally, I think we've simply lost the battle against greed, and there is a tipping point after which reigning it back in is impossible without burning it all down. That's something nobody should want, least of all the rich, but it's played out many times in history, and we keep falling into the same trap, just different ways. I think this time it probably was Citizens United where we lost our grip, that decision made it inevitable that corporate interests would be the driving force of government, not the needs of its people. Who can say for sure what will happen, but we're all along for the ride regardless.

To my understanding, no it doesn't, as the value is resolved when the function pointed is created, not when the underlying function executes, which the code you linked shows too. I know it uses the "env" as a structure field, but it's partial application, not the actual closure which has access to parent scope

The code I linked literally shows that the closed-over terms are written into the closure environment when the fun is created, and if any term is a heap allocated object, it isn't copied into the closure, only the pointer is written into the env. The only reason you can't observe the effects of mutability here is because, unlike Python, there is no way to mutate bindings in Erlang.

Again, this isn't partial application - not in implementation nor in semantics.

The example you've given here does not work the way you think it does. I would agree however that the mechanics of closure environments is simpler in Erlang due to the fact that values are immutable, as opposed to closures in other languages where mutability must be accounted for.

I would also note that, for the example you've given, the compiler _could_ constant-fold the whole thing away, but for the sake of argument, let's assume that `Val` is an argument to the current function in which `SumFun` is defined, and so the compiler cannot reason about the actual value that was bound.

The closure will be constructed at the point it is captured, using the `make_fun` BIF, with a given number of free var slots (in this case, 1 for the capture of `Val`). `Val` is written to the slot in the closure environment at this time as well. See the implementation of the BIF [here](https://github.com/erlang/otp/blob/6cefa05a2a977864150908feb...) if you are curious.

At runtime, when the closure is executed, the underlying function receives the closure environment, from which it loads any free vars. In my own Erlang compiler, the closure environment was given via pointer, as the first argument to the function, and then instructions were emitted to load free variables relative to that pointer. I believe BEAM does the same thing, but it may differ in the specific details, but conceptually that is how it works.

The compiler obviously must generate a new free function definition for closures with free variables (hence the name of the function you see in the interactive shell, or in debug output). The captured MFA of the closure is this generated function. The runtime distinguishes between the two types of closures (function captures vs actual closures) based on the metadata of the func value itself.

Like I mentioned near the top, it's worth bearing in mind that the compiler can also do quite a bit of simplification and optimization during compilation to BEAM - so there may be cases where you end up with a function capture instead of a closure, because the compiler was able to remove the need for the free variable in cases like your example, but I can't recall what erlc specifically does and does not do in that regard.

Ah right, good point - I was trying to remember the exact behavior, but couldn't recall if an error is raised (and when), or if the underlying module is just replaced and "jesus take the wheel" after that.

Erlang absolutely has closures, you are mistaken. What you are referring to are "function captures", which bind a function reference as a value, and there is no environment to close over with those. However, you can define closures which as you'd expect, can close over bindings in the environment in which the closure is defined.

The interaction between hot reloads and function captures in general is a bit subtle, particularly when it comes to how a function is captured. A fully qualified function capture is reloaded normally, but a capture using just a local name refers to the version of the module at the time it was captured, but is force upgraded after two consecutive hot upgrades, as only two versions of a module are allowed to exist at the same time. For this reason, you have to be careful about how you capture functions, depending on the semantics you want.

My reading is that they were evaluating leaders on their introversion/extroversion, intuitiveness, and overall success. So you could have both introverted-intuitive and extroverted-intuitive leaders, and overall, the introverted-intuitive leaders were _more_ successful.

BZ2 was one of my favorite games for quite some time after it released, just a blast to play. I had been really into BZ98 before it, and didn't think a sequel would be able to match the magic, but I ended up playing more of BZ2 in the end. Anyway, it's nice to be able to say thanks to one of the devs for all the good times!

Any particular interesting stories about BZ2's development that you recall? Always interesting to hear how games like this come together, so much of the time it seems like more luck than anything!

iOS does support a form a call screening, called live voicemail, which transcribes the message being recorded by the caller and lets you pick up the call if you want. iOS also supports ambient song identification, with history, which I use frequently. Safari supports extensions, and I believe other browsers can as well, but can't speak to that as I really only use Safari in my phone, even though it's not my primary browser on desktop.

Figured I'd drop a comment to let you know about the others though!

Those aren't the only failure modes - you can have two sets of servers partitioned from one another (in two different data centers), both of which are reachable by clients. Do you allow those partitions to remain available, or do you stop accepting client connections until the partition heals? The "right" choice depends entirely on the application.

Pretty disappointed to not find sources for the compiler yet, which is the part I'm by far the most interested in. Hopefully that will follow this release soon!

I wouldn't read too much into the syntax - the Haskell-like definitions are just a succinct way to describe the AST representation for the toy call-by-push-value language the post is talking about. Similarly, the syntax that resembles LISP, is actually (I believe) just shorthand for how the language would be represented in an extended lambda calculus with call-by-push-value semantics.

I think it's important to note that the post is clearly written for someone working on the implementation of compilers/type systems. So for example, in a compiler IR, especially those based on an extended lambda calculus representation, functions/closures are often curried, i.e. only take a single argument. As a result it can be an issue at a given call site to know whether a function is "saturated", i.e. all of its arguments have been applied so it will do some work and return the actual result; or whether it is only partially saturated, in which case it returns a new function that needs one less argument than before. I gather that this interacts poorly with typing in some situations, but I'm not super familiar with the issues here as I haven't gone down the rabbit hole of building a compiler with this kind of IR.

That said, as someone who works as a compiler engineer, I do recognize the potential of call-by-push-value, namely that it reifies evaluation semantics in the IR, rather than it being implicitly eager or lazy, and thus having to hack around the lack of one or the other, i.e. implementing lazy evaluation on top of eager semantics or vice versa. Making it a first-class citizen enables optimizations that would otherwise be impossible or very difficult to implement. To be clear though, you can obviously implement lazy on top of eager, or eager on top of lazy, without call-by-push-value - but I think if you anticipate needing to do that, and you are building a new compiler, using a call-by-push-value IR might be a worthwhile approach to take.

There might be more to it that I'm not really seeing yet in my brief reading of it, but the post made sense to me, it's just assuming a lot about the reader (i.e. that you are deeply familiar with compiler implementation, type theory, etc.).

This is said so confidently, but clearly with little to no experience with the military or the VA to back it up. No vet is receiving benefits without something to back up their disability rating, even if that rating is higher than it seemingly "should" be. Some disabilities are easier to establish than others, because the issue causing the disability is so prevalent in the service that the military has little basis to deny them. Hearing loss is a common one. That said, I'm a vet, with significant hearing loss due to my time in (I was an F-16 maintainer on the flightline, an extremely intense noise environment). I'm not eligible for _any_ disability rating at all, because I did not report issues while I was still in the service; but hearing loss issues often take time to become apparent, and it's not like we were being tested for it. It was not uncommon for someone to forget their earplugs (the second layer of hearing protection we had, under our headset), and be essentially forced to go out on the flightline anyway to handle some task around running engines. These events would be downplayed, but just one instance of that can cause irreversible hearing loss.

But that's just a specific issue relevant to my time in the service. The bottom line is that unless you report every little thing that _might_ cause an issue later, you're going to be up shit creek when you get out and find out that something you were exposed to during your service is causing an expensive medical issue that you have to deal with. There are all kinds of fucked up things people had to do while they were in, that they struggle to get compensation for now that the consequences are catching up, because the issues aren't straightforwardly attributable to some event during your service, like with combat injuries. Burn pits are the most notorious one - you have advocates like Jon Stewart fighting in Congress to pass laws to support vets who were forced to work those pits and are now battling all kinds of complications. If anyone should be an obvious beneficiary of the disability system, beyond those with combat injuries, it should be those folks - but they are largely left hanging in the wind. In the case of burn pits especially, the military _knew_ there were consequences to having soldiers work them, but chalked it up as the cost of war.

Frankly, from what I've observed, once vets are out of the service, our country largely gives them the middle finger when they struggle with mental or physical health issues. I say "them" here, because I'm not a combat veteran, and I'm lucky that I had it pretty easy during my tenure (2009-2015), but for many, that is very much not the case. Yeah, nobody in Congress is going to stand up in front of everyone and say "let's make disability benefits harder to obtain" - but I have no doubt they'd have few, if any, qualms about doing it behind closed doors.

No, you’re exactly right, they are just regular singly-linked lists of tuples, nothing more.

The only time `is_` is used, is with functions permitted in guards. These are functions defined in Erlang, and only a small handful exist, and you learn them very early on. With the advent of `defguard`, it is conventional to use `is_` with custom guards as well, but that’s the intuition - guards vs general predicates.

I haven’t seen a Blame! reference in the wild before! The concept of runaway AI that never stops building more infrastructure seems like one of those dystopian scenarios that is at least semi-plausible, and the idea that humans effectively lock themselves out of control by being too clever (net terminal gene) is just the cherry on top.

Cars have a lot of trim/seals/insulation/carpeting to reduce road noise and be aesthetically pleasing, and military aircraft cockpits don't care about either of those things, and are largely just a metal tube with racks on which all of the avionics and other cockpit equipment are mounted, with holes in a handful of places where wiring harnesses enter/exit the cockpit. All of that equipment is regularly worked on, removed/replaced, and so it is necessary that it be (relatively) easy to access and remove.

The equivalent would be like if you had to pull all of the instruments, electronics, and seats out of your car every 1000 miles, clean them up, replace faulty bits, and then put it all back again. All of the fancy trim, carpeting, etc., just makes that job harder, so you would probably want a car that doesn't have any of that, and is designed to make doing that kind of work easier, better still if you can avoid having to remove everything, and only have to remove the bits individually that need to be maintained. The down side of course, is that without all of the fancy trim and stuff, there would be gaps where things could fall and be hard to reach, and holes where wiring travels to the engine compartment/trunk/etc. Of course, FOD presents way less of a danger in a car than it does an aircraft, so you might not care if you drop something there, but aside from that, I think the analogy holds up.

I worked on F-16 avionics (in aircraft maintenance, on the flightline), there are a lot of little nooks/holes/slots/gaps where small bits of FOD can fall and be incredibly difficult to extract, and the fear of that FOD causing a jam, flying around the cockpit, or getting wedged and causing unexpected wear on wiring harnesses and then shorting out (or worse, arcing) during flight was a _big_ deal. FOD in the cockpit was basically the worst thing that could happen during routine maintenance, because if you couldn't see it, and either couldn't get to it with a magnet (or the FOD wasn't metal), it might require pulling _a lot_ of stuff out of the cockpit before you could reach into the area where it fell. The worst case that could easily happen was having to have Egress come out and pull the ejection seat so you could get under it.

I always figured that all of those little gaps/etc. were due to a couple factors:

1.) the aircraft are constantly being upgraded/modified, so even if you designed the aircraft to be gap-free initially, there will inevitably be changes that introduce them. The cockpit itself is basically a frame with racks that hold all of the avionics, seat, etc.

2.) in conjunction with the above, ease of maintenance was somewhat important, so they tried to leave at least a little room to maneuver in the cockpit where possible (though there were plenty of places which were a nightmare to work regardless), but that comes at the cost of introducing areas where things can fall.

3.) some components have to be regularly removed and worked on outside the aircraft, or must be free of obstruction during flight, e.g. the ejection seat. So you end up with plenty of gaps where things can fall.