Readit Newssfvisser commented on Löb and Möb: Loops in Haskell (2013) github.com/quchen/article... · Posted by u/fanf2
Reminds me of this classic doing the same: http://blog.sigfpe.com/2006/11/from-l-theorem-to-spreadsheet...
sfvisser commented on At the end you use `git bisect` kevin3010.github.io/git/2... · Posted by u/_spaceatom
Git bisect was an extremely powerful tool when I worked in a big-ball-of-mud codebase that had no test coverage and terrible abstractions which made it impossible to write meaningful tests in the first place. In that codebase it was far easier to find a bug by finding the commit it was introduced in - simply because it was impossible to reason through the codebase otherwise.
In any high quality codebase I’ve worked in, git bisect has been totally unnecessary. It doesn’t matter which commit the bug was introduced in when it’s simple to test the components of your code in isolation and you have useful observability to instruct you on where to look and what use inputs to test with.
This has been my experience working on backend web services - YMMV wildly in different domains.
Even if you can reason through a code base a bisect can still be much quicker.
Instead of understanding the code you only need to understand the bug. Much easier!
sfvisser commented on My first impressions of Gleam mtlynch.io/notes/gleam-fi... · Posted by u/AlexeyBrin
I don't think parser combinators are any more difficult in imperative languages like Python than functional ones? I found a few for Python and C++.
Don’t know about difficult, but at least less elegant. Lazy evaluation, type inference, abstractions like Functor/Applicative/Alternative/Monad make them so incredibly natural to work with in a language like Haskell. Sure, they exist in other languages (made a few myself) but it’s not the same.
Dead Comment
sfvisser commented on When Is WebAssembly Going to Get DOM Support? queue.acm.org/detail.cfm?... · Posted by u/jazzypants
sfvisser commented on When Is WebAssembly Going to Get DOM Support? queue.acm.org/detail.cfm?... · Posted by u/jazzypants
We use WASM quite a bit for embedding a ton of Rust code with very company specific domain code into our web frontend. Pretty cool, because now your backend and frontend can share all kinds of logic without endless network calls.
But it’s safe to say that the interaction layer between the two is extremely painful. We have nicely modeled type-safe code in both the Rust and TypeScript world and an extremely janky layer in between. You need a lot of inherently slow and unsafe glue code to make anything work. Part is WASM related, part of it wasm-bindgen. What were they thinking?
I’ve read that WASM isn’t designed with this purpose in mind to go back and forth over the boundary often. That it fits the purpose more of heaving longer running compute in the background and bring over some chunk of data in the end. Why create a generic bytecode execution platform and limit the use case so much? Not everyone is building an in-browser crypto miner.
The whole WASM story is confusing to me.
sfvisser commented on Gaslight-driven development tonsky.me/blog/gaslight-d... · Posted by u/theodorejb
> Like it or not, we are already serving the machines.
The machines don’t give a shit, it’s the lawyers and bureaucrats you’re serving :)
Better or worse?
sfvisser commented on Unexpected security footguns in Go's parsers blog.trailofbits.com/2025... · Posted by u/ingve
A "parser" is the piece of software that translates unstructured input (usually text) into structured output that better reflects the runtime of a programming language. A "security bug" in a parser is normally construed to be the existence of an input that causes the software to do something incorrect/undocumented/unexpected.
Nothing in the article discusses a parser or anything like a parser bug.
The article doesn't like that the semantics of the user-facing API wrapped around the parser is, I guess, "easy to make mistakes with". That's an article about API design, at most. But that's boring and specious and doesn't grab clicks, so they want you to think that Go's parsers are insecure instead.
Exactly right. Better have a domain layer with data types representing the domain object 1:1 and add one or more API layers on top for interacting with those for some modality. Creation, deletion, verification, auth etc.
The security failure is not the parsing library, but failing to model your application architecture properly.
sfvisser commented on Rust compiler performance kobzol.github.io/rust/rus... · Posted by u/mellosouls
Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memory issues (as much as say Java or C++).
This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?