norswap

Not really, he explicitly makes the point that it's easier to write useful simple programs in Javascript without the extra stuff, whereas in Rust you need to know about a whole lot of things to make the equivalent simple program.

I read it and was disappointed, it's okay but probably my expectations were too high for this classic.

I would recommend Snow Crash instead, another Sci-Fi classic from the same era which I found to be a much more enjoyable read & more commensurate to the hype.

Wasn't there a better technical way to block the scraper? Like blocking IPs/domains at ingress instead of serving requests? Probably you do still pay for request traffic though...

Isn't there a market for anti-DDOS third-party services for API endpoints (Cloudflare etc) — through probably for "Free Speech Extremist" that wouldn't be suitable solution, and there are charges too (though presumably when facing a situation like this you actually save money).

Am I the only one wishing I could see the original afterwards, for comparison?

I think it did much better on safety in some tests (no I don't have sources, going from memory :/), but is less capable by design on some more trickier scenarios. Basically pretty much what you would something like this to be.

I used to work on compilers & JITs, and 100% this — polymorphic calls is the killer of JIT performance, which is why something native is preferable to something that JIT compiles.

Also for command-line tools, the JIT warmup time can be pretty significant, adding a lot to overall command-to-result latency (and in some cases even wiping out the JIT performance entirely!)

His "attempt" at self-driving is better than most of the industry, at a fraction of the cost.

The man does and tries things. Man in the arena.

While I agree exceptions should not be used for control flow except in the rarest of circumstances (every rule has exceptions — pun fully intended), I think checked exceptions are very useful.

I wrote a whole article about this, way back when: https://norswap.com/checked-exceptions/

But for the tl;dr: checked exceptions represent somewhat expected issues, things like IO errors. There are two okay ways to handle those: checked exceptions and result types, and one bad way: unchecked exceptions.

Unchecked exceptions end up being undocumented in the API, and people forget to handle them.

Result types add a lot of ceremony, as you have to unwrap them at every level of the call stack. I've seen code dominated by error checking logic many times in C and Go (and the frequent alternative is to ignore error, which is easy in C).

Checked exceptions are much less verbose, you just let the exception pass through and annotate the function signature with the checked exception. It's type-safe, self-documenting and easy.

Unchecked exceptions "leak", checked exceptions propagate at the type-level, which is exactly what you want — making sure every caller is aware of what exceptions might occur and letting them make an explicit decision to handle or pass the buck upwards.

By the way, checked exceptions are coming back in favour with "effects" which are basically a generalization of checked exceptions beyond the realm of errors, trying to encode things into the type system.

Why use base 36 and not base 26?

Wow that's interesting — trying to cross my eyes produces hellish jitter.

I suspect it's because my left eye is slighty lazy.

But I was able to superimpose the right cat picture onto the left one (it's a lot harder for the more complex sky resort picture). It's pretty eerie, the right picture just slides right up the left one (I did need to figure out the right distance for it).

It doesn't help me pick out the differences though, I mostly only see the right picture, and if try to focus my left eye, the right picture slides out. Still, intersting.

Zig — here's the choice matrix:

- You need strong performance, your choices are:

   * C: nope, unless it's super simple library-type code, must integrate as easily as possible with everything C compatible

   * C++: unless you have ecosystem lock-in, avoid this mess, stuck in an evolutionary rut where they can't undo bad decisions and keep adding more complexity (mostly good stuff, but total complexity too high)

   * Zig: better than C & fully compatible with it

   * Rust: ecosystem tailwinds, bit better safety than Zig, steeper learning curve and uglier code

   * Go: ok but GC probably means not the best perf

   * Java: JIT means it can handily beat non-painstakingly hand-optimized C code in some particular cases (requires a lot of wisdom to choose this for perf)

   * something that will incur a lot of pain in some other way like Fortran, Forth or Ada

- You need to export to C code (all of the above have options to import from C code with C/C++/Zig being the easy choices)

    * C: ez

    * Zig/C++: harder but still ez, need to write some wrappers when using features nont in C

All in all, for new system or high-perf work with no ecosystem tie in, it's probably a battle between Rust and Zig. I think I'd use Zig on aesthetic grounds — find it less painful to use than Rust, and I'm not too worried about missing on the extra safety. The converse decisions seems reasonable too.

The biggest improvement from this (besides maybe performance) is that it should enable much better manually programmed syntax error messages. Those generated by yacc were pretty shit.

This is generally my #1 reason for using a manual parser — nobody has yet made a pretty good syntax error handling / reporting for parser generators or parser combinators.

It's genuinely very complex — I read the whole literature on that as of 2019 (there's surprisingly little). You basically have to inject custom logic, though there are a few heuristics that you can prepackage and can be useful in a lot of places. But the custom aspect of it means this doesn't play nice with traditional LL/LR parser generators. It could be done for parser combinators (PEG etc) however. Didn't have enough time in my PhD thesis to play with this, and I moved on to other things, but I'm hoping someone will make this eventually.

Is there a way to import existing corpuses?

Thinking in particular of browser bookmark exports and Notion, I'm sure other people would like something else. Being able to parse any kind of text file for links would be great + full-text search in text files / markdown.

Oh that looks cool! I was really hoping it would have better emoji support than MessagEase as that is the one think I miss (the ability to search for emoji by name) but alas no.

See MessagEase for a similar keyboard (not programmer-focused) with less keys but letting you use the swiping motion to type ordinary — great for fat-fingered people.

I used to respect patio11's opinions, and obviously he has a lot of valuable knowledge and there are things to learn from him, but some of his takes on crypto have led me to heavily discount his writings on the topic.

On the face of it, this writeup is reasonable.

I'm a crypto founder, and I struggle with banking. We've had two banking applications rejected in Singapore.

Here's the thing: we're not doing anything remotely like what Patrick describes. I think he strawmans a lot.

We're a crypto-focused IT consultancy, but closely affiliated with an upcoming blockchain. The business is set up to be super boring: we bill the client for work and that's it. The company doesn't handle a token, doesn't get revenue from onchain activities, ... The blockchain in question is not anymore risky than any other and in many ways less. Not that the banks know or ass.

They just say "you're rejected and we can't tell you why".

Now this is Singapore, not the US. It's not a targeted plan but just general policies: "crypto is potentially bothersome for us, let's not bother". In the meantime we don't have a bank account. Though I do believe US attitudes and (lack of) regulation probably impact these policies a fair deal.

Frontend frameworks really do make things simpler once you go beyond small applications though. Automatically re-rendering when the data/model changes is the right thing to do.

We can argue over the specifics for sure, but simply imperatively changing your UI whenever your data changes doesn't scale very far, neither in term of codebase nor in terms of team.

I think what actually convinces me more than tone is nuance. If you can fairly assess arguments on both sides, recognize when either side makes a good point, and mention when you're confused about your conclusion, or when some point of evidence doesn't mesh with the theory. Things that are all one-sided are usually wrong (though I suppose there are cases where the truth is indeed one-sided, it's just pretty rare, and less likely to be things that people that you otherwise consider serious would argue about).

Even that attitude can be weaponized I suppose, if nuance convinced more people, than more people would learn to fake nuance to push their favorite outcome. Though I'd like to think that the process would change them a little bit for the better too.

A heuristic is a heuristic, and we can do some of our own research too. I was just defending the OP.

As for my personal position, I remember looking into things a while back and just coming away with the conclusion that nobody really seemed to know. If there's a truth here, it's either considerably more complex than "SFA good" / "SFA bad" (all these interacting pathways, man), or it just makes little enough difference not to matter at all in a way that we can meaningfully measure above the noise.

It seemed clear SFA are clearly not that deadly. Whether you'd be more healthy or live slightly longer if you chose to consume less of them, I have absolutely no clue.

I shouldn't enter into consideration, but it's a shockingly good heuristic to evaluate the credibility of people.

I repeatedly found that people who are thoughtful and not snarky — and often, nuanced — when discussing a topic I have no deep expertise on were much more correct on topics that I did have expertise on and could properly evaluate.

We're all on a time budget at the end of the day. And I do share the sentiment: the scientific literature in nutrition is known not to be very good. You don't have to be an expert, it suffices to notice that there are a lot of people coming to contradictory conclusions, and that the consensus seems to have changed drastically over the past decades, not being particularly driven by any groundbreaking changes in available scientific methods.

What's the general schema of getting someone a work visa in the US?

My understand is big tech usually tries to see if you're eligible for an O-1, and then they take their chances for H1-B, and then there's also a pathway for bringing in workers that have already worked from you from abroad (for one year).

Wondering if there's other types of Visa that are applicable, and where they slot in in the general algorithm of a US-based employer that wants to get a Visa for one of their workers.

I also recently learned about the EB1 Visa, though that one is not tied to an employer. I'm wondering how it compares to the O1 in ease of access / modalities.

This is not immigration per se, but how often do you actually see issue with contract requalification?

For context: hiring remotely you don't want to set up a corporate presence in every country, that would be mind-boggingly complex & expensive — so instead you hire people as contractors or use an employer of record (EOR) like Deel to hire people and then you contract Deel.

The one risk with hiring contractors that will basically only work for you (though for sure, the contract should not make this a condition) is that in some jurisdiction is allegedly pretty easy to take these contracts to court and requalify them as employment contracts, putting you on the hook for back taxes and possibly fines.

I'm just wondering how much that stuff happens in practice, and how much of an issue it is when it happens.

> WASM proved to be secure and JVM did not.

This is an oversimplification — there's nothing about the JVM bytecode architecture making it insecure. In fact, it is quite simpler as an architecture than WASM.

Applets were just too early (you have to remember what the state of tech looked like back then), and the implementation was of poor quality to boot (owing in part to some technical limitations — but not only).

But worst of all, it just felt jank. It wasn't really part of the page, just a little box in it, that had no connection to HTML, the address bar & page history, or really anything else.

The Javascript model rightfully proved superior, but there was no way Sun could have achieved it short of building their own browser with native JVM integration.

Today that looks easy, just fork Chromium. But back then the landscape was Internet Explorer 6 vs the very marginal Mozilla (and later Mozilla Firefox) and proprietary Opera that occasionally proved incompatible with major websites.

I'm honestly not informed enough to comment, but everyone seems to agree there is really bad mismanagement at Lockheed & co + the incentives as set up are truly fucked up (I remember reading on that, but don't have the source handy) and actively encourage manufacturers to pile on costs to make more profits.

If there's good R&D and first-order thinking in the mix, one order of magnitude does not seem insane to me. It's a cliche, but look at what Elon Musk has achieved, everyone said it couldn't be done, but it happened.

Ultimately other things can help, like designing new innovative form factors and cathering to a changing reality (it's doesn't make sense to shoot down 50k$ drones with 1M$ missiles).

There's a new generation of defense contractors (Anduril, Ares) coming online that seem to promise order of magnitude improvement on the status quo.

> FTX faced no such regulation and if you sent them crypto you no longer owned it. FTX did.

This is at best only partially true, you own a claim on the underlying asset.

This is not a matter of regulation, it's a matter of your contractual agreement with FTX.

I don't know how more regulated brokers work, but I also doubt you own the asset outright, you also probably own a claim, which is why if the broker goes bankrupt because of fraud you might not recover it.

Regulation wouldn't have changed anything here: as FTX simply broke the law, which they could have done regardless of regulation & reporting requirements (e.g. WorldCom, Enron, ...).

What they did was not legal, even wrt to what regulation they were subjected to.

I don't know how bankruptcy documents work, but this is not a filling, it's a general-audience article.

The truth is if you had one Bitcoin in FTX, that was worth 20k. You might have bought for more or less than that. Now it's worth 60k. You didn't get the 20k back immediately (in which case you could have repurchased the Bitcoin immediately and not lose anything).

- If you bought Bitcoin above 20k, you lost money, whereas you wouldn't have otherwise. - If you would have kept your Bitcoin, you would have 60k now. You didn't get a choice in the matter.

The problem if of course "what is money" — the thing you owned was a Bitcoin, and now you're getting back its value from back then in dollar terms. This value changed meanwhile, shocking! But quite clearly, most people would have had more money now if that hadn't happened.

So while it's possible that some people would have sold lower than 24k (it didn't stay that low very long), most people wouldn't have, and so they lost money, in the commonly accepted undertanding.

Imagine the government seized your house 10 years ago, then paid you back today its price from 10 years ago +20%. Did you not lose money?

Yup, you can notice some issues even in their picked example. e.g. the prompt for the video of the painting woman says "there is a bear cub at her feet" and it quite clearly is not "at her feet" in the video.

True, but in this case we can simply judge based on the actions taken.

The claims (trademark violation, no contributing anything back) seem pretty sensible and borne out in practice.

WordPress is an open source project stewarded by a foundation that set rules for its use. If you don't follow them there are consequences. As simple as that, really.

These rules (paying a license or contributing back) seem sensible too.

Normalizing people leeching off the work of other doesn't seem like a good approach.

Some people might disagree with the philosophy — perfectly fine! They can write their own blog engine and release it in a permissive open-source license and make copyrights freely available to anyone. This is a blog engine, not exactly antitrust material.

Hold your horses — this will only produce a fraction of the chips, and probably at a much higher cost.

It's a step in the right direction for the policy goals, but they've really just entered the woods with this one.