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