I'm not very familiar with functional programming and Haskell in particular. I think I understand the gist of this article, and "use data structures that make illegal states unrepresentable". However, is there a similar article but written with more common languages (C#, C++, Java, Go) in mind? Or is a big part of this concept only relevant for strong functional languages with sum types and pattern matching?
It is relevant to all languages with static type checkers from idris to python. But of course since it is about expressing properties via the type system the more expressive that is the easier and more applicable.
Java has sum types, incidentally. And pattern matching.
> Or is a big part of this concept only relevant for strong functional languages with sum types and pattern matching?
It need not strictly be a pure functional language for type-driven style to be usable. Type-driven style only requires the fact that some type cannot be assigned to another type, so it's kind of possible to do even in a language like C, as `int a = (struct Foo) {};` would get rejected by C compilers.
However, I don't think it's doable in languages with structural type systems like Typescript or Go's interface without a massive ergonomic hit for minimal gain. Languages with a structural type system are deliberately designed to remove the intentionality of "type T cannot be assigned to type S" in exchange for developer ergonomics.
> However, is there a similar article but written with more common languages (C#, C++, Java, Go) in mind?
For C#, there's F#-focused article, which I believe some of it can be applied to C# as well:
For modern Java, there is some attempt at popularizing "Data-Oriented Programming" which just rebranded "Type-driven design". Surprisingly, with JDK 21+, type-driven style is somewhat viable there, as there is algebraic data type via `record` + `sealed` and exhaustive pattern match & destructuring.
For Rust, due to the new mechanics introduced by its affine type system, there is much more flexibility in what you could express in Rust types compared to more common languages.
> However, I don't think it's doable in languages with structural type systems like Typescript or Go's interface without a massive ergonomic hit for minimal gain.
Go only has structural interfaces, concrete types are nominative, and this sort of patterns tends to be more on the concrete side.
Typescript is a lot more broadly structural, but even there a class with a private member is not substitutable with a different class with the same private member.
Not me personally, but a GitHub user wrote a replacement for Go's regexp library that was "up to 3-3000x+ faster than stdlib": https://github.com/coregx/coregex ... at first I was impressed, so started testing it and reporting bugs, but as soon as I ran my own benchmarks, it all fell apart (https://github.com/coregx/coregex/issues/29). After some mostly-bot updates, that issue was closed. But someone else opened a very similar one recently (https://github.com/coregx/coregex/issues/79) -- same deal, "actually, it's slower than the stdlib in my tests". Basically AI slop with poor tests, poor benchmarks, and way oversold. How he's positioning these projects is the problematic bit, I reckon, not the use of AI.
Same user did a similar thing by creating an AWK interpreter written in Go using LLMs: https://github.com/kolkov/uawk -- as the creator of (I think?) the only AWK interpreter written in Go (https://github.com/benhoyt/goawk), I was curious. It turns out that if there's only one item in the training data (GoAWK), AI likes to copy and paste freely from the original. But again, it's poorly tested and poorly benchmarked.
I just don't see how one can get quality like this, without being realistic about code review, testing, and benchmarking.
Note that this is semantically exactly equivalent to "up to 3000x faster than stdlib" and doesn't actually claim any particular actual speedup since "up to" denotes an upper bound, not a lower bound or expected value. It’s standard misleading-but-not-technically-false marketing language to create a false impression because people tend to focus on the number and ignore the "up to".
Saying “up to” means that bound is the maximum value of the data set. It may be far from the median value, but it is included (or you’re lying). With any other interpretation the phrase has no meaning whatsoever.
I will concede, proactively, that "up to" could refer to some maximum possible bound, even if the current set doesn't include a value at that bound, though I would argue that's likely deceptive wording. For example, you could say that each carton of of eggs on a pallet contains up to 12 eggs, because that's the maximum capacity of the carton, even if none of the actual cartons on this pallet actually have 12 eggs in them.
That's a good caution. However, traversing a flat AST (iterating a "struct of arrays" rather than a pointer-based tree) is also going to be faster. So the next steps of the compiler, say type checking and code emitting, will also be faster. But how much, or whether it's worth it even then, I'm not sure.
True, but that does also depend on where you store semantic information. Zipping past a nicely packed AST won't buy you much if for every node you have to look up its type or other semantic information somewhere else in memory through some slow process.
Another small trick is to use a "reversed" bump allocator, that starts handing out the memory from the end with the larger addresses. Since AST structures are almost always created bottom-up, children before the parents, the root node at the very end on the return from parseProgram/parseModule/etc. function, you will end up with the AST that has most its pointers pointing forward. This means that during AST walks, you'll be going from lower addresses to the higher ones which I think is actually somewhat faster than the reverse order.
I use the "baby bear" strategy mentioned in the article. My criteria are something like: archive emails from humans as well as important emails like receipts and invoices; delete advertising emails, newsletters, notification emails, and things that I can just as easily find online.
Yeah, I use this sometimes too (even though Python makes "monkey patching" easy). However, note that it's simpler and clearer to use a default value for the argument:
def do_foo(sleep=time.sleep):
for _ in range(10):
sleep(1)
A program that will play chess (written in Go). My 18yo daughter can now beat me at chess (not that I'm any good). I figured if I can't beat her, I'll see if I can write a program to beat her instead. My idea for v1 is that I'd write the algorithm myself, without looking up anything about how to write a chess program (I'm sure such literature abounds). I've just about finished v1; still a few bugs to iron out. To be honest, I didn't find it all that fun, mainly because of all the special cases (all the castling rules and the like).
I'm a big chess buff, and will say that the hard part is not making an engine (which is hard!), but making an engine that plays poorly, well. What I mean is: engines are very smart and better than the best human. When you make a "dumb" engine, you are telling a chess god to intentionally make mistakes. The mistakes they make, however, are not the same mistakes a beginner chess player would make. Today, beginners are discouraged from learning by playing against bots because of this; It simply doesn't serve you in human games.
Lichess has a "humanlike" bot[1] but I haven't played with it yet. I think this problem will haunt you, if you get past the whole "create a chess engine" problem :) I have tried and failed to do this in the past.
Check out chessiverse (I’m not affiliated just found from YouTubers). They purport to be a collection of bots that play like humans with human-like mistakes matched to ELO levels. I like it so far - the main value for me (vs lichess/chess.com) is knowing that who’s on the other end isn’t constantly cheating.
I always assumed that chess engines are dumbed down by occasionally inserting random moves but now it occurred to me that a way to get more realistic mistakes might be feed them a distorted version of the game state.
I can't help but point out the irony of a chess program written in Go, as someone that enjoys playing Go [1] myself. Sorry to hear it wasn't that fun, hope you still got something out of it!
Yes, definitely still got/getting something out of it, thanks. And I'll probably get more out of it when I read up on "how to write a real chess program" for v2, and learn about all the things I didn't think about.
Same, always wanted to do this, especially without looking stuff up, which feels like cheating. I haven't yet figured out the recursive tree search thing.
> “The ships hung in the sky in much the same way that bricks don’t.”
That is probably my favourite phrase from the whole book. For some reason I find it hilarious. It has stuck in my brain in much the same way that names don't.
The guy certainly had ba... uh, courage. Jesus is known for saying striking things, like "If your hand or your foot causes you to stumble, cut it off and throw it away. It is better for you to enter life maimed or crippled than to have two hands or two feet and be thrown into eternal fire." (Matthew 18:8) He was the master of attention-grabbing metaphor. Of course here he means "deal seriously with your sin", not "get out the butcher's knife".
Hi! This is part of Jewish religious purity law and not usually taken as part of the rules that govern most Christian denominations. For example, women who are menstruating are usually not banned from participating in Christian services, and any other people would be unsuited to partake in Temple service according to Jewish religious law are usually allowed to participate in worship in Christianity.
Thus heightening Jesus’ mysterious irony, and probing the dichotomy between acceptance before humans and the abundant grace of spiritual redemption
The physical human body is said to parallel and prefigure the glorified heavenly body. Archbishop Fulton Sheen was quoted as saying that the only “man-made things” in Heaven are the Five Wounds of Christ.
>> Korean Statue Depicts A Jesus So Jacked It Looks Like His Last Supper Was Pure Protein (2018)
I do it by working for Canonical. The vast majority of our projects are open source. Yes, Canonical's application process is very long and thorough, but it's a good company to work for. Those aren't "my" projects, of course; I'm still very much working for an employer, but it's nice that our development effort is in the open and freely available. I also maintain a few of my own open source projects, for which (via GitHub Sponsors) I get about enough for one coffee date with my wife.
Canonical’s interview process sounds like more than just thorough, it sounds completely insane. I can’t believe people actually put up with that rubbish to have a chance to work at such a mediocre company.
My fly.io-hosted website went down for 5 minutes (6 hours ago), but then came right back up, and has been up ever since. I use a free monitoring service that checks it every 5 minutes, so it's possible it missed another short bit of downtime. But fly.io has been pretty reliable overall for me!
Would be fascinated to see your data over a period of months.
Application up time is flakey, but what was worse were fly deploys failing for no clear reason. Sometimes layers would just hang and eventually fail for no particular reason; I'd run the same command an hour or two later without any changes and it would just work as expected.
I'd love to make a monitoring service to deploy a basic app (i.e. run the fly deploy command) every 5 minutes and see how often those deploys fail or hang. I'd guess ~5% inexplicably fail, which is frustrating unless you've got a lot of spare time.
I used to run a service that created k8s clusters on GCP for our customers. We did want to check that that functionality kept working and had a prober test it periodically. It was actually broken a lot.
Always good to monitor your dependencies if you have the time. Then when someone complains about an issue in your service, you can check your monitoring to see if your upstream services are broken. If they are, at least you know where to start debugging.
My downtimes from fly are pretty rare but generally global when they happen, in this outage we had no downtime but couldn't deploy for a few hours. I have issues with deploying about once per quarter(deploy most days across a few apps)
If that’s the case I suspect fly is getting a lot more reliable. I stopped using them about a year ago so haven’t kept up on their reliability since. Glad to hear, it’s good for a competitive market to have many providers, and fly might have issues but hopefully has a bright future
They are definitely getting more reliable. I was an early user and moved off them to self hosted for quite a while because of the frequent downtime in early days.
Their support still leaves a lot to be desired even as someone that pays for it but the ease of running and deploying a distributed front end keeps bringing me back.
By asking directly and someone answering, it solves the problem for the person wondering, but also anyone else wondering (i.e. asking directly scales very nicely).
It wasn't a request routing outage; apps running on Fly.io didn't stop running. It was a deployments outage. For reasons passing understanding (I am reliably informed I'm wrong to complain about this), our website is the same Elixir app as our dashboard, and the dashboard got redeployed at one point. Our website being down is not the same as the whole service being down, though I guess there's a truth-in-advertising poetry to it being down when deployments are busted.
Why not both? Tell me what's comforting and I'll tell you why you shouldn't be comforted; tell me why you're disconcerted and I'll tell you maybe something else. All we can do is be straight about things.
I'm an HN person before I'm a Fly.io person, and as an HN person I find the points you're trying to make --- anybody can see them throughout the thread simply by searching your name --- tedious.
As a businessperson, I don't think I have much to gain by genuflecting to the importance of reliability; everybody I care about on this site shares an understanding with us that reliability is important, though apparently not with you that all these systems are fallible. So I'm making the decision not to genuflect, and instead call you out --- you in particular, anonymous, venomous, green-named commenter --- as a a writer of boring and facile attempted dunks.
Are we not allowed to expect reliable uptimes from a cloud provider? What part of "fly.io has a documented history of prolonged downtimes and data redundancy issues" do you disagree with? Are you calling everybody liars who have had bad experience with fly.io, frankly, business and reputation loss that came as a result of trusting fly.io ?
That's not how flags work on HN: I can't flag your responses to me. For a variety of reasons, and for better or worse, I'm very comfortable with how I come across on HN.
To twist the knife just a little bit, I'll refer you though to the guidelines:
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
