redbar0n

What’s unique about Jam is that it tries to keep the ergonomics of a C-like language while enforcing safety without a garbage collector or lifetime annotations. Its main differentiators are owned bindings with automatic drop, no undefined or implicit zero-initialization, no first-class references, and a C-ABI-friendly design that aims to make safe code the default even at FFI boundaries.

Jam is trying to be a safe systems language with C-like immediacy, RAII-style cleanup, no lifetime syntax, no undefined, and low-friction C interop.

It's a bit ironic that the "Good fit" for "When High Level Rust Makes Sense" lists all the use cases where someone would typically _not_ reach for Rust, and "Not a fit" lists all the use cases for when people _would typically_ consider Rust.

I think it's because majority of people using Rust come from C++ where the devx is way worse. But I think what pulls down the devx is the perceived steep learning curve, plus lifetimes.

Crystal's issues list 785 open issues tagged as bugs, as of today, 16. april 2026: https://github.com/crystal-lang/crystal/issues?q=state%3Aope...

Is that normal? Or does someone just really need to close some stale bugs?

Just remember Rob Pike's 1st rule: don't assume where bottlenecks will occur, but verify it.

How could CSS (or any language) have been designed so that these mistakes could have easily been corrected today in any case?

If the mentioned mistakes or similar language design mistakes were made. Because mistakes will always be made.

(Unison lang comes to mind but it’s refactor failsafe seems narrow. How about: Antifragile language design? Self-correcting language?)

x = x + 1

always annoyed me as a syntax for binding, when first learning programming, coming from using = in equational reasoning in mathematics.

x: x + 1

would have been more natural as assignment/binding, imho.

In two concepts: syntactic sugar vs syntactic vinegar.

I did not dismiss speech’s potential to cause hurt feelings, I acknowledged and affirmed it. It is not to be taken lightly. Yet, we need an effective demarcation between speech and physical action, where resorting to physical action is deemed even more severe than words. So which one do you propose?

I am not arguing that terms cannot be used in broader or more expansive or even metaphorical meaning. But I am arguing that the accuracy/essence of the term «violence» ought to be respected. Especially because diluting it (i.e. washing out the border of it) can have such disastrous consequences.

There should be a very clear line between saying something and using physical force. So if you think the term «violence» isn’t a part of defining that line (or even the terms «attack», «aggression», «force», «assault» etc. which you seem willing to use to describe speech), then I am eager to hear what term(s) you propose to uphold that distinction?

The fact that the Wikipedia page on «verbal abuse» has to use «verbal» as a prefix term to the terms «abuse», «violence», «assault» etc. actually underscores the point: If those terms were obviously verbal in nature, then «verbal» wouldn’t have been needed as a prefix to them.

Why would you even need to say «call for violence» if speech were violence in itself?

No one is opposing the fact that speech can be used to call for violence, but that doesn’t make the speech itself violence. The speech part of it is the «call for» or «incitement to» or even «lead to». But we must not mix up cause and effect.

Distinguishing speech from violence is not to dismiss the potential for speech to cause hurt feelings.

From each except the first: - «force, assault» - «action» - «an act of aggression»

Which stands in contrast to «speech».

Though any expression can be used in a broader sense than what it essentially/accurately signifies. Some such examples are of course included in dictionaries, without taking away from the point (what they list first and their general primary agreement: that violence is physical force).

I hope we can agree how dangerous it is to wash out the meaning of the word «violence», and conflate it with «speech». Especially all the while people are being killed (subject to violence) for their speech by other people who justify it by saying that they were responding in kind (eye for an eye) because they deemed their mere words to be actual violence (physical harm) too.

The post could have been called «The Unexpected Woes of Scalability: Few in-betweens».

You should look up the definitions of the word «violence».

You seem to be using violence figuratively (synonymously with ‘injustice’), but ignoring it’s essential and accurate definition.

Both Britannica, Wikipedia, Wiktionary, and Merriam-Webster dictionaries, as well as the etymology of the word agree that «violence» means the use of «physical force».

The flying wrenches remind me of the Gravity gun i Half-Life 2 :D

