The way I see it, AI is going to change the world radically. It could be for the worse, the better, or a mix of both, but in my mind there's no doubt.
We are only five or six years into the leap LLMs represent. For reference, radio waves were discovered in 1886, Marconi used them for communications in 1895, and while telephone and radio coexisted for many decades, it wasn't until the 1995 that mobile phones and wireless technologies started picking up. It took so long not because of the physics of radio waves required time to mature and improve, but because everything else needed to profit from it did require time.
To me, LLMs are not so much AI as it is a building block. Radiowaves maybe, or the equivalent of transistors. We are already seeing that it's possible to chain LLMs into agents. Currently, price is a strict limiting factor for coding and agents.It's probably fine-ish if all you want is Claude Code or Codex, but there are many other possible compositions of LLMs that most people don't dare to experiment with. For example, LLMs to drive NPC dialog and world mechanics in games is not a thing due to cost. Were prices of inference hardware go down and inference algorithms keep improving, I'm convinced (and afraid) we would see things very difficult to imagine today.
> For example, LLMs to drive NPC dialog and world mechanics in games is not a thing due to cost.
Hah, I'm actually working on just this problem.
Cost isn't the issue. There are only so many coherent (in context) responses and scenarios, that you don't need an LLM to generate text in the game, in real time. Instead, you can have LLMs build a vast corpus of "atoms" (dialog messages, fragments, cues, etc.) that can be stringed together in a deterministic way in response to player input. These can also be pre-screened and subjected to various tests prior to implementation.
To a player interacting in the game, a system like this would seem functionally indistinguishable from generated text within the game's designed interaction envelope. And it has huge advantages: Although it can expose seams if the player breaks character and decides to probe it, it won't be exploitable the way an LLM would be.
> The way I see it, AI is going to change the world radically. It could be for the worse, the better, or a mix of both, but in my mind there's no doubt.
Worthless statement. Wow, you suspect something can make things better, worse, or both? That's a keen insight there.
> For reference, radio waves were discovered in 1886, Marconi used them for communications in 1895, and while telephone and radio coexisted for many decades, it wasn't until the 1995 that mobile phones and wireless technologies started picking up.
We are still so early.
I mean, we have advertised them in multiple super bowls, have companies that basically own tech news (incredulous journalists will repeat any stupid insane shit a CEO wants to say), that say they're valued at over a trillion dollars and nobody with the power to argue those finances seems willing to do anything but agree. We have built hundreds and hundreds of acres of data centers (and made deals for data centers that are never going to happen) that demand *billions* per month. They are devouring all the silicon to where people are visibly seeing the price of hardware double, triple, more in price. Work places insist on employees using AI (then pulled back because it turns out this stuff costs money and it's not fun anymore when it's not subsidized).
But we just need more time, more eyes, more people looking at it.
>Far more interested in dialog and characters developed by a writer - simulation is boring
It entirely depends on the situation. Background NPCs that just have conversations among themselves would be a great use of LLMs to make the world feel more immersive. Obviously you never want to directly engage the player with LLM generated writing.
If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
Hallelujah, that's always been my position. To the static typing folks: leave my dynamically typed languages alone and go coding with something that really suit your needs. If the answer is that Python, Ruby, JS, whatever are really much more pleasant to code with, my reply is that they are so precisely because we don't have to type type definitions. Tradeoffs.
I think types are particularly valuable for libraries. A library author using copious types really helps the downstream user to know "Ok, this function returns a dict(Foo, Bar)". But after that, it's a matter of preference if you want to add those types to your own code or not.
Having the types in the libraries makes it a lot easier for your tools/IDEs to give good suggestions and catch bugs that you might otherwise miss.
> And if you aren't using an IDE then you can pretty much ignore it anyways.
No. I can't. This completely misses the fucking point entirely.
I use python because. it's. easy. to read.
And figure out what the fuck is going on.
This example is the complete antithesis of that.
> You are in exactly the same position as if you knew or didn't know that type.
But I'm not in exactly the same position as if the fucking static typing weenies hadn't gone and convinced everybody to massively increase the size of the codebase with impenetrable extra crap.
Part of it is due to the clunky `_NoArg.NO_ARG` business for optional params. Pretty-printing it would also go a long way, but that technology seems too advanced for any language circa 2026.
It's probably hard to come up with something messier than SqlAlchemy here. Not an expert, but spent more than enough time spelunking queries in the debugger. I much prefer bugs that can be surfaced at compile-time rather than run-time.
This is even worse because you attempt to try to sell why types SOMETIMES make sense. But you aim with this for a language that did not have nor need types to begin with. People don't seem to understand that this is an issue.
The library-situation is really not different from having types everywhere, and some people will do that too.
> catch bugs that you might otherwise miss.
People repeat this a lot. In about 22 years of writing ruby code, I have never ran into a situation once where I would have caught a bug through types. I don't understand why people keep on repeating this. Repetition does not make it anymore true.
Think in the opposite way: if types would have been necessary to begin with, why would ruby have been successful back in 2006? It was successful without types already. And types were never needed - they came because some people THINK they are needed. This is the biggest problem - the thinking part. They think they are right and all who do not use types, must be wrong and very foolish people.
> In about 22 years of writing ruby code, I have never ran into a situation once where I would have caught a bug through types
You must be the world's greatest programmer with perfect memory. Every nil pointer exception is a bug a (good) type checker could have caught. You've never had a NameError or NoMethodError in Ruby?
Have you considered these people in general aren't some outsiders out to attack you or your favorite language?
The people who do end up making and using type checkers are people who have or are actively using these dynamic languages and found out that they CAN help THEM with preventing bugs.
Also, really? 22 years in which not one type-related error happened? Never? I don't want to say I don't believe you, but I really don't.
SRE here, I've had multiple outages caused by lack of typing in both Ruby and Python where bad types get passed, something doesn't catch it and either data corruption or constant crashes. Couple cost us big money because it screwed up billing and we were forced to eat the billing cost.
>In about 22 years of writing ruby code, I have never ran into a situation once where I would have caught a bug through types.
I've definitely ran into that although much less common at places with good test discipline.
I think the related and often conflated problem is errors caught by compilers which you don't hit til runtime in Ruby/Python without good test coverage. For example, referencing an undefined variable
This is perhaps the least believable comment I have seen on HN, ever. It would be more believable for someone using C to say "In about 22 years of writing C code. I have never ran into a memory bug".
It kind of is? All the partial-typing systems are too complex and usually broken in various ways. Compare to eg Elm or Gleam which are typed and super simple.
It kind of isn't. We are talking about using types in type optional languages. We aren't talking about the quality of those type systems or whether or not they are good type systems.
If I was comparing type systems then it'd be relevant to talk about statically typed languages like Elm or Gleam.
Personally I like having my TypeScript cake and eating it.
I also truly believe those who design type systems would benefit from taking a look what kind of code people programming in dynamically-typed languages produce.
I do too, but I feel like TypeScript stands alone as an unusually effective and pleasant to use bolted-on type system. I've not seen any other approach come close. (My sample size is Python, Ruby and Elixir)
I really like PHP's type hints (I think they were the first I used) though it's somewhat limited (can't type hint complex/nested structures last time I checked).
Flow for Javascript was okay but Typescript I've found to be much nicer (last used flow years ago but occasionally I'd encounter bugs in Flow).
you don't think the elixir type system is effective? I've never seen a bolted-on type system get so much acceptance from the hardcore "you can add types into my dead hands" crowd
I find it funnysad that python people coined the phrase duck typing and then ended up designing what they have now. Meanwhile TS manages to embody duck typing far better even though coming from very different background.
Does Python needs its own TypeScript moment? Many times, while writing Python and deeply frustrated with its weak(er) type system, I have dreamed of something like TypeScript or VB/VBA from the early 2000s (where the type system was surprisingly strict!). However, there are so many Python libraries written in pure C, it is way harder to create a TypeScript equivalent.
Could you point me towards the kind of code people programming in dynamically-typed languages produce?
I have lived in statically typed languages almost all of my life, and even when I don't, I pretend I do, just without having a typechecker. So I'm very curious about what I'm missing.
I hate TS's tooling with a burning, deep passion. But its type system is actually pretty incredible for what it is.
There are times that I yearn for TS's ability to do duck type reasoning in e.g. Rust (despite that not being feasible) when working with very large data types.
So far I have been avoiding Pydantic as a huge-ass dependency. Instead I am relying on standard type annotations, lots of typed dicts and at service/program boundaries use a jsonschema. I like being able to specify the type of most functions, and get some hints, completions and so on, but I don't want to _have to_ specify every darn type. I also don't want to write a class for everything. Typing dicts is good and usually sufficient. If I wanted to write types for everything, then I could also just write Java or Rust or similar.
Unfortunately, I think the kingdom of nouns faction has long invaded the Python world and I see more and more companies demanding Pydantic and similar things. They are dragging us all the way to Java land, it seems.
My engineers write better code when we enforce types.
It's easier to do this then retrain everyone on Go and rewrite all our code.
New stuff is often in Go now, but prototyping quickly in Python and then enforcing types when we have to get it ready for production has been working decently
I started using types with Python in 2018-ish, and I never looked back.
I am not that good a programmer, so maybe I am wrong, but I just like being able to tell what the data is that's moving through the system. Typed function signatures, a little shift+k here and there, a warning that I am trying to add int and a string. I don't see what's the harm in having that?
At the end of the day, if you don't want to use Python with types -- do not. Unless somebody at work is forcing you, and it feels like putting lipstick on a pig (especially with something like numpy that doesn't easily support types)? Then condolences.
For personal projects, I don't want to learn Rust just so I can do `def add(a: int, b: int) -> int`.
For work, I don't really get a choice. I work on brownfield projects. We do use TypeScript, thankfully, for all the browser bits. But nobody is going to stop to refactor a 5 year old production code base from Python to Go just for better types. And -- pepega -- definitely not our codebase that's full of data sciency stuff (numpy/opencv/pandas). So we live with a not-as-good-as-it-could-have-been type system.
Meh, the amount of effort required to keep up to date with the python ecosystem churn is around the same as learning rust. More so if you are starting from scratch.
I quit python after realizing the amount of effort it required to just implement the tooling for a project… when all of that comes included with rust. I have spent maybe an hour in the last year thinking about tooling. Glorious.
But yeah, I feel for you. It is an impossible sell when they pay off is impossible to understand without a Time Machine and the only thing known about the cost is that it’s high. But for new people and projects, I can’t imagine starting with python in 2026.
Which Python tooling? I know that uv is replacing pip but all of my costumers' projects still use pip. One of them installed python with asdf. I can't think about any other tool we are using except Claude, but I don't think that's the kind of tool we are writing about. We deploy with a custom bash script resembling Ruby's Capistrano. Those projects are web apps with server generated HTML.
The only reason I gave up resisting and started writing any significant code in Python at all was that it got some kind of type system, and thus became less unpleasant to code with.
"Pleasant to code with" does not describe getting "AttributeError: 'NoneType' object has no attribute 'foo'" 25 levels deep in a stack trace already obfuscated by dynamic object-oriented nonsense. In production, because it's an unusual case and testing missed it. Not that test cases aren't way more work than types anyway.
Historically (80s/90s) I started using Perl because I didn't have to write all those malloc and free I spent years writing in C and I could perform string operations much more easily. Then in the mid 90s because of that wonderful CGI.pm Perl module. But the plus of all those languages, and Java, was managed memory. Then in the mid 2000 I learned Rails, and after Rails I learned Ruby. It was like Perl but much easier to understand and again no types to type. Basically what I did in Java but in a fraction of the time and in a fraction of the lines of code. Then a customer asked me to work with Python on a Django app so I learned Python. It looks like a Ruby designed by Klingons but it's OKish.
All those bugs I constantly read about, they don't happen very often and are a good tradeoff. Maybe Rails and by Django are shielding me from some bug scenarios.
> To the static typing folks: leave my dynamically typed languages alone
Surely you understand that the push to add types to dynamically-typed languages comes from dynamic-typing folks, not from static-typing folks. People who are deeply into static typing have little incentive to consider e.g. Python, whose support for types is relatively weak, loosely-defined, and rarely-enforced compared to the statically-typed languages that exist today.
I am totally with you and I am glad I am not the only one who is totally against those type-addictions leaking into languages that did not need them in the first place.
Types in ruby are even worse than in python, because the type systems in use really make ruby turn very ugly. In python it is not as much as a huge problem with regards to syntax, as python has a stricter syntax (e. g. mandating foo.bar() whereas in ruby you can typically omit the (), among other syntax sugar examples).
We need to keep the type people out of those languages.
Many years ago, on IRC, on #haskell, they said they don't want everyone to use Haskell. Back then I did not understand it. After the type-addicted people emerged out of nowhere, I now begin to understand why Haskell is so snobbish. If you let every idea float, you end up ruining languages - and then those who wanted this, will retire and move away too. Ultimate damage factor caused as outcome here.
Nothing can beat the Python numpy/ML ecosystem. There's a lot of value in just being able to run a Python script as well without any compilation step. The typing isn't perfect right now but it's usable.
For vectorizable problems there also won't be huge performance gains from switching to a compiled language because all the hard stuff is already done in highly optimized native code. The only time it really makes a difference is if you have to write a custom for loop or traversal.
Running more type checkers isn't really about strictness. The main benefit to library maintainers is to make sure that their APIs are compatible with whatever tools their users run.
This wouldn't really be an issue for most other languages, but Python's typing ecosystem is uniquely fragmented, with only partial standardization between several popular tools.
GP's point is obvious: performance is immaterial to the discussion. Static code analysis is about preventing bugs. Therefore OP fails to make any sort of point, as it's a straw man argument.
I think those of us who work in compiled languages are just snooty about them.
I'm a compiled language snoot, and happen to be working over the past couple days in typed Python for the first time. It's kind of nice. I like it. It's a huge improvement for me over ordinary Python/Ruby/Javascript; it materially improves the experience of working in the language.
> happen to be working over the past couple days in typed Python for the first time. It's kind of nice. I like it.
I like me a good type system and have always hated about everything about types in Python. What do you find nice and like about it?
(My experience with Python: all the type checkers are broken, there are false positives and false negatives everywhere. The LSPs are likewise broken, I have not found one that knew the types at least somewhat reliably...)
Lack of typing is my biggest problem with Python, Ruby, and ES6 Javascript; I have to write everything twice, once to do the stuff I want, and once to double check that it's actually doing stuff, because a single typo blow the program up despite it parsing fine.
Python typing is easy to dip in and out of. It handles None nicely; not as nicely as a true Optional, but enough for daily driving. The annotations are readable and simple. What more could I ask for, without asking for an entirely different language? Python typing catches a lot of bugs I'd otherwise have to tediously unit-test for.
The only thing I don't like about it is that it feels like it relies a lot on importing stuff from the swamp of the Python stdlib.
I believe you are right to point out how you feel about some of these features of a particular language, and to let that guide your decision in how and whether you use them.
It does not, however, say anything about the actual productivity gain or loss of using types in a language like Python which does not require them — that should be the ultimate objective measure of whether they make sense or not.
With most languages, I get annoyed if I need to create separate types for every variant of a basic type (eg. let's have a firstNameString, familyNameString, CountryCodeString, CountryNameString... when is it too much?) - I do not think there is any way someone can prove going this deep improves maintainability long term. Eg. imagine you introduced validation of CountryCodeString based on ISO-3166, and there has been a change to ISO-3166 which happen every couple of years — how do you start supporting new codes? How do you deprecate and remove old ones? All of those are not helped with a type being very strict, you still have the persistent data to worry about, code actually supporting any of those, etc — the basic type check is trivial with a couple of small unit tests in comparison. You also quickly venture into a territory of complex types with complex interaction rules (this subvalue can be one of A if another one is X; but B if another is Y).
So for me covering the basic invariants with a unit test is not much more effort and — especially with Python — does not stop one from refactoring effectively and building stable, long-running systems.
Really, complex relationships in data are complex, and encoding it in a declarative way using a complex schema does not guarantee correctness (see Pydantic); if you want just very basic data conformance (type) checking, it's mostly a question of ergonomics.
Basically, you need to keep to some principles of code structure and architecture, but they are a simple set of principles — perhaps the fact that most Python projects do not abide by these should be a knock against Python? I only attribute it to the approachability of Python, but I am open to being wrong and this being the latent forced idiomatic use that projects always evolve into?
What I like about Python types is that they accommodate both styles of programming. I happen to be completely sold on at least some baseline level of type safety (I don't need my type system to be a complete modeling toolkit for everything in my problem domain, just enough for basic sanity), but if you're an old-school Python type, you and I can work on the same codebase without types ruining your life.
> If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.
It is brutal. I can say with first hand experience: The APIs for Pandas and NumPy are awful and insanely dynamic. As a result, it is frequently difficult to know what is allowed with calling a method. It is exhausting. Since many methods are "hyper-dynamic", many of the error messages are unhelpful.
Well, that's the curse of machine learning: since everyone uses Python you have to deal with Python. Even though Python isn't very nice when things start to get serious and you don't want to spend your time fiddling with noise just to make something work at scale.
I'd wish the ML/AI/LLM crowd would see that it is in their interest to get better developer ergonomics at scale. (I don't want to have to turn to C++)
The ML/AI ecosystem is a minefield, and pure Rust rewrites (Candle, Burn, ...) are still immature and incomplete. But I'm pretty sure we're eventually going to see the same uptake that's already happening in the data processing world.
Cython is a niche language for writing perf-critical bits inside your Python codebase. It's like C for people who don't want to learn C. At least that's how I treated it, when I had to write some stuff to make some numpy ops faster.
Cython is not in any real sense a replacement for a modern data/ml stack.
However, I think an ML designed for machine learning would be nice, especially if the type system is extended to multidimensional arrays shapes. Pattern matching on array shapes would be rather nice. Ocaml style interactive mode for exploration and compiling for performance would be nice too.
LLMs are leveling the developer experience and productivity in a way that makes Python's strengths almost irrelevant, while it's still suffering from bad tooling (even with uv and friends) and poor performance.
AI/ML: interfacing with C++ libraries directly (or in Rust) is now a real option. For everything else, even 5 years ago I wouldn't have used Python, now there are even fewer reasons to do so. As far as I'm concerned the remaining use cases are notebooks and one-shot scripts.
> What statically typed language would you suggest for machine learning and large data pipelines? I don't love Python, but it has by far the largest ecosystem.
Pay no attention to OP. It's nonsensical to even suggest you should migrate away from a whole tech stack just because you want to run static code analysis, specially when the argument is based on having too many static analysis tools to chose from. Utter nonsense.
The modern approach seems to be to require full typing on items seen from outside the function or object. Within functions, have the compiler infer as much as it can.
Newer languages (Go, Rust) seem to be converging on this approach.
Function parameters need type info as guidance for people and LLMs calling the function. Even though cross-function type inference is technically possible, it's too confusing. Long-distance inference failures tend to generate poor messages.
Within a function, if you have typed parameters, the type inference engine has a local starting point and a good chance of success on most local variables.
Unchecked advisory typing in Python was a terrible idea. All the work of writing type declarations with none of the benefits.
strict type checking is an incredibly useful tool for cases when you really want to make sure your code is correct and behaving as expected (one of many tools).
There are lots of people who like python and want to use it for things that where incorrect code has serious consequences. Type checking is helpful in these contexts.
Type checking remains optional for the masses and is not practical in many cases. Still, pushing away people who want to use all available tools for writing correct python only hurts the community.
That is why I'm using C# and Rust more now than Python. You get far better RoI on types. and they are so much faster and can use all cores so much more easily.
Yeah, I can't say I really get the appeal of gradual typing. It's commented/documented code at best and outright lies at worst. Sure, you can build tooling around it and improve your DX a bit but isn't it always a house of cards?
If you add one of these type checkers into your CI or a pre-commit hook, it provides the same guarantees you get from a compiler along with the same tooling benefits. It gives you the option of using the structure when you need it, but not being forced to use it when you want to take advantage of some of the more dynamic features of the language.
But none of the runtime benefits of having static types in the compiler, since the runtime still can't trust the types. Still, half a loaf is better than none.
> If you are going to be super-strict with type-checking, wouldn’t it be best to switch to a statically typed language and get the performance gains as well?
I don't understand your question. The whole point of static code analysis is preventing bugs. Don't you like Python code to not have bugs that are easily caught with static code analysis, or is preventing code a foreign idea that is better left to other languages?
Often, when I code in Python, it's because there are some libraries that aren't available in whatever other language would have been my first pick. Then, typing and type-checking are useful tools to stave off the codebase turning into the unruly mess that all Python projects eventually become.
Don't projects in all languages turn into unruly mess by default?
It requires special care to not let long-running projects evolve into it.
Python is only special in that it is extremely productive and allows lots of easy evolutions of a project with not a care in the world, so the timeline is probably shorter on getting to the "unruly mess" if no special care is put in to make it survive many evolutions.
Perhaps a bit special too in that it looks welcoming to the masses who have no idea how software systems evolve and thus do not even know there are some special patterns to introduce for code to survive many changes in the future. I am undecided if this is a pro or a con of the language itself.
Yes, but unfortunately Python has invaded everything, and one must adapt.
Python is going to be preinstalled on almost any machine I use, with a reasonable assortment of libraries. And even if they're not preinstalled, the libraries I want are likely to exist. They'll have unstable APIs and weird quirks, and I'll have to take my choice of bad packaging systems to install them, and everything will just generally be a pain, but they'll exist and largely work. That's not true for any language I actually want to code in. I mean, I'm not going to deny that Python is better than shell scripts or (usually) C.
It's not like it's a pleasant language to code in, especially if you actually want to use the type support, which is weird and irregular and keeps changing and has to work around fundamental design problems at the core of the language.
Python has other, bigger problems that make it a constant headache. One of them being the dismissive attitude towards any and all of problems that come from versioning, dependencies and quirks that make it challenging to have robustness.
Criticisms are typically dismissed by suggesting heaping yet another "solution" onto the growing pile of "solutions" that you have to drag around with you. That people have to learn. That you have to install tooling for. That has to be vetted. That has to become part of the toolbox to get even seemingly simple things done. This attitude is a big part of the reason that I strongly advise people against using Python in production. On top of all the problems presented in a real-world setting.
Almost all of the time, people who are fond of Python are more interested in defending python, disparaging me, downvoting me etc that listen to why I make that recommendation.
(I get it. People like Python. What I think of Python as a language is irrelevant. In fact I don't have that much against it. But I do have a lot against it in a setting where you need reliability and repeatability)
I have spent the last month of my life building a system that can run Python tooling reliably in a business critical application. I knew this was going to be a pretty big job when I started, but for every problem I solve, a bunch of new problems arise. I am starting to see light at the end of the tunnel but it hasn't exactly been smooth sailing. I'm almost there for a first version, but there are a bunch of problems still to solve. Mostly because I care about developer ergonomics and that things should "just work". One important goal is that my solution shouldn't impose any significant cognitive burden on people who use it. That's really hard.
(I don't think the solution will be open source since my contract wouldn't allow for it. But I'll make the case at some point for why it should be open sourced)
And yes. There are statically typed languages available today that have decent tooling that provides superior developer ergonomics. I can understand that people don't want to learn new languages, but if you have the capacity to do so I would recommend trying to move on if the code you write has to run outside your own workstation. If an old fart like me can learn and adopt new languages, so can you.
Python the language is pretty nice. It has its warts, but I make my living in PHP which is practically made of warts. But the python ecosystem still seems to be trying to figure out this whole package management and project setup thing. In most languages I can do some form of `$blub install` where $blub is the language's official package manager or some close equivalent. It's just python that always screams at me that I have to set up and "enter" a virtualenv. I get what venv is for, but it's still a weird hack of hardlinks and relative paths that no other language seems to need, and a clumsy two-step dance of a UX that hasn't improved in like 20 years.
I am not sure you get what virtualenvs are: Python is never screaming at you to set up a virtualenv, it must be a particular package recommending use of virtualenv for easy set up without interfering with the rest of your system.
Virtualenv allows you to seamlessly run multiple Python ecosystems simultaneously, even within the same project directory. It's basically primitive containerisation mechanism that predates any actual containerisation systems on Linux.
You do not have to use it, but then you can easily slip into a sort of "DLL hell" (multiple incompatible library versions installed system-wide) with multiple projects — or need to bundle all dependencies within your project directly. None of this is specific to Python, really — any shared library system has the same challenge. How many other systems are there in active use making it as easy to use multiple incompatible versions of shared libraries per project or within the same project?
When in doubt, you can always retreat to the basics in Python world: put packages you need in a path of your choice, and point PYTHONPATH (sys.path) at it.
What are the problems you have with tooling? Imo it's no worse than most other languages besides a very small handful of recent ones (rust, go) where everything is included
The easy approach is usually just throw it in an OCI container
There's not much concrete to go on here besides "I don't like the ergonomics"
I have a habit of reading obituaries and of getting a small reprieve when the cause of death is not cancer. I have the feeling that, for something that kills one in four people, we should be doing more as a society, and not leave the problem to a small group of people desperately fighting in the shadows. Thank you for your service, Dr. Scoyler.
It's an old person's disease. 30% of all cancers occur after the age of 74, 50% after 50.
I used to work in the pharmaceutical industry and my experience is that people in this field in particular are extremely passionate - you can immediately tell who lost loved ones to cancer.
One of the reasons cancer kills 1 in 4 people because we've eradicated lots of things that killed people before they were old enough to develop cancer. If we ever manage to cure cancer (or some cancers, because it's a taxonomy rather than a thing) then people will die of something else. No doubt we'll then wonder why we never spent enough effort curing whatever that is.
There will always be a reason why people die, and it will never feel like we're doing enough.
"because we've eradicated lots of things that killed people before they were old enough to develop cancer"
The other reason might be, we introduced lots of new cancer inducing compounds.
Also cancer is very complex and a broad term. "Solving" it likely requires solving the human body first, as in understanding every mechanism to the finest details.
Not to subtract from anything you said, but something that could help us, in the aggregate, as a society, is to frame things differently.
Today, most people say "human biology is a thing of wonder" "Humans are built for longevity". And when a terrible ailment strikes, they explain it with "The meaning of life/God/The devil/We must die of something!"
In my mind, we could create a human systems biology profession where students are told during the first day at school "human biology is a mess wrought up by mindless evolution. Your job is to bring it to the exacting standards of perfection that we are able to apply to other things. In the measure we succeed, we will be able to bring dignity to billions of people."
It’s not that we can’t fix things— given enough time and resources. It is just that we need to fix too many things. Each thing fixed only makes a small difference to average uptime, and that will be true for a long time, unfortunately.
We got some big early wins from low hanging fruit of infant mortality and poor sanitation. Everything else moves the needle a lot less, and it is a really long bug list. Our environment does ongoing damage of many different kinds and we wear out.
It's actually both - a thing of wonder wrought up by tens of millions of years of mindless evolution. And most scientists would already be happy to be able to "hack" this incredibly complex system to achieve a certain goal (e.g. cure cancer), not "refactor" the whole code, as you seem to be suggesting.
> If we ever manage to cure cancer ... then people will die of something else.
Well yes, people will still die, but in the process average life expectancy goes up. I think Aubrey de Grey once said that if you cured cancer and aging then the average life span would be seven hundred years or so, based on death rates due to accidents and murder, etc.
> There will always be a reason why people die, and it will never feel like we're doing enough.
That's the best of humanity: love for fellow human beings, and a desire to preserve life. And seeing that we live in an inconceivably vast and empty universe, I see nothing wrong with the idea.
Yeah, it feels like we need a phase transition in the speed and practicality of the process. But I don't believe we need a single concrete lab tech.
Years ago when I did research, my impression was that there was complexity galore. A researcher on Drosophila developmental signaling would have a very disjoint knowledge domain than that of a researcher in horizontal gene transfer and antibiotic resistance. Both would exist in a different planet altogether than a clinician prescribing a cancer treatment. And the three of them would generally lack the tooling that somebody doing systems biology was used to.
So, to me, the key thing we need is some sort of "domain cement", or a good way to pull operative knowledge and usable skills from everywhere.
> the key thing we need is some sort of "domain cement", or a good way to pull operative knowledge and usable skills from everywhere.
Isn't that what LLMs are shaping up to be? Once we manage to divorce the knowledge from the weights in some way we could have in effect a frontier model whose awareness was limited to the sum total of the scientific literature.
I very much respect Espressif products, specially because how good their documentation is. I wish though somebody would package an ESP board with 256 Mb of RAM or more... From what I've seen, that amount of RAM seems to be exclusive Linux SBC territory, but Linux doesn't make sense for a lot of projects.
Oh, this was a fun read and one that kids should have in school before they turn ten.
Because we are not taking things seriously. If ClosedAI or DeepDisTrust or Posthropic come up with something that quacks like a sentient being, our built-in innate reaction is going to be to scorn it, dismiss it and end the conversation. The alternative, to even consider that we fungible creatures who live in apple-eating-sin that got us expelled from Eden can create alien souls, souls that are at the very least our equals, would be teleological Armageddon. It would force us to acknowledge the mutable nature of souls and the malleability of being. We would have to stop believing that the nature of disease and death is more divine than ourselves.
Do those actually qualify as alien, if they're products of our human culture and just the substrate is different?
> We would have to stop believing that the nature of disease and death is more divine than ourselves.
Why? Stopping believing in mutually contradictory claims is not a requirement. Especially when it comes to concepts that don't seem to have a definition, like "divine".
> Do those actually qualify as alien, if they're products of our human culture and just the substrate is different?
I'll posit "alien" is a spectrum.
For the sake of the argument, let's assume that some form of panspermia is real and the same tree of life has reached Earth, Enceladus (moon of Saturn) and TRAPPIST-1 (a different solar system in our galaxy). Let's also say there was a second abiogenesis event somewhere in Messier 104 (another galaxy).
Earth to Enceladus would arguably be already "alien", but there might be similarities, maybe there was something there that looked like one of our Archaea, while sharing none of our Eukarya and having its own domains of life.
Earth to TRAPPIST-1 would be distinctly alien, evolved so differently it'd be almost unrecognizable, but they'd likely still be carbon-based lifeforms sharing the same basic building blocks. Maybe something like lipids forming cell walls would also be seen there, but they'd likely be independently evolved.
Earth to M104, any similarity would be at best convergent evolution. Truly unarguably alien.
>> While you write very dismissive and pseudo philosophical
Even with the "pseudo" in front, I'm very sorry any of my writing sounds philosophical; I didn't intend that sort of confusion :-). The "dismissive" is not exactly intended either; instead, I was aiming for "bitter".
>> enough people do not believe
Here we believe different things. First, enough people, even today, do believe. Second, the body of culture we are raised in accrued during centuries. The vast majority of it comes from people who believed. Everybody in my family was atheist and yet I was raised homophobic, and I have it from good sources I'm not an isolated case.
>> I'm a complex biological thing.
That state comes with a big wallop of misery. For millennia, we have used faith to justify that misery. Not a year ago, I was at the hospital, next to the bed of a dying girl. Can't forget the doctors saying "we do what we can, but we are not here to prevent what is going to happen." Coming from them, it was sensible resignation. Sensible because as long as we believe those things are inevitable and there's nothing we poor humans can do, we can absolve ourselves.
This looks promising, especially the no-account-required part. Does it handle SPAs or heavy client-side rendering well, or is it more geared toward traditional server-rendered sites?
I wonder what would make this better (for some use cases at least) than venerable FreeRTOS? Or Zephyr? Or any of the other many, many RTOSes? In particular, the ESP32 comes with top notch documentation and SDKs that will make beginners at least want to stay with Espressif's modified RTOS for a while.
after looking at it, i would use anything else over the roku stuff if i felt the need for tasking. bare metal esp32 is easy with the espressif sdk anyway .
esp32 is way too power budget heavy for anything using batteries though. even using all deep sleep available a msp430 will leave it in the dust by a large factor. i’m surprised they use such large devices in remotes but go figure
That's also what I was wondering. What problems is this custom RTOS solving that all the other ones don't, or is it in fact just that some Roku engineers decided they needed some job security and having an OS nobody else uses would be a good path to that?
In books, movies and videogames people spend a considerable amount of time in the sewers. In fact, I’m pretty sure they spend more time in the sewers that in standup meetings. Reality mirrors fiction. Speaking of which, some getting acquainted with sewers may be in order for the upcoming AI apocalypse.
I've been in some of these in a different capital city. It's worth it, the visits have informed be what kind of person I'm. It's a subtle feeling of waste, seeing the people queue to the elevator, and then going all the way up to see some bushes growing in misery but enough concrete and rooftops to, well, keep you assured you are in a city. Many of my friends enjoy those places. I just find it way nicer to go for a long stroll in the woods.
> and just do what I want to do all day, stress free, for the rest of my life...
In a saner society, jobs would be the measure of how we are mutually useful and bound to each other, and UBI would be there so that people are not coerced with freezing and starvation into doing things. But, when was the last time people got to negotiate the social contract at such a deep level? The French Revolution? Maybe the Bolsheviks? If we could, would we be able to do a good job of setting up something like that? When one remembers that the biggest democracy on the planet keeps electing Trump, one loses hope.
We are only five or six years into the leap LLMs represent. For reference, radio waves were discovered in 1886, Marconi used them for communications in 1895, and while telephone and radio coexisted for many decades, it wasn't until the 1995 that mobile phones and wireless technologies started picking up. It took so long not because of the physics of radio waves required time to mature and improve, but because everything else needed to profit from it did require time.
To me, LLMs are not so much AI as it is a building block. Radiowaves maybe, or the equivalent of transistors. We are already seeing that it's possible to chain LLMs into agents. Currently, price is a strict limiting factor for coding and agents.It's probably fine-ish if all you want is Claude Code or Codex, but there are many other possible compositions of LLMs that most people don't dare to experiment with. For example, LLMs to drive NPC dialog and world mechanics in games is not a thing due to cost. Were prices of inference hardware go down and inference algorithms keep improving, I'm convinced (and afraid) we would see things very difficult to imagine today.
reply