Rhombus Language
160 comments
·March 18, 2025pmontra
timkq
TypeScript & Rust don't "look nice to work with" because they force you to write maintainable code that doesn't just stop working because of a random runtime error. In my opinion, Go looks nice to work with but actually is a hidden monster full of footguns.
hnlmorg
Curious to read that because I’ve always had the opposite opinion of the above:
Typescript looks nice to work with but the tool chain is horrible (this isn’t really Typescripts fault though, more a synonym of it having to compile to JS).
Go looks horrible to work with (too simplified syntax) but is actually really nice because the tooling is (mostly) spot on and it’s simplified syntax weirdly helps with maintainability for large projects that have evolved over multiple years.
I guess this just goes to show how much personal preference can be a driving force behind our platforms of choice.
frou_dh
> Typescript looks nice to work with but the tool chain is horrible (this isn’t really Typescripts fault though, more a synonym of it having to compile to JS).
It's not even inherent to TS that the toolchain must be a morass of moving parts and multiple config files, as shown by Deno in contrast to Node.
frontfor
I’m not sure about Go being full of footguns, but for one, a panic in any goroutine forcibly terminates the entire application.
timkq
Simplified syntax helps with maintainability for large projects? You're talking about a "modern" language which had no generics for the better part of its life? The language filled to the brim with "if err != nil"? Go is horrible to work with.
odyssey7
JS isn’t breaking, it’s the layers between there and Typescript.
a2800276
Exactly, Typescript doesn't stop working because of random runtime errors, it stops working because you didn't update the toolchain tangle last Thursday and then some configuration file got out of whack with the tsc defaults ;-)
pjmlp
Typescript is like C++ and Objective-C for C.
Technically, it provides an improved type system that offers the tooling to write safer code.
In practice, plenty of folks just rename the file extension and keep coding as they always did.
alpaca128
Technically TypeScript doesn’t force you to anything other than writing valid JS code. Its design was great for wide adoption but also suffers from the JS part.
kalekold
> Go looks nice to work with but actually is a hidden monster full of footguns.
Really? Me and my team been using it for years with no problems whatsoever.
tgv
While Typescript has the gaping hole that is typing external data. Your code can't enforce that in TS, but in Go you're forced to.
I do admit Go has an easily found foot gun: nil pointers. It's a small one though, in comparison to the original problems with nil pointers. More stubbing your toe than shooting your foot.
freeopinion
Do you feel the same way about English?
gus_massa
From Rhombus you can call all the Racket libraries. I used Racket in a few projects:
* To edit a Moodle backup file, I used Racket to unzip it, find the xml file, parse and filter some of the parts of the xml file and then zip the new version.
* To autoreply some emails, I used IMAP, then scrap some info from my webpage and then SMTP.
There is also a JSON library, but I never used it.
The only problem is that some libraries have no wrappers still, so instead of the expected snake_case name you must use the spear-case with some delimiter to make the parser happy. (Something like |spear-case| or {spear-case}, I should check the docs.) And if that annoys you too much, it's easy to write a macro with a rename transformer so you can use the nice snake_case name, it adds a negligible compilation time and no penalty at run time.
sevensor
I was skeptical when I heard “Python-like Racket syntax,” but this certainly looks like the Python I wish I was writing.
Edit: racket is a nice language, went my thinking, why give it a Python syntax? But I think they’ve answered that.
cies
I found Kotlin a "typed Ruby" (I found Ruby a "sane Perl").
Rust seems pretty nice to work with (good DX) in it's domain: close to the metal programs were every tick counts. The main DX issue with it would be compile times.
Go's awful to me from a DX perspective as it is lacks proper error handling. Compile times are great though.
Maybe OCaml is a good fit for me (and you!). Fast compile times and good error handling.
TypeScript suffers too much from being a JS superset. JS has horrendous DX imho.
agent281
Did you ever see Crystal? It's more or less a typed Ruby. I've heard that you can port some code directly.
cies
YesI have. But I need to get work done so I rather use a language with a larger ecosystem.
Also, I've come to prefer more FP.
dominicrose
Interesting. I learned Ruby a long time ago because a Perl expert told me Ruby was getting good. I like Typescript because it's really easy to read and maintain without breaking anything. But you can't do this: `next x.map { _1 + 3 }.sum if sth`. I guess I should give Kotlin a try then.
pmontra
After 20 years of Ruby I didn't know (or didn't remember) that next can have an argument. I looked it up. Thanks.
BTW, I never liked the _N arguments. Too cryptic. They make me stop and think on details instead of just read the code and concentrate on the important stuff.
x.map {¦n¦ n + 3}.sum
mapcars
You ever heard of Crystal, Red, XL?
dexterlagan
I have used Racket in production for a decade and a half, with great success. Racket belongs to a sort of invasive species equivalent in languages, in the sense that once it has a hold on you, all other languages, old and new, vanish from your mind. The elegance of Scheme married with the power of hygienic macros does a great job at tricking your mind into believing Paul Graham's Hundred-Year Language idea again.
What if Racket and Python had a child? Rhombus represents much, much more to us Racketeers. It may quite possibly be the crown jewel of multi-paradigm meta-programming languages and most importantly, a possible solution to the 's-expression barrier'. Who knows, it might even make a dent in the LISP curse. And we were all hoping for this. We were all waiting for this. And so I applaud the enormous effort involved, and I hope it inspires people to try a different approach to programming, and to language in general. It represents an impressive achievement in terms of elegance, pragmatism/practicality and efficiency in a language built atop a very solid foundation, coming from one of the greatest lineage of programming languages in history.
Like many others, I have been waiting for a killer app, a real showcase of the power of language-oriented programming. I was secretly hoping Rhombus would become a catalyst to the production of something great. While the emergence of LLMs presents challenges, it doesn't have to seal the fate of amazing purely and proudly human innovations like this one. My GitHub account may be filled with Racket code few will ever use, but Rhombus gives me new inspiration.
Sure, the future of programming might involve neural networks programming CPUs and GPUs directly. We're getting there. Yesterday we were programming with cryptic machine language, today we program computers with increasingly natural syntax. Tomorrow we might just tell machines what we need. But that doesn't make what we're doing now any less significant or exciting.
We programmers aren't going anywhere just yet, and many of us will keep writing code because we love it, not just because we have to. And now we have this pinnacle of human ingenuity in the form of a beautiful language, a love letter to the art of programming by humans, for humans. Thank you.
ashton314
Can you tell me more about what you're building with Racket? Warms my heart to hear about/see Racket being used in production.
dexterlagan
The last app I worked on was an advanced Harmony/Flow(ex-shotgrid) bridge which let production staff manage Flow's database, upload assets and work on scenes without having to deal much with Flow's horrible UI. Over the years I have written hundreds of small tools to automate production and assist artists with their workflows in Harmony. Racket's built in UI library and supremely maintainable syntax made it very easy and fun to work with. I published quite a few apps and tools of variable quality at https://github.com/dexterlagan
lygaret
This is racket's [rhombus], which might be an interesting second link here; it's a scheme, underneath, with the full power of Racket libs available.
[`shrubbery`], the replacement for s-exprs, is pretty interesting, expanding s-expr simply with grouping, and then a separate infix-pass on top. I've been playing with using it as the basis for a separate language; it's in an interesting place in the AST space, especially given the forethought put into macros.
[rhombus]: https://docs.racket-lang.org/rhombus/index.html
[shrubbery]: https://docs.racket-lang.org/shrubbery/index.html
breuleux
A while back I had made my own alternative to s-exprs that works with Racket. I have no idea if it still works, but I still think it looks nice, and at a glance I feel it's "purer" than shrubbery: http://breuleux.net/blog/liso.html
HexDecOctBin
I really wish they had kept the old C-like Honu syntax rather that the Python-like Shrubbery. If Rhombus is supposed to be an educational language, copy-pasting and trying out new code is going to be a important part of ecosystem, and indentation based syntax is not ideal for that.
ForTheKidz
I guess. Truth be told I've taught hundreds, bordering on thousands of undergraduate intro courses in python, and students mostly figure it out after they configure tabs and spaces.
spdegabrielle
A valid point.
There is a long history of identifying the problems and risks of copy-pasting, and trying to reduce it. I remember it was a selling point of Java in the early days. For all the efforts it doesn't seem to be going away. (all the boilerplate in Java probably didn't help)
I'd love to see a C-like Rhombus. A Chombus.
obogobo
lol at Chombus
sevensor
I’ve never seen anybody learn much by copy pasting. If you want to learn, you must put fingers to keys.
xigoi
C was my first language and braces confused the shit out of me. I found Python’s syntax much more intuitive when I learned it.
shakna
C-parsing is still built-in [0], so whilst I don't think the standard library has a C-language, it's either really simple, or there'll be a few on the package manager.
rednafi
The syntax looks clean, akin to Python, but with terser record types. This would make a nice config or an embedded language like Lua.
One thing I’d appreciate here is a “Why Rhombus?” page, even if the rationale is simply that it’s fun.
Edit: Turns out there’s a goals[1] page. Rhombus is trying to replace Lisp’s parenthesis-heavy syntax with something cleaner while keeping Racket’s powerful macro support.
Jtsummers
> Why a new language? See Rhombus Goals.
Rhombus Goals links to: https://rhombus-lang.org/goal.html
rednafi
Graaah, totally missed it. Thanks!
hudon
here is the "goal" page: https://rhombus-lang.org/goal.html (with related paper & talk)
rednafi
Thanks. It’s nice to see at least a few in the FP community recognize that Lisp dialects, with their parenthesis-ridden S-expressions, are hard to read and write.
pjmlp
This is nothing new, see
- M-expressions (https://en.wikipedia.org/wiki/M-expression)
- Lisp 2 (https://en.wikipedia.org/wiki/LISP_2)
- Dylan (https://en.wikipedia.org/wiki/Dylan_(programming_language)
- Wolfram (https://en.wikipedia.org/wiki/Wolfram_Language)
- Julia (https://en.wikipedia.org/wiki/Julia_(programming_language))
However the large majority of Lisp folks end up using plain old Common Lisp and Scheme with their S-expressions, because it is easier, it is like telling written languages with symbols are harder than those with latin characters, it is only hard to read and write until one actually learns them.
cardanome
It is hard to have empathy for a problem you don't have.
I have only recently become open to the idea that people might legitimately experience pain using an unfamiliar syntax.
For me, it is a non-issue. From Lisp to C to APL to Forth to Prolog, syntax was never an issue for me. I greatly enjoy learning languages with different approaches to syntax. It has never caused me pain. Only joy. Then again programming languages are my special interest.
It kind of easy to dismiss complains about syntax as intellectual lazyness. After all, learning Lisp-style syntax takes maybe a few hours tops, how can that be a problem? Syntax is just the easiest to criticize but would these people really learn the language if it had curly braces or is it just an excuse?
I don't know. I am the kind of person whose day gets ruined by an app minimally changing its UI so maybe I shouldn't be too judgy about syntax sensitive people.
MathMonkeyMan
I'd say it's more like "we've been teaching Scheme for decades, and we just have to admit that most people don't like S-expressions."
wavemode
From the 2nd example:
class Rect(left, top, right, bottom)
fun rect_like_to_rect(v): match v | Rect(_, _, _, _): v | {"LT": [l, t], "RB": [r, b]}: Rect(l, t, r, b) | {"TL": [t, l], "RB": [b, r]}: Rect(l, t, r, b)
rect_like_to_rect({"TL": [0, 2], "RB": [10, 5]}) // ⇒ Rect(0, 2, 10, 5)
Isn't this wrong? I'd expect to see Rect(2, 0, 5, 10) instead.
It also seems like "RB" was meant to be "BR".
gus_massa
I guess it's a typo and the second line should say "BR". I just send a PR to fix it.
unwind
If you indent each line by, uh, something (I use 4 spaces), HN gives you code formatting:
class Rect(left, top, right, bottom)
fun rect_like_to_rect(v):
match v
| Rect(_, _, _, _): v
| {"LT": [l, t], "RB": [r, b]}: Rect(l, t, r, b)
| {"TL": [t, l], "RB": [b, r]}: Rect(l, t, r, b)
rect_like_to_rect({"TL": [0, 2], "RB": [10, 5]})
// ⇒ Rect(0, 2, 10, 5)
rect_like_to_rect({"LT": [0, 2], "RB": [10, 5]})
// ⇒ Rect(2, 0, 5, 10)
Jtsummers
Two spaces are all you need. There are only two formatting rules on HN so it's easy to remember: * around text adds emphasis emphasis.
Two spaces before each line
creates a code block.mapcars
Looking through the examples, macros and pattern-matching, for me that would be impressive like 10 years ago.
If you want to see really innovative, readable and powerful language check out Red. While the language development seems to be ceased, the ideas (coming from old proprietary Rebol language) of working with code and data go much deeper than just macros: it has built-in DSL (called parse) for making DSLs on the fly and not just pre-runtime code manipulations. https://www.red-lang.org/
And there is XL language which might have even more powerful extensibility features, like adding types or pattern matching or asynchronous processing. Sadly I couldn't compile and try the only implementation it has, only judging by the docs explaining its ideas. https://xlr.sourceforge.io/
ashton314
Looks like Red’s `parse` is just that… a parser. The pattern matching + “shrubbery” notation (see paper; tldr: syntax trees but flatter and more flexible via delayed parsing) are waaaay more general as they allow you to define totally new language grammars inside Rhombus itself. Building Red’s `parse` would be trivial in Rhombus.
Moreover, compile-time macros fill a different role than run-time extensibility: macros can do some ahead-of-time static analysis and the compiler can emit much faster code with no runtime cost.
All I’m trying to say is, if you think Red is more impressive than Rhombus, then you are missing something. :) Rhombus is strictly more expressive than Red. Red might have some nice affordances, but there’s no reason why Rhombus couldn’t have them too.
(And I remember speaking with Matthew Flatt about an eDSL someone was building with the macro system—it was embedded regexes that could communicate with the host language about some of their internal structure; eg report number of capture groups for binding information or something like that. Again, this is all done in user-land, rather than part of the “core” of the language.)
mapcars
Parser is one of the show cases of the fundamental language approach to not have "code" and "data" but only have data, which might occasionally be interpreted using different parsers.
One example I don't think you can reproduce with macros is something like this (I don't have Red at hand)
args: [x y] # these are literal items, like quote in lisps
code: [x * y]
my_func: func args code
print my_func 5 10 # prints 50bw86
> While the language development seems to be ceased
Red 0.6.6 was just released: https://www.red-lang.org/2025/03/066-memory-management-impro...
coolio1232
This actually looks good. It's like a less-obtuse Haskell. At a glance the features seem to be just the right mix of functional programming paradigms and standard imperative programming.
steve_adams_86
The other day I saw someone describe writing Haskell as “programming with your elbows while listening to math rock”, which is awesome. I can see the need for a less-obtuse Haskell
bmitc
Less obtuse Haskells have existed for years: Standard ML, OCaml, and F#.
ksp-atlas
It also involves sending values forwards and backwards in time using Tardises occasionally
bmitc
What is the relation to Haskell?
The language is basically Racket, which is a Scheme at its core. There's very little in common with a language like Haskell.
coolio1232
Syntax-wise it looks a lot like Haskell to me, especially the pattern-matching, the variable declarations (with `::`), as well as the indent-based blocks.
cies
It's usually called ML-syntax. SML, OCaml, Elm, PureScript, and many more have used this.
galaxyLogic
So it's not PURE!
otabdeveloper4
Yeah, it doesn't have the one thing that makes Haskell Haskell.
cies
> What is the relation to Haskell?
I could only think of is they are both being a "typed lambda calculus" language with an ML-syntax.
true_blue
I think it's clever how the logo is a different shape from Racket's to fit the name of the language, but they kept the same colors and kept the lambda in it.
Y_Y
I've been cautiously optimistic about Rhombus since the initial "Racket 2" controversy. I'd have preferred they went with something more like Wisp or Wraith, but it could be a lot worse.
I am somewhat troubled by tricks that are "too magic", like this example from front page:
class Posn(x, y)
fun flip_all([Posn(x, y), ...]):
[Posn(y, x), ...]
flip_all([Posn(1, 2), Posn(3, 4)])
// ⇒ [Posn(2, 1), Posn(4, 3)]
(Then again being too magic is working well for Python, e.g. that a<b<c thing)
disconcision
a big part of the racket project has been about establishing robust tools for transforming syntax. focusing on this use case has resulted in a much more generalized notion of pattern matching and template reconstruction than is typical. these kind of pattern/template combinators, as developed for racket/match and syntax-parse, might appear special-casey at first glance but from use i can attest that they are clean and compositional... they have the appearance of something you'd write informally on a whiteboard, but they really do just work, and the rules are fairly simple and easy to internalize.
Here, the ... pattern combinator means 'match a list (segment) consisting of the pattern Posn(x,y) zero or more times, and because (free variables) x and y are under one ... combinator, bind x to a list of xs and y to a list of ys'. The template combinator ... means 'produce a list (segment) consisting of the template Posn(x, y) zero or more times, returning an error unless x and y are bound to lists. The reason I specified 'under one combinator' for the pattern part is that ellipses can be nested, resulting in contained pattern variables being bound to lists of lists etc. anyway, point is, this is all just compositional rules, with no spooky communication needed between pattern and template. I won't objectively argue that it's not magic, but it's at least not more magic than regexps.
Y_Y
I understand what it's doing, I just don't like that it does it.
notjack
Are you familiar with `syntax-rules` based macros? Because this is roughly the same logic here.
It's trying to unify how macros produce syntax objects via `syntax-rules`-style pattern matching and ellipses with how regular pattern matching on values works, so there aren't two separate pattern languages (one for macros and one for everything else).
soegaard
It's not magic. It's pattern matching.
The `[Posn(x, y), ...]` is a pattern that matches a list of positions. The `[Posn(y, x), ...]` is a template that produces a list of positions.
arunix
That syntax suggests the first pair will be flipped, and the rest will just be as they were, i.e. more like flip_first
soegaard
When the pattern `[Posn(x, y), ...]` matches a list of positions, since `Posn(x, y)` is followed by `...` the `x` is bound to a sequence of first coordinates and `y` is bound to a sequence of second coordinates.
In the template the `Posn(y, x)` is followed by `...` so the same number of positions is produced as the common length of x and y.
norman784
Care you to elaborate on Racket 2 controversy? I don't follow the language, but I'm aware of it, so I didn't learn about the controversy.
Tewboo
Interesting to see a new language like Rhombus popping up. Always curious to see what innovative features it brings to the table.
orthoxerox
I am going to play the devil's advocate. What problem does Rhombus solve? An approachable syntax is a necessary, but not sufficient requirement for mass adoption.
According to the goals page, its other major feature is an extensible syntax. Why should I prefer it over, say, Scala? Scala has syntax macros, it runs on the JVM and can access Java's massive library of libraries, it has been used to implement large and complex projects like Spark and Lichess, what's that niche in which Rhombus can defeat Scala or Rust or Elixir?
virgilp
This is not playing devil's advocate - this is a _VERY_ legitimate question. I'll go further and say that without a "killer app" (and/or strong corporate backer), a language doesn't typically take off nowadays, regardless how good it is ([edit] but to the point of another commenter - I do agree that "exploration" is a good enough reason; one doesn't need to write languages only with the goal of making them popular).
- Scala: only really took off with Spark (had Akka before but wasn't really that popular)
- Python: might've died if not for numpy/pandas/ ML
- Ruby: Rails
- Typescript: V8/Node.js / javascript on the server-side
- Go: Google, Kubernetes (and even so it's questionable how popular it _really_ is)
- Swift: Apple, iOS apps (to a somewhat similar extent: Kotlin, for Android development).
- C#: I can't really name the "killer app", but... Microsoft. (to be fair the "killer app" itself might be the whole MS ecosystem integration)
There are a lot of decent languages (Clojure, D) that never got popular, despite their merits. Even Kotlin mentioned above is arguably a much better choice than Java on the server side. But it's not used that much on the server, even though it actually has the answer to "what problem does it solve" (easy way to write async code in JVM, which is not a small thing)
rscho
I don't think they care so much as you think about 'takeoff'. It's mostly a research project in programming pedagogy. They're trying to make lisp features more accessible to students in universities. A takeoff would sure be appreciated, but the immediate goal is not a takeover of the industry.
The author (M Flatt) is an incredibly gifted and productive programmer, btw.
norman784
> Typescript: V8/Node.js / javascript on the server-side
I would dare to say that more people use Typescript in frontend than in backend projects, so basically Typescript killer "app" is the browser, because you are forced to use Javascript, but JS does not scale that good for mid, big projects.
virgilp
I agree; but I _think_ chronologically Node & server-side-JS came first? The driver is the same though: "larger codebases, running on top of Javascript" - and indeed nowadays probably the browsers are the things that run the larger codebases.
neonsunset
C#: ASP.NET Core (a slimmer, faster Spring Boot), EF Core (better Prism, jOOQ, etc.), very flexible build targets (JVM-style, self-contained JIT and AOT binaries), easy integration with F#, good pattern matching, access to low-level features only rivaled by Swift (although Swift has its own set of issues). Far better performance ceiling than all the languages here on the list.
orthoxerox
You forgot async/await. But all that wasn't what propelled C# to popularity, and I say that as someone who's been writing it since 2002. It was an army of VB6 and Delphi line-of-business programmers migrating to the new stack and enterprises running Windows.
The next big killer application was Unity, which didn't even use Microsoft .NET.
Everything else is just marginal advantage: if you're a JVM shop, the existing experience of your programmers is more valuable than the speed of modern .NET or better pattern matching. But if you want to switch to making games, then switching to C# and/or C++ starts making sense.
speed_spread
I disagree strongly with Kotlin being a better choice than Java. Kotlin solves problems Java had 14 years ago while bringing along totally unnecessary syntax complexity. Moreover it is slow to compile and is essentially a proprietary language.
xelxebar
> Many newer languages include a macro system to enable extensibility, but few would argue that the new batch of macro systems have achieved the expressiveness and fluidity of macros as they exist within the Lisp tradition, which includes Racket.
It sounds like the authors see Lisp-style macros as uniquely powerful and are exploring how to bring similar meta-programming power to languages with syntax other than just s-expressions.
> what's that niche in which Rhombus can defeat Scala or Rust or Elixir
Good question. My read is that Rhombus isn't motivated by solving some "real world" problem and is instead an exploration in language design.
fc417fc802
Add to this integration with an entire family of languages. Racket permits you to jump between different syntaxes. The closest thing that immediately comes to mind is writing inline C in Chicken or Gambit Scheme and that's far clunkier. Hy (embeds in python) also comes to mind but Python often seems rather slow.
notjack
Rhombus massively advances the state of the art for macro systems in infix languages. Macros in Scala, Rust, and Elixer are extremely limited compared to Rhombus macros. The enforestation-based approach that Rhombus uses and the underlying Racket macro machinery means that things like Rhombus's class system, pattern matching system, annotation system, infix operator system, etc. are all implementable as macros. That's definitely not the case in Scala, Rust, or Elixir. Imagine if the base Rust language included only a macro system and `unsafe` code and the borrow checker could be implemented as a regular library in `std`.
zerr
Does anyone use Racket outside academia? Is it production ready (or friendly)? Especially Typed Racket.
spdegabrielle
Racket has been used outside academia for years. Racket has been production ready for years.
Here is a recent example https://blog.cloudflare.com/topaz-policy-engine-design/
evdubs
Yes. I've been using it for 8 years. It has been production ready that whole time. I am not a user of Typed/Racket; the contracts system works well.
https://github.com/evdubs?tab=repositories&q=&type=&language...
Bogdanp
I’ve used it for all kinds of production stuff over the years, from web to desktop and mobile apps.
zerr
Interesting, how do you distribute/publish those apps?
Bogdanp
Web: create an executable distribution[1] and ship it to a server.
Windows/Linux/macOS: same as web, using cross-compilation[5]. Additionally for macOS, embedded in a Swift app and distributed as a .dmg[2] and on the Mac App Store[3]
iOS: embedded in a Swift app and distributed on the App Store[4].
[1]: https://docs.racket-lang.org/raco/exe-dist.html
[3]: https://apps.apple.com/us/app/franz-apache-kafka-client/id64...
[4]: https://apps.apple.com/us/app/podcatcher-podcast-player/id67...
MathMonkeyMan
I've used it for some command line [tools][1]. Nothing running on production. Mostly programs that process programs or markup. I haven't used Typed Racket.
[1]: https://github.com/dgoffredo?tab=repositories&q=&type=&langu...
velcrovan
I have one day of college under my belt and use Racket for all my personal projects, as well as in a few areas related to ERP systems professionally. I have found no compelling reason to use Typed Racket so far.
[edit to clarify: I am not in college. I’m in my forties and have 25 years experience as an IT/programming/accounting generalist.]
procaryote
I tried, it's a really nice language with almost no libraries so you end up reinventing the world every new thing you do. It's not really practical compared to arguably worse languages with better ecosystems
velcrovan
It has a lot of libraries. Can you give some examples of the gaps you are talking about?
The examples on the home page are a nice way to quickly show the features of a language. I'll check the documentation to see how to work with files, make HTTP calls, parse JSON.
It's the first time in more than 10 years that I actually feel like trying a new language. The last time was Elixir. Since then I had to use Lua (hobby project) and Python (work) but I don't enjoy them much. I would have skipped them if I hadn't have to use them. Before Elixir I enjoyed Ruby, before that it's been Perl 5 in the 90s. Everything else I used in that period and before was because I had to (C, Java, PHP, JavaScript/Node) and I skipped many other mainstream languages because they didn't look nice to work with (Go, Rust, TypeScript.) I still have to see what's writing and running a Rhombus programs looks like so I might discover that it's not so nice after all. I'm hopeful.