I'm having some success doing work on my own, so I decided to create a version of my site for the US, specializing in providing maintenance services for WordPress sites. It is not the most intellectual work, but I enjoy helping small businesses with problems that can really affect them:
Elixir's heavy reliance on pattern matching has always made it kind of "dynamic language where you still have to think about types" vibe to it. It's also always had a spec meta-language (taken from Erlang) which a lot of people use. You should read up on how they have been implementing the type system, it's pretty interesting! I would not say it's "bolted on." It also has full inference so all codebases get the benefit of it whether you specify types or not.
Yes, it is what I found works so well. It is easy to write short, specific functions in Elixir and adding Typespecs to theses functions is like typing a block of code. Within the functions everything is "easily" understandable.
The issue with TS is that it's not really a type system, it's mostly just comments with a linter bolted on. It tries, but it's fundamentally broken in too many ways.
Here's just one very simple example, there are many more. I've checked all the strict mode options and this appears to still "typecheck".
var x: {a: number} = {a: 1};
var y: {a: number|string} = x;
y.a = 'FAIL';
var n: number = x.a; // not actually a number
1. TypeScript doesn't aim to have a sound type system. i.e. there may be things the type system accepts that are actually unsafe.
2. this is more of an issue with mutation. If those properties were marked `readonly`, then the assignment of y.a wouldn't work at all. You can also encapsulate mutation behind functions with your intended types.
I tend to write TypeScript in a "functional" or "immutable" way, and in this case, most soundness issues come from things like array index access, which can't really be solved without dependent types anyway.
With that said, TypeScript still gets one quite far *despite* soundness not being a goal of the type system. The problem is that writing imperative, mutable code will make you go through (intentionally!) unsound covariance of types. Similar issues exist for code with side effects, since TypeScript has no way to encode effects in the type system. This is why some language communities settle on ideas like "functional core, imperative shell", where the ultimate goal is absolute minimum amount of code involved in side effects and mutation, while everything else is designed to be easy to test (and, ideally, expressible with a sound subset of your type system).
I agree. The sheer amount of flexibility it provides makes it both hard to use/read and also not particularly safe/sound. No other type system in existence allows you to be as incoherent as TS.
You didn't like Purescript? It looked pretty cool to me. Its main competition back in the day was Elm, but Typescript has now taken over. From a distance Typescript seems to have too many gaps. I haven't used it though.
I think TypeScript can feel like there's too many gaps because not enough people take it seriously enough to truly learn it. Hardly anyone reads a book about best practices/design the way many do about C/Java/Rust.
It's actually a very powerful tool when used thoughtfully. Although it wasn't the first structurally typed language I tried, it's the one that made me fall in love with structural type systems
You use Zod if you want runtime features. I'd say it's pretty industry standard. On the type level there's no reason it couldn't account for any of the examples you pointed out. And since Zod supports all the expressiveness of the actual language, you can certainly have those as runtime checks
I would also just like to point out that the "It Misses" your robot pointed out aren't actually flaws with TypeScript but flaws with JavaScript.
I think Elixir is taking a very mature path to typing. No type-annotations (yet) just type inference from existing language constructs like function guards and pattern matching. Also trying to minimize false positives, only giving type errors when it would provably crash at runtime.
I've experienced this, but it's mostly because languages like Python and TypeScript give you way too many escape hatches. I get the intent: allow devs to convert their code base slowly. But in practice it just lets developers opt out of the benefits of typing to "save time" in the short run.
Once you are squarely in a Typescript program and not a "Javascript program gradually adopting Typescript", it would be a good idea to enable Strict mode which forbids implicit-any, effectively meaning the only places you can omit type declarations is where the language will infer the type. Typescript for instance does not infer types of function arguments via their usages (like Flow does), which means in strict mode you must explicitly provide a type for all arguments within a function declaration.
I used to be a bit of a pragmatist when it comes to strict mode, but over the years that has subsided, nowadays I think it is plainly obvious that all Typescript programs should use strict mode unless there's a damn good reason. And I'm not sure there are any legitimate damn good reasons.
True there is no ability to forbid an explicit-any type declaration, though.
I’ve never had a real problem with developers opting out. It’s not that hard to enforce coding standards.
The real problem with Python is the inexpressiveness of its type system and the mess of typed dicts, dataclasses and pydantic classes.
TypeScript may fail narrowing here and there or require a superfluous assert, but usually writing properly typed code, especially with zod, is the path of least resistance.
As long as you're fine with the types being semantic gibberish because all agents I've used take the lowest effort approach to make the error go away.
You probably have the same logical type duplicated in 3+ different places (at least partially), including inline casts using type literals like "maybeCat as { meow(): void }"
I keep getting baited by these comments so this is the last one I'll respond to, lol.
Elixir is always been sort of a "typed dynamic language" due to how baked in pattern matching is. Any good Elixir developer has always been thinking about types anyway, it's almost impossible not to.
Also, as I kept forgetting to mention, there are no overloaded operators (`+` only works on numbers, for example... unfortunately it does work on both ints and floats but that's another story). The one pain point is that comparriason operators works across all types, but the compiler has already been warning against doing that for at least a year now.
Ok dang. Well. I guess I have no reason not to dive fully into the elixir now.
I’ve toyed around with it a handful of times and I really like it. I like the clojure-ey immutability and threading operators and such. And of course I’ve heard so much about the magic of the BEAM and the phoenix framework. But between typescript and clojure I’ve never felt like I needed anything else.
But if the type system is pretty good, that’s a huge plus over clojure in my book.
JS was designed well. Got a lot of things right that others copied later, and also made improvements without breaking compatibility. And the random weird things like [] == 0 don't come up much in actual usage.
I don’t think JavaScript’s syntax was ever designed with the idea that TypeScript would one day exist. Yet somehow it feels like it left the perfect open spaces for TS to later occupy.
They did get lucky with that. The Python type syntax ended up being similar, but the implementation of type-checking is confusing, also it was annoying how you needed to import the types of basic collections for a while.
I have not seen the numbers, but even a game running 10% faster does not replace the fact that many games wont even start in Linux (League of Legends for example).
Is this even true? I mean, Windows is the main focus for all hardware vendors, and everybody who has owned a PC knows that malfunctions are unavoidable. If that is the case for Windows, then Linux cant be better.
20 years ago your Linux installation might not include wifi drivers, bluetooth support, decent GPU drivers, fat32/ntfs drivers, or the widely used video/audio codecs of the era. And you had to be careful when shopping for things like wifi cards, as only certain chipsets could be made to work.
Much of which was kinda fair enough, because if you're a volunteer making an open source OS because of a strong belief on the open source ideal, you don't want to distribute closed-source driver blobs or patent-encumbered codecs. But it meant mean the initial installation process was not always easy. One of the things that contributed to the success of Ubuntu was a particularly easy initial setup process.
Today, things are a lot better - you'll still get unsupported hardware from time to time, but it'll be much less severe. If your laptop has a non-USB integrated camera you might have to download and install a kernel module. Your corporate laptop's built in fingerprint scanner might not work, but who cares?
> 20 years ago your Linux installation might not include wifi drivers, bluetooth support, decent GPU drivers, fat32/ntfs drivers, or the widely used video/audio codecs of the era.
To be quite fair, this is pretty much the only reason Ubuntu exists. It started off as "Debian for people who just want stuff to work", but these days Debian even ships non-free wifi drivers on the install media. I've personally used both extensively and apart from the "enterprise support" argument and the minor convenience of having ZFS pre-compiled, I see no reason to use Ubuntu.
When I was shopping Lenovo.com for my ThinkPad in 2018, there was a table with ThinkPads certified for Ubuntu Linux in one column, and certified for Red Hat Enterprise Linux in another column.
I chose the T580 as a RHEL-certified notebook, and it was fantastic. Lenovo.com let me configure each individual component exactly according to my needs and tastes, and it was custom-assembled and shipped from Shenzhen.
It did arrive with Windows 10 pre-installed (this was the least hassle and most popular OS option). I initially installed CentOS, but quickly realized that Fedora would be the sweet spot, and so it was a Fedora system for most of its lifetime. Near the end, I did revert to Windows 10, which also worked flawlessly.
The ThinkPad T580 literally never malfunctioned. It was still 100% working when I turned it in for recycling in 2025.
I've also run Ubuntu on my "daily driver" desktop system, which ran from 2006-2022. Yes, that's 16 years' worth of Ubuntu installs and upgrades. It was mostly a KDE Plasma (Kubuntu) system. I enjoyed every bit of that.
In 1999, I was avidly using OpenBSD on really old hardware (such as HP Apollo 425t workstations.) OpenBSD simply couldn't deal with the special graphics subsystem on those machines. I tried and tried to get something working, but there were obstacles, not only with the hardware and drivers, but also the monitor connection needed a particular type of cabling and a proprietary monitor, too.
However, OpenBSD did great for networking, security, Squid cache, proxies, all kinds of things. And even in 1999, though it was early, I ran Linux on a 386DX-40, because Linux supported the "ftape" floppy tape driver at that time, and I had some kind of QIC tape backup from Eagle that wouldn't be recognized by OpenBSD or NetBSD.
Meanwhile, in that same year, my "daily driver" desktop machine was a 486 with VLB, dual-booting Windows 98 and OpenBSD. The Windows 98 was set up with a Cygwin system and X11 server, so that I could run X11 clients on the OpenBSD machines, or the Linux machine, or whatever else was on the LAN.
What do you mean, in 5 years? It's not like everyone just bought a new computer. My gut says it's exactly the other way around: most computers are old. They may fail as soon as today.
There is enough older hardware floating around to last us for decades. You don't need a gaming rig to do 99% of your computing (excluding gaming obviously). Also computers don't really just break. It's mostly the disks that wear out and PSUs that age.
Right now Im working on so many thigs, but none of them as interesting as the things that other people here do.
I manage a small store (https://amigurumis.com.mx) for my SO and im dropping Elementor (too expensive) to use only Gutenberg. Turns out that it is pretty good for simple sites.
Im having some sucess developing new websites for people who cant afford it, or who never though about having one, so i created one for an accountant (https://contadoranual.com) using only WordPress.
Is Love2D a decent option for gamedev compared to Godot? I finished a really simple game using Unity3D and it was fun, but it sucks to use a closed source engine.
Löve on the other hand is 100% just code. You'll not have the gui things and the pletora of different components that go with them. Still gives you freedom. Just too much freedom and not as much helpful preset tools.
Yeah, Love2d is a great option for gamedev. It doesn't have the same built-in tools as Godot so you'll need something else for putting together maps (use Tiled [1]), and you'll need to write your own main/render loops (these are just two for loops, nothing fancy).
It’s very different, and it depends what you are targeting. I love love2d.
I think love2d is better if what you love is coding, everything is code, love2d just executes Lua.
If what someone wants to do is make (for example) a 2d platformer, or definately for 3d, and the coding is something you need to do to make your game, goody is better, it includes so many batteries, have a built in gui level editor, etc.
One big advantage of love2d (although ironically not loved by many in its audience) is it is the AI friendly engine, as AIs love text and hate GUIs.
Fair point. I could have expressed it better, but what I mean is that as long as you install plugins trusted by the community (ACF, WooCommerce, Yoast...), your site should be safe.
https://us.alprado.com