Comments URL: https://news.ycombinator.com/item?id=45028539

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45005494

Points: 3

# Comments: 0

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.

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).

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!)

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

Comments URL: https://news.ycombinator.com/item?id=43050422

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=42662149

Points: 3

# Comments: 0

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.

- 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

    * C: ez

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

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.

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.

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.