Crystal might not be the most popular, but it is very interesting to me, I'm not a Ruby guy, but I was looking into other languages other than Go, Rust, etc that are natively compiled, I've dabbled with Nim, but I really wanted to try something slightly different, and I'm honestly impressed, it needs some slight polish still, maybe better funding might help, but in a different timeline under the right conditions, I genuinely think Crystal could have taken off as a really solid language. It's LLVM based, has green threads (that are insanely lightweight), has C-interop, has a comp-time macro system for AST inspection, code generation and removing boilerplate code.
The web frameworks look interesting too, but I haven't deep dived those just yet. You really get a Rubylike language with native performance which is very interesting.
One thing I wanted out of Nim is slightly more Python-likeness, I want regular OOP, since Crystal takes from Ruby (I believe it was originally written in Ruby, before it became self-hosting) it has sane OOP features I miss when I use Go, Rust or even Nim.
I really feel in a different timeline, Crystal could have been something, I also feel like "Ruby" for some leaves a bad taste, but Ruby is nowhere near as awful as most people think, even though it was never for me, it was still one of the nicest ecosystems I ever worked with long before Go got its package management situation situated.
Edit one more thought: I believe the Windows installer / Windows support for Crystal is a newer addition if I'm not mistaken, so it took a while before it got proper Windows support. Well, I just googled it, it started in 2023... but still, that's fairly recent by my book. I think any programming language should strive to work across the "big three" as soon as possible to increase adoption. Go took off the moment it came out for Windows and was formally released.
Opinions vary on OOP being a mistake. Most likely people with that opinion are responding to the influence of Java's popularity in the past. Or the confusion with how Javascript was prototype-based but with Java-like syntax and then it got classes for further sugar coating.
I don't think anyone who regularly uses Ruby or Python thinks OOP is a mistake, it's in how you use it and whether one likes the OOP design of the language.
I think that OOP, like Lisp, lost a lot when Smalltalk machines went out of vogue. Ruby is a super cool language but doesn't have the same breadth as a OOP-as-OS system.
I think the Lisps kind of have up on being an interpreter and I feel they lost some of their power because of it.
I kind of see Ruby waning right now, I don't think it offers much with the development of LLMs. I don't think adding typing is the key - but I anticipate there will be a kind of LLM-powered Smalltalk resurgence
Halfway there I guess, the reason they aren't as you expressed, are the C and C++ layers that exist underneath them, not exposed to the debuggers and such.
Lots of people who use Python regularly, think its a mistake on this, and a lot of other levels. Lots of people use languages, because they feel enforced to do so, and not because of a concious choice.
I get the hesitation from people used to C# or Java where OOP has always been the law of the land, but the rest of us who have used D, C++ or Python... to name a few... OOP is fully optional, and that's how I want OOP in any language, give me multi-paradigm any day of the week.
I would have loved Go more if they had made "lightweight" classes a thing, something feels wrong tying structs and functions, you could have added a wrapper around both to make the code more organized. I guess that's what I like about OOP, organized code. I don't even care about most OOP things, I just want to organize code in a meaningful way.
Kotlin has optional OOP on the JVM. I still use it, but sparingly. Barely ever classes inherit from other classes in my code; I use interfaces, mostly to be able to fake services for testing.
Most of what I write are functions and data objects (records, basically).
One pattern I use is classes with one function, where the constructor takes the functions dependencies, and the function only takes non-dependency parameters.
Functions are an object in Python too, I think that's why they're trying to get at. So you can do some funky things with them if you really want.
You certainly don't have to write OO Python if you don't want to. Objecting to functions being objects like the person you're replying to is, is a flavour of puritanism I find baffling.
Agreed. I saw the announcement and had an inkling of the excitement I got the first time I tried Crystal, years ago. I remembered how exciting new languages were to learn, and putz around with.
Then I remembered I could open [coding agent of choice] and it'd nearly oneshot whatever I would want to try in Crystal. I got a little disheartened.
Some languages for me were never meant to be 'used in production', but were a creative & learning space instead.
As someone who also feels that with new languages, I see it a little differently. To me, the limiting factor of all these langauges was (no shade to Crystal not really the case there these days) most of them have terrible or no docs, have terrible onboarding, have rough edges that may or may not be fixed.
So it was a gamble learning something new could just result in a brick wall dead end where you can't fix the thing, you can't get in touch with anyone who knows how (or has time), there's no docs to help you on the way, the code base is a mess and inscrutable, maybe written the a language you don't know -- maybe even the one you're trying to learn! It could be very frustrating at times, to the point I'd just pass over some interesting languages if they weren't polished enough. Which is a shame because I know there's good ideas in there, I just can't invest the time to make sense of them. Seems contradictory, but designers are not always the best communicators.
With LLMs, all this consternation is gone. Can it write the program for you? I guess... but also not really because for many niche languages with interesting features, the LLM won't do so idiomatically, opting instead to implement enough functionality to scaffold a Python-shaped solution, and then it writes that.
The neat ideas are still there, the learning opportunity is still there, the ability to leverage technology in a way the LLM can't is still there. Especially in a creative and learning space!
This reminds me of how, say, the YouTuber Practical Engineering works as an engineer, but then goes and builds physical models of how water moves under hydrostatic pressure out of perspex and sand in his garage for fun.
People love trotting out this phrase. But on analysis of its usage for the above comment, it doesn't make any sense. Who is the leopard, the breeder, and why are they upset in that above comment? They don't sound upset, just sad.
I think the leopard is software-as-automation, the breeder is the tech industry, and the exact semantics of "upset" are less important than schadenfreude at automation (and ensuing poverty) coming for the automator.
I mean maybe but... There's nothing forcing you to use Claude or what have you to play around is there? I mean an employer might force you to use it but you don't have to in your free time. That's one way I comfort myself lol
You’re right. But the treat was having a hobby that was also professional development. People in other industries have to take courses, study through dreary textbooks… I got to do something I enjoy and get professional benefit. That’s the shine we’re rapidly losing.
I can't comment on the enjoyment aspect, but I'd argue that writing code still confers professional benefits. It might not be the most economical way to ship code [citation needed] but it's still the best way to understand code, and understanding code will remain professionally relevant for a long time yet.
Most of my agentic pilled colleagues get lapped by people using llms as a search tool/ conservatively.
A lot of agentic use creates a feeling of psuedo productivity.
Ive only met two devs who genuinely have supercharged their output with them, but they were also superstars before CC.
The agentic only folks are twiddling their thumbs all day messing with their 20 different meta-agentic tools, thinking that extra thing is finally going to give them those superpowers too.
I think being a "super contributor" has little to do with just having access to llms, but people will downvote this.
I used to see the 20 meta agentic tool thumb twiddling last year such as with Ralph loops and plan modes, but since this year with frontier models, they just...do what you tell them, so I've seen that a lot less today. And thus the people use Claude Code are lapping manual coders, at least from what I've seen.
Seeing the kinds of stuff my coworker is spitting out into merge requests on my codebase via Claude Code is sometimes baffling. It's literally spaghetti code. I won't be surprised if the advent of LLMs causes power usage to surge globally, not only because they themselves use a lot of power, but because the code they spew out is horrendously ugly and inefficient. And then the time they take to sort out the spaghetti code they spat out, to add new features on top, takes even longer and uses more power than before. It's gonna be a mess. I don't see how we can keep going down this road without huge investments into nuclear power collectively.
I may be one of the few to use Crystal in anger for long running programs but unfortunately we had to do away with it because of longstanding issues in the runtime where exceptions at the wrong time during I/O bring the runtime to a halt. It's been a few years so I don't have the github issue off the top of my head anymore. I'd like to think that if they could redesign the language again they would not have exceptions and destructors/finalize.
It's a great language for CLIs though. I'm glad to see the team still pressing on.
Mainly because normal Ruby is an awesome language to write code, and it is also a language that's tried and lost the spotlight because its performance is really, really low, even when compared only with other interpreted languages.
Ruby caught a second wind when they started putting effort into their JIT, which in our testing made it quite a bit faster than every interpreted language except JS in real world performance.
But then Python got a second wind in performance with better rewrite in Rust integration, but it looks like with the latest DHH keynote, Ruby might also go down that path.
My opinion is that I/O and concurrency ease of use and performance continues to be Ruby's weak point vs other interpreted languages. Which also happens to be Go's very few strong points.
It's even more flexible than Go because you can tune different contexts for specific workloads.
Go still has more advanced optimizations and overall better thread-safety in libraries. But we're working on that...
My main critique - which I'm sure you're aware of - is that the hardest part of doing this is predicting what your workload is actually going to be like. That's what Go does so well. It can get almost anything right without you needing to hand-tune it.
While I have you - are y'all planning to implement FSMs and thunks (for recursion) at any time in the near future?
This is something Go is unlikely to ever do unless it becomes a Go2 language.
I don't know enough about your runtime to know if it's remotely feasible given the choices you've made.
Goroutines are roughly 2kb in memory, and Crystal fibers are roughly 4KB, which is insane in any regard. I think Crystal is really interesting and worth considering, especially if you want something native that has OOP, I really would love to see Crystal used more in general.
That is especially insane, when we consider that "B" means "bytes" while "b" means "bits", and "kb" means 1,000 bits, while "KB" means 1,024 bytes (8,192 bits)!
No, "KiB" is the IEC abbreviation, while "KB" is the JEDEC abbreviation for the same quantity of 1,024 bytes. "kB" is the SI abbreviation for decimal 1,000 bytes.
The one time I don't double check my capitalization for bytes vs bits... The sad thing is I usually double check as I type them, must have been in the middle of something and not noticed.
>It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages...
I will say this comes with the asterisk that it heavily depends on what your concurrent system/problems looks like!
...but more often than not when dealing with web problems and network IO, the shape of concurrency/parallelism I need looks exactly like Goroutines, and even as someone who uses Rust/tokio daily: the Go runtime is an incredibly engineered system that usually beats Rust in my experience for application dev tasks.
Anyways, I love Crystal's syntax around concurrency! I wish we lived in a world where it had tons of Google engineers optimizing the runtime :)
If you mean pre-packaged jobs in that specific language, you're correct. However, if you're a Rubyist needing native performance, it's another tool in your toolbox.
Yea but that doesnt help with companies still hiring for language specific roles. Also you gotta be able to check LLM generated code which requires proficiency in the given language.
I've been happy using Crystal for many things. It's very convenient for small server deploys. When processing a lot of execution traces I ported previous Ruby code to get 40x support boost and 3x memory reduction, while keeping the code virtually the same.
And it's nice to see each version is getting better. The reference could get some love, but it's still ok.
great that aarch64-linux support is now promoted to Tier 1! finally, I can convince my CTO to port some of our services in crystal for those cheap hetzner machines.
They have an interactive mode right now (crystal i), but it's not very comprehensive. You cannot use certain libraries with it etc.
Shouldn't be terribly hard to make it good though. Some time ago, I added a JIT REPL in a few afternoons with Claude, ending up with roughly the same performance as their compiler, and with it working reliably with all the libraries I tested. But since they don't want LLM contributions in Crystal, I just left it as an interesting experiment and started working on my own language instead.
Crazy how easy it is these days, isn't it? The last 20% that matters is gonna be a bit harder though, I assume. Plus with everybody being able to do it means that making yours be interesting is going to be extra difficult.
It is a lot easier, but I've been working on this language project for almost 8 months now. I've spent a lot of time in research papers and thinking about both dev UX and how it works with LLMs. Knocking together a working compiler on LLVM is WAY easier now, but making something nice is still hard. A language is so much more than a compiler and syntax. So to your point, standing out is incredibly hard.
I'm doing this because it interests me and I'm learning, but it does feel quixotic at times.
Cool. I'm about 3-4 months in, this is the current result: https://hanki-lang.org/docs/reference/ -- sorry about the LLM smell. I haven't paid much attention to making the documentation beautiful yet.
Seems like you're slightly more ambitious with the features (linear typing, refinement typing are way beyond what I dream about). I'm focusing more on a small practical application language with ruby-like aesthetics.
I wanted Hanki to be a general-purpose language that could be used with minimal compromises as a scripting language, a configuration language and a reasonably high-performing application / server-side language. I wanted a good REPL, arbitrary precision arithmetics by default, reasonable safety features (effects, strong typing, concurrency via message-passing actors, erlang-like supervising) and excellent readability for human reviewing.
I wanted to include features that force AI agents into a style, so the linter is included as part of the checker and every linter complaint is an error.
The implementation is currently 300K+ lines of Rust, about 60Kloc of Hanki.
I still have about a hundred beads tickets to go through before I'm happy enough about this that I dare to publish it. And seems like every solved task gets 2 follow-ups :)
What a ridiculously negative comment. Obviously ragebait, but I'll bite anyways.
Did you forget that until five minutes ago humans used to read the code? And they needed to understand it? Yes, there was an actual desire for great Ruby-like syntax without the implications of using it, like its performance characteristics and the need for an interpreter.
Yes, it didn't go mainstream. Should we all abandon every project we've ever worked on because they're not "relevant"?
The challenge for Crystal is that we also have TruffleRuby which gets you the elegance and Ruby interop. To me Crystal feels like it's at the same time too different to Ruby to benefit from the similarity and too similar to create its own viable niche.
HN is full of cynical comments like the above. We should be celebrating people trying things and doing things differently... I can almost guarantee you that the person who posted this cynical comment is not working on anything particularly relevant or useful.
My message to the HN community: HN is literally bankrolled by YC. If Crystal doesn't deserve to exist because other languages exist, why exactly should I care about your bullshit uber-for-dogs startup, or whatever not particularly original AI crap you think you're changing the world with these days? Get real. If you want people to be open to your ideas, maybe you ought to make an effort to be open to the ideas of others, and cultivate a climate where discussing different ideas is possible. Don't treat every HN post as an opportunity to opine on how you think the work of other people is flawed.
Crystal never aimed at Ruby interoperability, it's inspired by Ruby's ergonomic syntax.
You should learn this language if you want the nice developer experience, great stdlib, managed memory, native performance. Similar reasons to why you'd learn Go.
Prior to LLMs, Crystal was my language of choice when I needed a distributable binary. It works great for this, and for the kind of packages I was writing - mostly agent-daemons lurking in servers - the networking worked great. The only real alternative was golang, which I've never really liked and has (had?) a more complicated linking story too. The typing worked well too, if used with discipline - if it compiled, I could be pretty confident it would work. I still have systems deployed running Crystal agents, in production, without issue or memory leaks, for years.
LLMs though - I confess they've changed the calculus. Now I no longer have to look at the language, and obey its stupid ideas about error handling, I just use golang for its better library support. But I still have a soft spot for Crystal!
> It just looks like Ruby, but it isn't Ruby and it is a compiled language?
It's close enough that porting things is often trivial (sometimes just slap a few signatures), as long as the code doesn't go crazy with metaprogramming. Yes, it's not the same and stdlib is a bit different. But it's a lot further than "looks like" Ruby.
I used Crystal for a year before moving on to Go, which I value for its faster build times. Bun also keeps improving at fast pace and constantly reduce memory usage which can be useful on budget server.
what does this language excel at in particular? havent heard of it before and didnt find a clear use case / mission statement on the webpage. unless I'm missing where to find it. just curious to learn more.
Crystal is for when you want to write C with Ruby-ish syntax. It's been around for awhile, all the way back to when Ruby was required to get VC funding.
In my opinion, it doesn’t excel at anything beyond being pleasant to read. Maybe if Go hadn’t come along, it would have gained more traction and developed a better concurrency runtime. Very few companies are publicly using it.
Plus, since 00s Ruby = Ruby on Rails, so it didn't appeal to ruby (on rails) developers back then.
It's somewhat similar to Ruby, but it categorically is not Ruby. If you want fast compiled Ruby, TruffleRuby is actually Ruby and relatively compatible with MRI.
I surely don't want a fast compiled Ruby for the tasks I would use crystal for though.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
You're free to like Crystal of course, but for me even for long running tasks (almost my entire desktop, including my wm, terminal, editor are Ruby - I still use Ruby for almost everything; if anything, for more than ever), the Ruby ecosystem beats the steadily diminishing performance gap between MRI and an AOT compiled language to the extent that even going to TruffleRuby where I could keep almost all of my code, is rarely worth it for me.
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it, because in ruby there is so many layers of safety check and failure guard it is really hard to make it faster (number calculation is not everything). with crystal you can manipulate the io stream directly, avoiding a lot of intermediate steps. you can check yourself, they make a full page for it: https://crystal-lang.org/reference/1.22/guides/performance.h...
personally I do not use a single language, I just pick the most suitable language for the job I'm doing, let it be ruby, python, crystal, rust, go or typescript. but surprisingly crystal is the one I use the most everyday.
> no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.
> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
So you do in several Ruby implementations.
> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it
I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.
> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
It's sort of like how Nim was sometimes advertised as similar to Python but fast, even though the similarities were pretty surface level. And by having a low level alloc/free available and a principle of performance (it's the first section in their Guides) Crystal could pretend to be a mythical C or C++ replacement. I also remember likening it to Pony at some point, and/or Red, but when I went through a bunch of them years ago they all kind of blended together as just existing because of dissatisfaction (either with performance issues in Python and Ruby, or with various issues of C and C++) while not wanting to join an existing Rust/Go/whatever faction.
Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it.
I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools.
(And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress).
Personally I don't like the thought of giving up meta programming, and I don't think it's necessary. Spinel is great as a pragmatic way of getting an AOT compiler for a Ruby subset though, but it's not that hard to support meta programming in an AOT compiler.
Though it makes it harder to generate fast code, it's not impossible given that most Ruby meta programming runs early and then doesn't change the program again, and most patterns are recognisable and it seems likely to be (I'm on and off working on my own Ruby AOT compiler) possible to statically verify for most programs that after a given point most code will not change types and so do static type inference to elide most type checks (a type in such a Ruby program will not be a given class, but a given version of a given class or meta class)
That's very funny to see, as I was just watching a presentation Matz gave last year where he was arguing static types won't be needed in the future because LLMs will just figure it all out, so Ruby with its dynamic types was well positioned to be the language of LLMs.
Basically he's saying static typing is needed for AI today because it's "junior level", but for senior level programmers they are more experienced so these types blend into the background; therefore when AI is a senior level in the future, it will also not require static typing to not make mistakes. That writing correct code will be as natural to the LLM as moving your arm is to you.
Everyone wants their favourite language to be well positioned to be the language of LLMs, in reality they will eventually be good enough to generate code directly.
And in what concerns interpreted languages, they will be replaced by agentic runtimes as it is already the case in iPaaS cloud products.
Why would a programming language need or want a "moat"? The whole idea of a "moat" is a feature of certain kinds of business strategies. A programming language's task is to be useful, not somehow preempt or delay or undermine competition through its positioning.
An imitable killer feature isn't a moat, so the terms shouldn't be used interchangeably. And moats are often sort of broadly anti-social, or at best a necessary "cost" of letting the work get done. Network effects and platform advantages are that way, for example.
But I would think that as hackers, when we praise a programming language, we often have in mind virtues that are freely transportable to other programming languages; intrinsic achievements that can be learned from and applied broadly.
I want my programming languages to be lovely, concise, clear, expressive, powerful, fun, insightful, mind-bending, illustrative, flexible, convenient, well-integrated, well-founded, efficient, safe, or helpful. I don't want them to have moats. I don't want to have to say "I'm using this because I (or my industry) started using it years ago and it's sticky"; I want to be so lucky as to get to say "I'm using this because it's good"!
Maybe a minor semantic dispute in the eyes of some, maybe a kind of excessive literalism on my part, maybe a futile resistance to to concept creep, old man yelling at cloud.
Crystal might not be the most popular, but it is very interesting to me, I'm not a Ruby guy, but I was looking into other languages other than Go, Rust, etc that are natively compiled, I've dabbled with Nim, but I really wanted to try something slightly different, and I'm honestly impressed, it needs some slight polish still, maybe better funding might help, but in a different timeline under the right conditions, I genuinely think Crystal could have taken off as a really solid language. It's LLVM based, has green threads (that are insanely lightweight), has C-interop, has a comp-time macro system for AST inspection, code generation and removing boilerplate code.
The web frameworks look interesting too, but I haven't deep dived those just yet. You really get a Rubylike language with native performance which is very interesting.
One thing I wanted out of Nim is slightly more Python-likeness, I want regular OOP, since Crystal takes from Ruby (I believe it was originally written in Ruby, before it became self-hosting) it has sane OOP features I miss when I use Go, Rust or even Nim.
I really feel in a different timeline, Crystal could have been something, I also feel like "Ruby" for some leaves a bad taste, but Ruby is nowhere near as awful as most people think, even though it was never for me, it was still one of the nicest ecosystems I ever worked with long before Go got its package management situation situated.
Edit one more thought: I believe the Windows installer / Windows support for Crystal is a newer addition if I'm not mistaken, so it took a while before it got proper Windows support. Well, I just googled it, it started in 2023... but still, that's fairly recent by my book. I think any programming language should strive to work across the "big three" as soon as possible to increase adoption. Go took off the moment it came out for Windows and was formally released.
> I want regular OOP
Why would you want that? Just to continue the habit? I'd say regular OOP is, after implicit `null`, the biggest mistake in software.
Crystal is nice, but for network programming, Go simply cannot be beaten by a language that has a equally limited type system.
Opinions vary on OOP being a mistake. Most likely people with that opinion are responding to the influence of Java's popularity in the past. Or the confusion with how Javascript was prototype-based but with Java-like syntax and then it got classes for further sugar coating.
I don't think anyone who regularly uses Ruby or Python thinks OOP is a mistake, it's in how you use it and whether one likes the OOP design of the language.
I think that OOP, like Lisp, lost a lot when Smalltalk machines went out of vogue. Ruby is a super cool language but doesn't have the same breadth as a OOP-as-OS system.
I think the Lisps kind of have up on being an interpreter and I feel they lost some of their power because of it.
I kind of see Ruby waning right now, I don't think it offers much with the development of LLMs. I don't think adding typing is the key - but I anticipate there will be a kind of LLM-powered Smalltalk resurgence
You get "OOP-as-OS system" on Apple, Google and Windows platforms, to various levels of approximations.
With Objective-C/Swift, Java/Kotlin, .NET/C++/COM userspaces.
Lol fair point -
But you know what I mean, right? What would be a better way to describe it?
Halfway there I guess, the reason they aren't as you expressed, are the C and C++ layers that exist underneath them, not exposed to the debuggers and such.
Lots of people who use Python regularly, think its a mistake on this, and a lot of other levels. Lots of people use languages, because they feel enforced to do so, and not because of a concious choice.
Isn't Crystal significantly more expressive than Golang?
I get the hesitation from people used to C# or Java where OOP has always been the law of the land, but the rest of us who have used D, C++ or Python... to name a few... OOP is fully optional, and that's how I want OOP in any language, give me multi-paradigm any day of the week.
I would have loved Go more if they had made "lightweight" classes a thing, something feels wrong tying structs and functions, you could have added a wrapper around both to make the code more organized. I guess that's what I like about OOP, organized code. I don't even care about most OOP things, I just want to organize code in a meaningful way.
Kotlin has optional OOP on the JVM. I still use it, but sparingly. Barely ever classes inherit from other classes in my code; I use interfaces, mostly to be able to fake services for testing.
Most of what I write are functions and data objects (records, basically).
One pattern I use is classes with one function, where the constructor takes the functions dependencies, and the function only takes non-dependency parameters.
Functions and data objects are translated into OOP related JVM bytecodes.
Which is why, something like
gets translated into When running javap on the .class file.People really should understand what they talk about avoiding OOP.
OOP is not optional in Python though, unless you are speaking about pre-2.0 Python, before everything became object instances, Smalltalk style.
You can have naked (top-level) functions in Python right? Are they also in instances of classes?
They definitely are,
Functions are an object in Python too, I think that's why they're trying to get at. So you can do some funky things with them if you really want.
You certainly don't have to write OO Python if you don't want to. Objecting to functions being objects like the person you're replying to is, is a flavour of puritanism I find baffling.
> I'd say regular OOP is, after implicit `null`, the biggest mistake in software.
I love this website. It proves that software "industry" is a pop culture after all.
The biggest mistake on the design level seems to be pretty clearly the heap, as it complicates everything else by several orders of magnitude.
It’s sad that we don’t write code anymore, it takes a lot of the joy of stuff like this away.
Agreed. I saw the announcement and had an inkling of the excitement I got the first time I tried Crystal, years ago. I remembered how exciting new languages were to learn, and putz around with.
Then I remembered I could open [coding agent of choice] and it'd nearly oneshot whatever I would want to try in Crystal. I got a little disheartened.
Some languages for me were never meant to be 'used in production', but were a creative & learning space instead.
As someone who also feels that with new languages, I see it a little differently. To me, the limiting factor of all these langauges was (no shade to Crystal not really the case there these days) most of them have terrible or no docs, have terrible onboarding, have rough edges that may or may not be fixed.
So it was a gamble learning something new could just result in a brick wall dead end where you can't fix the thing, you can't get in touch with anyone who knows how (or has time), there's no docs to help you on the way, the code base is a mess and inscrutable, maybe written the a language you don't know -- maybe even the one you're trying to learn! It could be very frustrating at times, to the point I'd just pass over some interesting languages if they weren't polished enough. Which is a shame because I know there's good ideas in there, I just can't invest the time to make sense of them. Seems contradictory, but designers are not always the best communicators.
With LLMs, all this consternation is gone. Can it write the program for you? I guess... but also not really because for many niche languages with interesting features, the LLM won't do so idiomatically, opting instead to implement enough functionality to scaffold a Python-shaped solution, and then it writes that.
The neat ideas are still there, the learning opportunity is still there, the ability to leverage technology in a way the LLM can't is still there. Especially in a creative and learning space!
This reminds me of how, say, the YouTuber Practical Engineering works as an engineer, but then goes and builds physical models of how water moves under hydrostatic pressure out of perspex and sand in his garage for fun.
People who work at the leopard breeding factory being upset that the leopards are being bred to eat their faces..
People love trotting out this phrase. But on analysis of its usage for the above comment, it doesn't make any sense. Who is the leopard, the breeder, and why are they upset in that above comment? They don't sound upset, just sad.
I think the leopard is software-as-automation, the breeder is the tech industry, and the exact semantics of "upset" are less important than schadenfreude at automation (and ensuing poverty) coming for the automator.
Not everyone gets to work at the factory, yet they still get their face eaten.
I mean maybe but... There's nothing forcing you to use Claude or what have you to play around is there? I mean an employer might force you to use it but you don't have to in your free time. That's one way I comfort myself lol
You’re right. But the treat was having a hobby that was also professional development. People in other industries have to take courses, study through dreary textbooks… I got to do something I enjoy and get professional benefit. That’s the shine we’re rapidly losing.
I can't comment on the enjoyment aspect, but I'd argue that writing code still confers professional benefits. It might not be the most economical way to ship code [citation needed] but it's still the best way to understand code, and understanding code will remain professionally relevant for a long time yet.
You can still write code. I do it every day, even for work.
And how do you justify that to your boss?
My boss doesn't care because I hit our deadlines, still ship as fast as my peers, and with a higher quality level.
Which is all that should matter. Nobody should be forced to use LLMs if they can do good work without them.
Fair enough but I can also tell you working with an LLM is basically a free second pair of eyes- even if you are the one writing the code.
Everyone who disagrees is just in pure denial or has never properly used an LLM to interact with regarding a code base.
I don't know. LLMs second pair of eyes frequently make things up and invent crises.
Or maybe lacks the budget, the IT or legal permissions to let AI ingest company code.
Most of my agentic pilled colleagues get lapped by people using llms as a search tool/ conservatively.
A lot of agentic use creates a feeling of psuedo productivity.
Ive only met two devs who genuinely have supercharged their output with them, but they were also superstars before CC.
The agentic only folks are twiddling their thumbs all day messing with their 20 different meta-agentic tools, thinking that extra thing is finally going to give them those superpowers too.
I think being a "super contributor" has little to do with just having access to llms, but people will downvote this.
I used to see the 20 meta agentic tool thumb twiddling last year such as with Ralph loops and plan modes, but since this year with frontier models, they just...do what you tell them, so I've seen that a lot less today. And thus the people use Claude Code are lapping manual coders, at least from what I've seen.
Seeing the kinds of stuff my coworker is spitting out into merge requests on my codebase via Claude Code is sometimes baffling. It's literally spaghetti code. I won't be surprised if the advent of LLMs causes power usage to surge globally, not only because they themselves use a lot of power, but because the code they spew out is horrendously ugly and inefficient. And then the time they take to sort out the spaghetti code they spat out, to add new features on top, takes even longer and uses more power than before. It's gonna be a mess. I don't see how we can keep going down this road without huge investments into nuclear power collectively.
It does not just do what you tell it, the last six hours of my day are a fckn testament to that fact.
"It is in this companies best interest that somebody maintains a low-level understanding of our code base."
[dead]
I've still been known to write a cheeky code or two, even now in the age of LLMs. In fact, it's a little guilty pleasure of mine.
I still do, thankfully not every customer is keen on letting vibe coded applications lose on their systems.
I may be one of the few to use Crystal in anger for long running programs but unfortunately we had to do away with it because of longstanding issues in the runtime where exceptions at the wrong time during I/O bring the runtime to a halt. It's been a few years so I don't have the github issue off the top of my head anymore. I'd like to think that if they could redesign the language again they would not have exceptions and destructors/finalize.
It's a great language for CLIs though. I'm glad to see the team still pressing on.
For those that don't know: Crystal is like a typed Ruby with the performance and concurrency flow of Go.
That actually sounds awesome.
Mainly because normal Ruby is an awesome language to write code, and it is also a language that's tried and lost the spotlight because its performance is really, really low, even when compared only with other interpreted languages.
Ruby caught a second wind when they started putting effort into their JIT, which in our testing made it quite a bit faster than every interpreted language except JS in real world performance.
But then Python got a second wind in performance with better rewrite in Rust integration, but it looks like with the latest DHH keynote, Ruby might also go down that path.
My opinion is that I/O and concurrency ease of use and performance continues to be Ruby's weak point vs other interpreted languages. Which also happens to be Go's very few strong points.
> Crystal is like a typed Ruby with the performance and concurrency flow of Go.
I'm not up to date, but the scheduling engine was far behind Go in terms of parallelism. Crystal was always quite good at concurrency.
But Go is popular because it's so good at parallelism (and relatively safe with a garbage collector).
I know Crystal has been working on this for the last few releases, but I'd be surprised if it's matching Go on parallelism.
Go's runtime is quite the engineering feat.
It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages...
Crystal core dev speaking.
In the previous release (1.21) we enabled Execution Contexts as a parallelism engine. https://crystal-lang.org/2026/07/12/releasing-execution-cont...
It's even more flexible than Go because you can tune different contexts for specific workloads. Go still has more advanced optimizations and overall better thread-safety in libraries. But we're working on that...
Thanks for the response!
My main critique - which I'm sure you're aware of - is that the hardest part of doing this is predicting what your workload is actually going to be like. That's what Go does so well. It can get almost anything right without you needing to hand-tune it.
While I have you - are y'all planning to implement FSMs and thunks (for recursion) at any time in the near future?
This is something Go is unlikely to ever do unless it becomes a Go2 language.
I don't know enough about your runtime to know if it's remotely feasible given the choices you've made.
Go is popular because Docker and Kubernetes made it popular, and it was designed by UNIX idols.
If only it had a few more features from 1970's languages, designed outside Bell Labs, or even those from Limbo that it still doesn't support.
Goroutines are roughly 2kb in memory, and Crystal fibers are roughly 4KB, which is insane in any regard. I think Crystal is really interesting and worth considering, especially if you want something native that has OOP, I really would love to see Crystal used more in general.
That is especially insane, when we consider that "B" means "bytes" while "b" means "bits", and "kb" means 1,000 bits, while "KB" means 1,024 bytes (8,192 bits)!
Happy International Caps Lock Day!!1
KiB means 1,024 bytes, KB is still 1000, if you want to be pedantic.
On other note, who the hell decided kibi, mebi, gibi are good prefix names? that's the reason no one uses them (me too)
No, "KiB" is the IEC abbreviation, while "KB" is the JEDEC abbreviation for the same quantity of 1,024 bytes. "kB" is the SI abbreviation for decimal 1,000 bytes.
https://en.wikipedia.org/wiki/Kilobyte
The metric prefix "kilo" is always lowercase. I don't know how you got a capitalized "K", but that's not how it works.
https://en.wikipedia.org/wiki/Kilo-
The one time I don't double check my capitalization for bytes vs bits... The sad thing is I usually double check as I type them, must have been in the middle of something and not noticed.
Does it outperform Erlang/OTP?
>It can often outperform hand-optimized Rust in worst-case parallel workloads (p99), despite Rust having a number of pretty huge advantages...
I will say this comes with the asterisk that it heavily depends on what your concurrent system/problems looks like!
...but more often than not when dealing with web problems and network IO, the shape of concurrency/parallelism I need looks exactly like Goroutines, and even as someone who uses Rust/tokio daily: the Go runtime is an incredibly engineered system that usually beats Rust in my experience for application dev tasks.
Anyways, I love Crystal's syntax around concurrency! I wish we lived in a world where it had tons of Google engineers optimizing the runtime :)
I always describe Crystal as “Ruby and Go went off to Argentina and had a beautiful baby together. Who has grown up and has so much promise.”
...and a community the size of Elm.
[flagged]
If you mean pre-packaged jobs in that specific language, you're correct. However, if you're a Rubyist needing native performance, it's another tool in your toolbox.
AI killed the language wars. Now you can use whatever you want for whatever you want, wherever you want.
Which means you can have fun trying new languages with every new project :)
Yea but that doesnt help with companies still hiring for language specific roles. Also you gotta be able to check LLM generated code which requires proficiency in the given language.
It's not true though, languages have different level of maturity in different domains.
If you ask Claude create me a Crystal controller for Kubernetes, good luck with that.
It's another tool in the belt. You don't have to be an AH about it
[dead]
I've been happy using Crystal for many things. It's very convenient for small server deploys. When processing a lot of execution traces I ported previous Ruby code to get 40x support boost and 3x memory reduction, while keeping the code virtually the same.
And it's nice to see each version is getting better. The reference could get some love, but it's still ok.
great that aarch64-linux support is now promoted to Tier 1! finally, I can convince my CTO to port some of our services in crystal for those cheap hetzner machines.
That's cool that you have Crystal in production! What are you using it for?
web services for some of our internal tools
I looked closely at Crystal when it first got popular but they removed the REPL which for me made Elixir a better choice.
They have an interactive mode right now (crystal i), but it's not very comprehensive. You cannot use certain libraries with it etc.
Shouldn't be terribly hard to make it good though. Some time ago, I added a JIT REPL in a few afternoons with Claude, ending up with roughly the same performance as their compiler, and with it working reliably with all the libraries I tested. But since they don't want LLM contributions in Crystal, I just left it as an interesting experiment and started working on my own language instead.
I've been doing precisely the same thing https://march-lang.org/docs/playground/
Crazy how easy it is these days, isn't it? The last 20% that matters is gonna be a bit harder though, I assume. Plus with everybody being able to do it means that making yours be interesting is going to be extra difficult.
It is a lot easier, but I've been working on this language project for almost 8 months now. I've spent a lot of time in research papers and thinking about both dev UX and how it works with LLMs. Knocking together a working compiler on LLVM is WAY easier now, but making something nice is still hard. A language is so much more than a compiler and syntax. So to your point, standing out is incredibly hard.
I'm doing this because it interests me and I'm learning, but it does feel quixotic at times.
Cool. I'm about 3-4 months in, this is the current result: https://hanki-lang.org/docs/reference/ -- sorry about the LLM smell. I haven't paid much attention to making the documentation beautiful yet.
Seems like you're slightly more ambitious with the features (linear typing, refinement typing are way beyond what I dream about). I'm focusing more on a small practical application language with ruby-like aesthetics.
I wanted Hanki to be a general-purpose language that could be used with minimal compromises as a scripting language, a configuration language and a reasonably high-performing application / server-side language. I wanted a good REPL, arbitrary precision arithmetics by default, reasonable safety features (effects, strong typing, concurrency via message-passing actors, erlang-like supervising) and excellent readability for human reviewing.
I wanted to include features that force AI agents into a style, so the linter is included as part of the checker and every linter complaint is an error.
The implementation is currently 300K+ lines of Rust, about 60Kloc of Hanki.
I still have about a hundred beads tickets to go through before I'm happy enough about this that I dare to publish it. And seems like every solved task gets 2 follow-ups :)
Is Crystal even relevant at all now?
It isn't interoperable with Ruby and I don't know of any reputable companies using Crystal.
It just looks like Ruby, but it isn't Ruby and it is a compiled language? OK?
I am not sure why I should learn this language?
> I don't know of any reputable companies using Crystal.
Kagi uses Crystal for their search backend [1]. How they feel about that today and whether that was the right call are, of course, separate questions.
[1] Previous thread: https://news.ycombinator.com/item?id=38421149
What a ridiculously negative comment. Obviously ragebait, but I'll bite anyways.
Did you forget that until five minutes ago humans used to read the code? And they needed to understand it? Yes, there was an actual desire for great Ruby-like syntax without the implications of using it, like its performance characteristics and the need for an interpreter.
Yes, it didn't go mainstream. Should we all abandon every project we've ever worked on because they're not "relevant"?
Because it is a nice language to write elegant and performant code in. If that is not enough motivation I guess it is not a language for you.
The challenge for Crystal is that we also have TruffleRuby which gets you the elegance and Ruby interop. To me Crystal feels like it's at the same time too different to Ruby to benefit from the similarity and too similar to create its own viable niche.
HN is full of cynical comments like the above. We should be celebrating people trying things and doing things differently... I can almost guarantee you that the person who posted this cynical comment is not working on anything particularly relevant or useful.
My message to the HN community: HN is literally bankrolled by YC. If Crystal doesn't deserve to exist because other languages exist, why exactly should I care about your bullshit uber-for-dogs startup, or whatever not particularly original AI crap you think you're changing the world with these days? Get real. If you want people to be open to your ideas, maybe you ought to make an effort to be open to the ideas of others, and cultivate a climate where discussing different ideas is possible. Don't treat every HN post as an opportunity to opine on how you think the work of other people is flawed.
Crystal never aimed at Ruby interoperability, it's inspired by Ruby's ergonomic syntax.
You should learn this language if you want the nice developer experience, great stdlib, managed memory, native performance. Similar reasons to why you'd learn Go.
Prior to LLMs, Crystal was my language of choice when I needed a distributable binary. It works great for this, and for the kind of packages I was writing - mostly agent-daemons lurking in servers - the networking worked great. The only real alternative was golang, which I've never really liked and has (had?) a more complicated linking story too. The typing worked well too, if used with discipline - if it compiled, I could be pretty confident it would work. I still have systems deployed running Crystal agents, in production, without issue or memory leaks, for years.
LLMs though - I confess they've changed the calculus. Now I no longer have to look at the language, and obey its stupid ideas about error handling, I just use golang for its better library support. But I still have a soft spot for Crystal!
> It just looks like Ruby, but it isn't Ruby and it is a compiled language?
It's close enough that porting things is often trivial (sometimes just slap a few signatures), as long as the code doesn't go crazy with metaprogramming. Yes, it's not the same and stdlib is a bit different. But it's a lot further than "looks like" Ruby.
There are Minecraft bots written in Crystal, which was the first time I'd heard of it.
I used Crystal for a year before moving on to Go, which I value for its faster build times. Bun also keeps improving at fast pace and constantly reduce memory usage which can be useful on budget server.
what does this language excel at in particular? havent heard of it before and didnt find a clear use case / mission statement on the webpage. unless I'm missing where to find it. just curious to learn more.
Crystal is for when you want to write C with Ruby-ish syntax. It's been around for awhile, all the way back to when Ruby was required to get VC funding.
In my opinion, it doesn’t excel at anything beyond being pleasant to read. Maybe if Go hadn’t come along, it would have gained more traction and developed a better concurrency runtime. Very few companies are publicly using it.
Plus, since 00s Ruby = Ruby on Rails, so it didn't appeal to ruby (on rails) developers back then.
Fast, compiled Ruby. If you like that, there you go.
It's somewhat similar to Ruby, but it categorically is not Ruby. If you want fast compiled Ruby, TruffleRuby is actually Ruby and relatively compatible with MRI.
I surely don't want a fast compiled Ruby for the tasks I would use crystal for though.
Like every one else I also used ruby for almost everything back then, usually some hundred of lines or less for processing stuff. but for tasks that run for several hours using ruby was a frustrating experience. slowness and memory consumption aside, the duck typing system and lazy evaluation of method meaning you can run to typo after hours of running session. sure, you can fix it by write the code more carefully, running smoke tests beforehand and other stuff, but it still a chore, and when you write code all days it makes you sloppier.
having a strong typed compiled language helps it immensely, and with crystal you don't have to sacrifice the easiness of programming. and you can compile it to a portable binary and run it everywhere, no need to reinstall a huge toolchain again. (yeah rust or go can also do that, but not for ruby level expressioness language)
I'm sure crystal is not the ideal language for everything you want to use, and ruby is still helpful for what you use daily. but for some tasks, crystal surely has it own advantages. you can write very capable CLI programs without have to install a single library!
You're free to like Crystal of course, but for me even for long running tasks (almost my entire desktop, including my wm, terminal, editor are Ruby - I still use Ruby for almost everything; if anything, for more than ever), the Ruby ecosystem beats the steadily diminishing performance gap between MRI and an AOT compiled language to the extent that even going to TruffleRuby where I could keep almost all of my code, is rarely worth it for me.
But my main point was that people who do want a fast Ruby should be aware that Crystal isn't a Ruby in any meaningful sense - if you like Crystal for Crystal, by all means use it.
no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it, because in ruby there is so many layers of safety check and failure guard it is really hard to make it faster (number calculation is not everything). with crystal you can manipulate the io stream directly, avoiding a lot of intermediate steps. you can check yourself, they make a full page for it: https://crystal-lang.org/reference/1.22/guides/performance.h...
personally I do not use a single language, I just pick the most suitable language for the job I'm doing, let it be ruby, python, crystal, rust, go or typescript. but surprisingly crystal is the one I use the most everyday.
> no, I meant when your script crashes because some careless typo in the middle of the file, then you will value a compiled language. and even when there is no typo, your program can still crash due to the huge memory consumption.
If your code is poorly enough tested for a typo to cause it to crash, a typo is the least of your concerns.
> also, using crystal you have parallel and concurrency to speed up your task. sure it is not as good as other matured languages, but it still does the job.
So you do in several Ruby implementations.
> when doing with large amount of data, and with IO involved, you will see that your JIT or AOT engine for ruby still can not cut it
I've used Ruby for large scale IO with Ruby for 20 years without problems, even on CPU's far slower, and with Ruby versions far slower than today. If you're doing IO with Ruby and the performance of your language implementation is what is limiting you, rather than spending most of the time in kernel space waiting for system calls to complete, you're doing something wrong.
> when your script crashes because some careless typo in the middle of the file, then you will value a compiled language
How about the crashes for all the other more common reasons? It seems like a concern unrelated to whether a language is strictly AOT-compiled or not, and whether such compilation runs through a static type checker or not, and in any case surely differs a lot among programmers' experience. (Crashes from typos basically rarely if ever happened to me in Python, same with memory constraint crashes. But I've never tried running Python on anything with less than 1 GB/core, if you don't count possibly some educational usage on ancient 90s hardware or a 2004 laptop; the lowest power device was probably a Cubietruck3 from 2013 that still had a generous dual-core ARM cortex-a7 and 2 gigs.)
But I agree with the sentiment, I hate it when programs crash and take out their work in progress or other state. I wish more languages adopted the Common Lisp condition system model, where errors don't crash or unwind anything by default and you can dynamically fix things and retry, or resume, or restart from a specific stack frame. There's even a book about implementing it: https://www.amazon.com/dp/B0DF5YVJKJ (And despite being dynamically typed, Common Lisp is compiled to native machine code, and some implementations like SBCL offer some bare-bones static checks to flag trivial typo or type mismatch issues during compilation, before running the code in question... You can also bolt on a full static type system language on top as a library if you want.)
It's sort of like how Nim was sometimes advertised as similar to Python but fast, even though the similarities were pretty surface level. And by having a low level alloc/free available and a principle of performance (it's the first section in their Guides) Crystal could pretend to be a mythical C or C++ replacement. I also remember likening it to Pony at some point, and/or Red, but when I went through a bunch of them years ago they all kind of blended together as just existing because of dissatisfaction (either with performance issues in Python and Ruby, or with various issues of C and C++) while not wanting to join an existing Rust/Go/whatever faction.
Truffle is very good.
Could also use Matz's Spinel Ruby compiler. That's Ruby with static types using RBS but you have to give up some metaprogramming to get it.
I love the idea that we could get ractors written with Spinel and compiled ahead of time. I also love the idea that I can use Ruby for self contained binary tools.
(And for the sake of avoiding confusion, Crystal is also a great project. I'm really pleased to see them continue making progress).
https://github.com/matz/spinel
Personally I don't like the thought of giving up meta programming, and I don't think it's necessary. Spinel is great as a pragmatic way of getting an AOT compiler for a Ruby subset though, but it's not that hard to support meta programming in an AOT compiler.
Though it makes it harder to generate fast code, it's not impossible given that most Ruby meta programming runs early and then doesn't change the program again, and most patterns are recognisable and it seems likely to be (I'm on and off working on my own Ruby AOT compiler) possible to statically verify for most programs that after a given point most code will not change types and so do static type inference to elide most type checks (a type in such a Ruby program will not be a given class, but a given version of a given class or meta class)
That's very funny to see, as I was just watching a presentation Matz gave last year where he was arguing static types won't be needed in the future because LLMs will just figure it all out, so Ruby with its dynamic types was well positioned to be the language of LLMs.
https://youtu.be/XVaRRryB_cQ?si=CuXiMDdwccH6wOra&t=760
Basically he's saying static typing is needed for AI today because it's "junior level", but for senior level programmers they are more experienced so these types blend into the background; therefore when AI is a senior level in the future, it will also not require static typing to not make mistakes. That writing correct code will be as natural to the LLM as moving your arm is to you.
Everyone wants their favourite language to be well positioned to be the language of LLMs, in reality they will eventually be good enough to generate code directly.
And in what concerns interpreted languages, they will be replaced by agentic runtimes as it is already the case in iPaaS cloud products.
One of the biggest complain about Crystal is its compile time. Unfortunately there isn't an easy fix.
Glad to see the continued progress on adding support for Windows.
[dead]
Fast Ruby with no moat. Next.
Why would a programming language need or want a "moat"? The whole idea of a "moat" is a feature of certain kinds of business strategies. A programming language's task is to be useful, not somehow preempt or delay or undermine competition through its positioning.
I interpreted moat here to mean "killer feature". It seems the best pitch on this thread is "it's like Go but not" or "it's like Ruby but not".
An imitable killer feature isn't a moat, so the terms shouldn't be used interchangeably. And moats are often sort of broadly anti-social, or at best a necessary "cost" of letting the work get done. Network effects and platform advantages are that way, for example.
But I would think that as hackers, when we praise a programming language, we often have in mind virtues that are freely transportable to other programming languages; intrinsic achievements that can be learned from and applied broadly.
I want my programming languages to be lovely, concise, clear, expressive, powerful, fun, insightful, mind-bending, illustrative, flexible, convenient, well-integrated, well-founded, efficient, safe, or helpful. I don't want them to have moats. I don't want to have to say "I'm using this because I (or my industry) started using it years ago and it's sticky"; I want to be so lucky as to get to say "I'm using this because it's good"!
Maybe a minor semantic dispute in the eyes of some, maybe a kind of excessive literalism on my part, maybe a futile resistance to to concept creep, old man yelling at cloud.
But ykwim?