I tried doing the same thing, happy to see it worked out for somebody! I just didn't have the capital or social safety net to get the farm off the ground, so I eventually had to sell the farm and go back to coding.
Someday though...
Emigrating halfway across the world is not cheap in the first place.
Greece is also not cheap for where it stands on the economic level compared to the average income, especially back in 2018 when Dylan did it, and especially for property even outside of urban areas. Euboea is not super remote either, it's about an hour or two's drive from Athens depending where you go.
So sure, the farm might not make money, but I would wager he had a good amount saved up between him and his family to make the transition possible.
Yes, this really is an example of someone who "made it" and made a large amount of money that has allowed them to turn around and choose a simpler life. "Oh, I just moved myself and my family off to a little Greek island estate I bought and farming it (along with my existing money) is what provides for us..."
Money may not buy happiness buy money buys you all the freedom you could possibly need to do anything that fits your whimsy.
The way I see it, the problem with LLMs is the same as with self-driving cars: trust.
You can ask an LLM to implement a feature, but unless you're pretty technical yourself, how will you know that it actually did what you wanted? How will you know that it didn't catastrophically misunderstand what you wanted, making something that works for your manual test cases, but then doesn't generalize to what you _actually_ want to do?
People have been saying we'll have self-driving cars in five years for fifteen years now. And even if it looks like it might be finally happening now, it's going glacially slow, and it's one run-over baby away from being pushed back another ten years.
People used to brush away this argument with plain statistics. Supposedly, if the death statistics is below the average human, you are supposed to lean back and relax. I never bought this one. Its like saying LLMs write better texts then the average huamn can, so you are supposed to use it, no matter how much you bring to the table.
The self driving car analogy is a good one, because what happens when you trust the car enough to do most of your driving but it suddenly thrusts the controls upon you when it shits the bed and can't figure out what to do?
You suddenly realise you've become a very rusty driver in a moment that requires fast recall of skill, but your car is already careening off a cliff while you have this realisation.
[The "children of the magenta line"](https://www.computer.org/csdl/magazine/sp/2015/05/msp2015050...) is a god explanation of this, and is partly why I often dissuade junior devs from pretty user friendly using tools that abstract away the logic beneath them.
funny story: I got the wife of a friend to install tinder, a couple of years back when I was dating. I was having a hard time getting matches, so I figured I'd see how the other side lives. She created an empty profile, with a blurry hippopotamus as a profile picture, and a single letter as name. Just "H". For hippopotamus. No bio. Within five minutes she was matching with every other guy she swiped right on. Which wasn't all of them, mind you. Within another five minutes, half of the guys she had matched with had messaged her. Regular looking guys. A lot of them had same opening line. "Did you know hippos are the most dangerous animal in the world?"
After that, I got why I wasn't getting any replies >.<
You can try creating a profile as a woman. I did, five years ago, on a site that advertised itself as being dedicated to "affairs" between married people.
All I said was I was 20, was red haired, and open minded. Nothing more, and no photo.
Indeed, within a couple of minutes there were guys asking me if I liked to be whipped while handcuffed to a radiator, and offered to send me dick picks if I sent naked photos first. One of them added later "maybe I'm too direct for you, is that why you're silent?"
I didn't respond to any message, but the offers kept coming. It's insane.
Depends on protocols, but hence why EMS’ job is recognition of the right issue (the best we can do), there are things we can evaluate to determine if we think its an aortic aneurysm even at the emt level to rule that out before making the determination to give aspirin (eg: comparing bilateral blood pressures, checking for pulsating masses)
a heart attack is far more common than an aortic aneurysm.
would comparing bilateral blood pressure (which I assume the patient could do themselves) be enough? I'm not asking for medical advice, just like... what would _you_ do if it was you who had sudden chest pain?
Id encourage you (generally, outside of hn) to lookup the symptoms of a heart attack and aortic aneurysm.
A aortic aneurysm can present with a pulsating mass in the abdomen, and is more common in older people and smokers. The inner lumen of the aorta starts to separate and blood can flow differently or be restricted, eg: right arm bp may be different than left arm. But absence of that doesn’t rule it out entirely.
Whereas a heart attack is going to feel pain in the chest, perhaps radiating to the jaw, shoulder, back, maybe nausea, sweating, and an impending sense of doom.
Automated bp cuffs are pretty inaccurate imo, we use them at the tail end of transport to the hospital and they usually spit out wild numbers. An auscultated bp with a stethoscope and sphygmomanometer is the gold standard.
Bottom line, If you are having chest pain, call 911.
I googled a bit and I'm not sure I would follow the new advice simply because it totally depends on getting help to you fast enough such that they can determine if its a heart attack or something else.
In the writer's case that help never came, so personally if I had to choose I'd rather go with the risk of guessing the symptoms wrong and making things some percentage worse vs a possible death.
I don't really get what's special about OCaml with these points they raise? Wouldn't almost any strongly typed language do? Wouldn't TypeScript also tick all these boxes?
EDIT: I wouldn't choose TypeScript either for this type of use case, but not for the reasons they state, that's my point
Typescript (javascript) is kind of a joke compared to what ocaml brings to the table.
Ocaml has a top in class typesystem, a "faster than Go" compiler and (in 2025) good tooling. It allows you to say fuck it and write a while loop if you need to. Hell you can even do OOP. Also it has an incredible module system and full type inference. It also has an effect system, and good concurrency features (ocaml 5).
I cant say many other languages that has all the same features.
It's the combination with concurrency that makes this a hard problem.
And OCaml excels at solving that sort of problem. OCaml and Erlang are the only two languages that I'm aware of that have a really clean way of doing this, in most other languages there is always some kind of kludge or hack to make it work and at best you're going to do something probabilistic: it seems to work, even under load, so it probably is good now. Until six weeks later on an idle Tuesday the system deadlocks and you have no idea how it happened.
What advantage does OCaml have over Haskell here? I find software transactional memory in Haskell so simple to work with that I have lost all fear of concurrency, but what am I missing out on?
I personally find OCaml more pragmatic than Haskell.
Haskell has a steeper learning curve IMHO: monads are pervasive and are hard to understand, laziness isn't a common programming pattern and it adds complexity. I find type classes confusing as well, it's not always clear where things are defined.
I like that OCaml is close to the hardware, there are no complex abstractions. The module system makes it easy to program in the large (I love mli). If you avoid the more advanced features, it's a super simple language.
I should have specified. I wasn't asking about OCaml vs Haskell in general[0], but what advantage does OCaml have with respect to concurrency?
[0] I think most people just end up post-rationalizing whatever choice they have already invested in, I know I do :) With that in mind, maybe I as a mainly-Haskell dev should instead list some things I miss from OCaml: faster compile times, non-recursive `let` by default, polymorphic variants, labeled arguments
Its mostly about practicality. Haskell is kind of pain when you need IO, as in when you go there there is no way out.
Ocaml is more practical, and less punishing (you can do IO without monads), but the most important diffrence is performance. Haskell is VERY hard to make predictable because its lazy. Ocaml is strict so general system performance is much easier to predict.
But they are sibling languages in my book, while i still prefer ocaml over haskell.
Also IMO the dev tooling is better for OCaml. Far better compile times.
A big part of interacting with APIs (which I imagine Stategraph does) is just dealing with records, and working with records in Haskell is really annoying unless you bring in lenses which bring a lot of complexity.
TypeScript does not have an equivalent to PPX infrastructure AFAIK. If there is, it's definitely not as widely used within the ecosystem compared to PPX for OCaml.
Besides the better type system, OCaml is a compiled language, you don't need workarounds like rewriting code in Rust and Go, as it happens on TypeScript/JavaScript world.
Certainly there are specifics between the type systems that differentiate. TypeScript generally chooses to enforce types in an ergonomic way whereas OCaml chooses to enforce types in a sound way. Whether or not that is a meaningful differentiator for someone is up to them.
This blog post shows the elements of OCaml that motivate us to use it. Is it complete? No. Maybe it should be more explicit that we like using OCaml, and these technical aspects aren't unique but certainly benefits we see.
Functional programming is immutable by default. TypeScript and many other typed languages don't really stop you from clobbering things, particularly with concurrency. Rust does. But immutability with GC is a lot easier to use than Rust if you don't need the performance of Rust.
That is only true since people started equating FP with Haskell.
OCaml as the discussion subject on this thread, allows for mutable data structures, and I am old enough to have been taught Lisp as one possible avenue for FP.
But what is functional besides haskell? Purescript? Elm I guess. Ocaml is not. It has for loops even. You can write pure functional ocaml but people don't. It mattered a lot less when it didn't have true concurrency, but now clobbering things in ocaml is quite possible.
My point was that without any escape hatches or magic you can code a segfault starting in ocaml5. That may be true of haskell? It is true of rust too, though the only known way to do it isn't something that is likely to happen by accident and is tracked as a bug. In ocaml5 if you use domain, it is down to experience skill, and some luck to be sure you used atomic when necessary. I'm a bad programmer despite going on four decades of experience. I'm not even remotely methodical. If I adopt ocaml for a project I'm using 4 or adding something that fails the pipeline if it finds domain anywhere.
It shouldn't, the OCaml 5 memory model bounds the reach of data races in both space and time. [1] Thread-unsafe code won't be correct when misused, but it will stay memory safe unless you reach for an additional escape hatch (or you find an implementation bug of course).
You are right! As of 5.1.1 at least it catches the cross domain access I was using to smash things. From what I am reading it sounds like it didn't work in 5.1 I could go try it in godbolt to find out when it was fixed, but I kind of don't care. Very exciting, I like ocaml and was lamenting the changes.
That makes a lot more sense: The earliest 5.x releases weren't stable at all despite the non-prerelease version numbers. I waited for longer than I wanted to before upgrading from the LTS to 5, but right now it should be ok to switch as long as the few regressions, like the GC pacing issue, don't affect you workload.
Pure functional programming languages do not allow mutable state. They can simulate it with monads, and they typically have impurities to allow io sode effects, but a for loop is an inherently imperative construct. Mostly functional languages like ocaml have things like ref. Functional languages aren't just about functions being composable and having no side effects, they also require that once a value is bound to a name, that it does not change. That isn't just pedantry either, it is what allows safe concurrency by default.
Ocaml is immutable. It has ref if you need mutation, this is not the default thing you grab tho. Haskell has unsafe and IORef, that does basically the same thing. Scala, rust etc has all escape hatches.
A loop by itself is not non-fp, as i can do the exact same thing via recursion. Its just syntax.
Hell, i can write a never halting program in lambda calculus with a fixed point combinator causing "undefined behaviour".
OCaml has a much stronger type system than Typescript.
The real question is "why not Rust?". I've used both a fair bit and OCaml's only major advantage IMO is compile time. That doesn't seem compelling enough to put up with the downsides to me.
I'm the CTO of Terrateam. For "why not rust", I have found the downsides of Rust not compelling enough to use it. We don't need close-to-metal performance. We don't really need the borrow checker, a GC is fine. We are immutable by default so the borrow checker doesn't help much there.
Great choice by way, I feel too many reach out for Rust, because they lack the perspective ML type systems are not something introduced by Rust, rather a long linage of languages since ML/Standard ML.
Plus, OCaml kept the SML tradition in its robust module system, with modules as first-class citizens and ML-style functors, this is something hard to see nowadays, even among ML-inspired languages.
The sense I get from some comments is that if you need a type system and to compile to an executable, Rust is the only option, otherwise you can use pretty much anything. But, as you say, MLs have been compiling to binaries for decades. One of the first online books on OCaml is for systems programming.
I know that isn't everyone's view, but I do hope posts like this, even if not technicaly deep, at least let people know that there are lots of options out there.
I don’t like OCaml myself, but I’d pick it over rust here as bare metal perf is not necessary, and time wasting fighting the borrow checker is just not worth it.
It is worth it in my opinion because it's mostly a one-time cost (learning how it works and what is allowed), and in return you get less buggy program structures (it basically forces you not to write spaghetti code). Also you have to worry about it much less if you don't need 100% performance and are happy to clone everything.
Occasionally I do still fight it, e.g. if you want a self-borrowing structure there still isn't a great solution (I think Rust should support position independent borrows) but overall it's fine.
Answer is easy, not everyone needs the performance boost provided by borrow checker, 99% of the time some kind of automatic resource management is good enough.
I gave it a spin with Gravity's Rainbow. Most of the recommendations are what you'd expect, Pynchon himself, Don Delillo, David Foster Wallace... and then right at the end... The Hobbit, or There and Back Again >.<
Could be a cliff fitness function. Heard about this relativ typ schizophrenia here on HN a while back. The idea is that some phenotypes promote survival of the species overall, but due to random mutations are sometimes detrimental to individual members of that species
It could also be indirectly linked to other benefits. Humans have lost the CMAH gene, making us able to run long distances and hunt down large prey animals. But because of this we can no longer process specific sugars that you will still find in mammalian meat. That causes inflammation and arteriosclerosis. But those things only kill you after many decades, so there seems to have been a net positive effect on evolution.
This idea can generally work, but one should be careful of 'just-so' stories in evolutionary biology.
It appears this deletion happens in other animals and may be attributable to pathogen pressure. It's arisen multiple times, which makes it hard to claim that it has a specific role in primates (beyond its presumed antimicrobial benefit, which any animal should enjoy).
Evading pathogen pressure is just another benefit behind the scenes. The point is that I would be careful to attribute any of these things to such weird mechanisms when there are so many much more realistic explanations that we just haven't fully uncovered yet.
> Evading pathogen pressure is just another benefit behind the scenes.
I'm imagining that this relates to a specific pathogen that may no longer exist (like the presumed mechanism of the most common cystic fibrosis mutations and cholera).
I'm not sure how this would relate to humans running, however.
reply