3 ms·

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 adoptio

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?

xelxebar 2y ago
> 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 2y ago
  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.
virgilp 2y ago
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)
- neonsunset 2y ago
  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 2y ago
    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.
    - virgilp 2y ago
      I forgot about Unity. Yes you're absolutely right.
- rscho 2y ago
  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 2y ago
  > 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.
notjack 2y ago
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`.

xelxebar 2y ago

> 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 2y ago
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.

virgilp 2y ago

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)

neonsunset 2y ago
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 2y ago
  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.
  - virgilp 2y ago
    I forgot about Unity. Yes you're absolutely right.
rscho 2y ago
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 2y ago
> 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.

notjack 2y ago

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`.