Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rhombus Language

rhombus-lang.org

Post reply on HN
Print view View original

151–160 of 161 posts

Re: Rhombus Language

#151

Post by Y_Y »

notjack wrote: post #149
Y_Y wrote: post #126

Earlier quoted context omitted.

I understand what it's doing, I just don't like that it does it.

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

I am only have a passing acquaintance with them I'm afraid, though I have been meaning to get my head around it and write a few hashlangs.

https://docs.racket-lang.org/guide/pattern-macros.html#(part...

I like the explanation there, and I think it gets me closer to my objection. I'm quite happy with the Kleene Star as a concept, but I don't think it corresponds to any usual use of ellipsis, nor is it really a list element on equal footing with the others.

Re: Rhombus Language

#152

Post by hnlmorg »

timkq wrote: post #145
hnlmorg wrote: post #44

Earlier quoted context omitted.

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 maintainabili…

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.

I repeat:

I guess this just goes to show how much personal preference can be a driving force behind our platforms of choice.

Re: Rhombus Language

#153

Post by hnlmorg »

noisy_boy wrote: post #147
shikck200 wrote: post #146

Earlier quoted context omitted.

I have aliases for these kinds of general things (in vim) for most languages i use. Eg. if im inside a typescript file i have a mapping produces if ($obj) { $ } and i tab to enter the next "$" to insert the correct things. The same goes fo Go. I have a mapping for if err != nil { ... } and the cursor is places inside the block. I dont understand why people dont use this kind of thing for the most common programming c…

I would suppose they do and are free to do it - however, liberally having to spread it all over the code hurts readability. I'm sure people can say in response to that after a while you stop noticing or that their favorite IDE can collapse it and so on. It can be excuses all the way down instead of admitting that it is a shortcoming of the language.

You say it hurts readability but most of the time I want the unhappy paths to be visible.

Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly.

All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors that don’t mean much to anyone bar the core maintainer. But I seldom see 3rd party Go software bomb out in quite the same way. And I think that’s in large part because Go doesn’t try to hide errors away as an inconvenience that we shouldn’t be looking at.

So I’ll agree Gos approach is ugly. But sometimes good software does just look ugly. And the way I see it, it’s the quality of the compiled software that matters more than the beauty of the combination of characters that built it.

Re: Rhombus Language

#154

Post by noisy_boy »

hnlmorg wrote: post #153
noisy_boy wrote: post #147

Earlier quoted context omitted.

I would suppose they do and are free to do it - however, liberally having to spread it all over the code hurts readability. I'm sure people can say in response to that after a while you stop noticing or that their favorite IDE can collapse it and so on. It can be excuses all the way down instead of admitting that it is a shortcoming of the language.

You say it hurts readability but most of the time I want the unhappy paths to be visible. Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly. All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors…

I am not questioning it's effectiveness. I have written Go code that is chugging along without issues in Production. My point is ergonomics and effectiveness are not mutually exclusive - hence the example of Rust's ? operator - effective and ergonomic (Rust also has issues with difficult to read lifetime+trait annotations).

The sad part is that people have been talking about this for years but Go team stubbornly refuses to make error handling more ergonomic.

Re: Rhombus Language

#155

Post by bw86 »

mapcars wrote: post #83

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…

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

Re: Rhombus Language

#156

Post by Y_Y »

shawn_w wrote: post #117
Y_Y wrote: post #101

Earlier quoted context omitted.

Typical pattern matching like in Haskell or Prolog wouldn't do this.

It makes perfect sense if you're used to the pattern matching of Scheme and Racket syntax macros.

I guess so, though that might be counterproductive to the goals of Rhombus.

Re: Rhombus Language

#157

Post by zerr »

Bogdanp wrote: post #137
zerr wrote: post #119

Earlier quoted context omitted.

Interesting, how do you distribute/publish those apps?

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 [2]: https://franz.defn.io/ [3]: https://apps.apple.com/us/app/fran…

What UI framework did you use for mobile?

Re: Rhombus Language

#158

Post by Bogdanp »

zerr wrote: post #157
Bogdanp wrote: post #137

Earlier quoted context omitted.

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 [2]: https://franz.defn.io/ [3]: https://apps.apple.com/us/app/fran…

What UI framework did you use for mobile?

It's SwiftUI. See [1] and [2].

[1]: https://github.com/Bogdanp/NoiseBackendExample

[2]: https://github.com/Bogdanp/Noise

Re: Rhombus Language

#160

Post by Kamq »

noisy_boy wrote: post #154
hnlmorg wrote: post #153

Earlier quoted context omitted.

You say it hurts readability but most of the time I want the unhappy paths to be visible. Coding software that works when conditions are met is easy. Coding software that works when things break is hard. So I want error handling to stand out because it forces errors to be handled visibly and properly. All too often I see Python programs drop to a stack trace under normal execution or JavaScript return cryptic errors…

I am not questioning it's effectiveness. I have written Go code that is chugging along without issues in Production. My point is ergonomics and effectiveness are not mutually exclusive - hence the example of Rust's ? operator - effective and ergonomic (Rust also has issues with difficult to read lifetime+trait annotations). The sad part is that people have been talking about this for years but Go team stubbornly refu…

> Rust's ? operator - effective and ergonomic

It is, but it's also subtle, and if you want branches (especially sad-path branches) to be explicit, that's not a good thing.

Post reply on HN