«Freedom software» is what they should call it.

It would remove the awkward ad-hoc parentheses at every instance.

Besides: The Americans will LOVE it!

Unbundled won over bundled approach, even for RedwoodJS itself (which is now renamed Redwood GraphQL):

"Unbundled Integrations: Over the coming months, we'll progressively unbundle third-party integrations—such as the authentication providers, Storybook, and others. These integrations will then be independently maintained by their original teams or the community, giving you greater flexibility, faster updates, and control over which integrations you adopt and support."

https://web.archive.org/web/20250407165256/https://redwoodjs...

This was clarifying: https://redwoodjs.com/blog/redwoodsdk

See also earlier thread: https://news.ycombinator.com/item?id=43592998

RedwoodJS is going into maintenance mode and is named Redwood GraphQL.

RedwoodSDK is the focus for the team going forward. "It begins as a Vite plugin that unlocks SSR, React Server Components, Server Functions, and realtime features". Which reminds me of the modular approach of Vike.dev (aka. vite-plugin-ssr).

Seems like the unbundled and modular approach won over the opinionated fullstack all-in-one framework approach.

> He turned "same form" into "homoiconic" with the help of Greek/Latin.

«same form» in Greek would rather be «homomorphic». (Or in latin «eademforma», which could maybe be turned to «idoform» in english)

«Homoiconic» could also have been named «monomorphic» (single form), similar to to «polymorphic» (many forms).

«Homoiconic» in Greek means «same-likeness» or «self-similarity» in English.

No, because you can see when a website is using design components that imitate a particular platform (iOS, Android), like Ionic. Because the UI elements wouldn’t naturally look like that on a website if it wasn’t. They would look like standard HTML form elements.

If only there was One.

Yeah, I’ll add that the decision to use RN if you already have a couple of native apps is way harder than if you are starting out with RN. I think the former was why AirBnB reverted their RN foray, and it seems to match your experience.

To target iOS, Android and Web, you’d have to write 3 apps / frontends then, instead of just 1 (with One).

On React Native then One uses Expo, which is used in a lot of top tier and complex apps.

For more about the CTO type decision of going with 3 apps or 1, and the various options from RN, Flutter, Ionic Capacitor, NativeScript (etc.) then you’ll likely find my comprehensive blog post helpful:

https://magnemg.eu/the-different-tech-strategies-for-buildin...

Context:

Tamagui Takeout is a paid fullstack starter kit based on Tamagui (and Drizzle): https://tamagui.dev/takeout

They’ve started a rewrite of Takeout to One (Zero instead of Drizzle, etc.), and are grandfathering in all existing users (also those who start using it before the rewrite is released). More in thread:

https://x.com/tamagui_js/status/1841985327139098649

PS: I’m happy you found use of my blog post about the various tech strategies/choices when making a cross-platform app. :)

Someone asked on the other news item about onestack.dev :

> What is the added value of using it over just Expo?

My answer:

The added value of One is crossplatform compatibility with SSR, and HMR, all using Vite as the single bundler on all platforms.

Nate baked in his vxrn.dev project to get off of Metro and forked Expo Router to do that.

Since Expo Web has a large bundle size, requires NextJS for SSR, Solito for unified filesystem routing, and 2 bundlers: Metro as a bundler on RN plus a separate bundler like Webpack for web.

With One then all of that is integrated. With Zero as the optional data sync engine.

github link on the landing page seems to have been fixed, and leads to that repo now.

The added value is crossplatform compatibility with SSR, and HMR, all using Vite as the single bundler on all platforms.

They baked in their vxrn.dev project to get off of Metro and forked Expo Router to do that.

Since Expo Web has a large bundle size, requires NextJS for SSR, Solito for unified filesystem routing, and 2 bundlers: Metro as a bundler on RN plus a separate bundler like Webpack or whatnot for web.

Btw, here is a good React Native, Capacitor, NativeScript etc. overview:

https://magnemg.eu/the-different-tech-strategies-for-buildin...

If you like Lisp I presume you would prefer Datalog over SQL, as that is used in the Clojure related database Datomic. Datalog is much more elegant and composable than SQL.