React Lua
github.com
github.com
Roblox's Luau: https://luau-lang.org/
> Luau is a fast, small, safe, gradually typed embeddable scripting language derived from Lua.
> Around 2006, Roblox started using Lua 5.1 as a scripting language for games. Over the years the runtime had to be tweaked to provide a safe, secure sandboxed environment; we gradually started accumulating small library changes and tweaks.
I'd love to have type annotations in Lua.
But this doesn't compile to Lua, right?
I found Teal, which seems to Lua what TypeScript is to JavaScript
I've used it successfully with Love2d projects (albeit with some quirks)
What are the quirks?
All of these, too: https://typescripttolua.github.io/docs/caveats
1: https://github.com/teal-language/teal-types/tree/master/type... 2: https://github.com/MikuAuahDark/love2d-tl
There are a great many implementations of Lua at this point, I'm aware of at least six. But Roblox upstreaming their semantic changes was never an option.
Just because there's a closed development model doesn't automatically imply the devs team lives and breathes "not-invented-here"-ism and are no interested in discussing improvements that make a difference to actual people using Lua in (extremely) large real world products.
> Lua is not "open developed". The development is done exclusively by the Lua team, at PUC-Rio. So, we do not need a SVN repository. Currently, we keep Lua with the good old RCS.
- Roberto Ierusalimschy
If I had this as my message, and someone asked to ship changes, I would be more than mad.
just take the L dude.
really, dude?
Which would be the whole reason I would put such a statement there, in the first place.
What are you even trying to argue with now? That I'm not allowed to get angry in the hypothetical that I made up? Do you see why it's fruitless to continue arguing?
Or are you going to pick out some prior wording and analyse it further, because you just can't comprehend that corporations don't have best interests at heart, and some people prefer to just put things up and not deal with other people's improvements
PUC-Rio Lua uses C (with a tiny bit of C++ for stack unwinding on errors if folks don't want to use `longjmp()`,) Luau is strictly C++. Luau rewrites quite a lot of the core structures, and they aren't compatible. Further, Luau is a fork of PUC-Rio Lua _5.1_ (the current is 5.4 I think?) and intentionally picks and chooses features from later Lua versions. Even things like improvements to the core VM interpreter loop wouldn't be upstreamable, because Lua 5.2+ has a fundamentally different model to allow for yielding in metamethods. PUC-Rio would not accept changes other than fixes for critical bugs in Lua 5.1.
I like both PUC-Rio Lua and Luau, but a hard fork with no upstreaming was the only option here. The architectural differences of the VMs are so large now that it would amount to PUC-Rio adopting Luau. Supposing there is some tiny bit that PUC-Rio is interested in, they can cherry-pick it out of Luau, since they use the same license.
The more options like this, the better. Especially for existing ecosystems.
More specifically, I know that Roblox uses lua(u) but I assumed this was all for scripting. React is a tool for building UI.
How do you use React inside Roblox? You can build UI? I'm trying to wrap my head around my clearly mistaken assumption that what was possible in Roblox was writing lua-ish scripts that handle events in Roblox and then alter the game flow. That's very different from a full UI element that manages state and presentation, which is why React was so exciting (ten years ago).
Still though, the boilerplate required to do it doesn't make it seem like React is particularly good at it, even though it's technically capable.
I use this pattern commonly. You put a state-update callback into the context.
It's my favorite go-to when I don't want to bother writing all that Redux boilerplate (state description plus accessors plus reducers feels... Half-baked).
- https://redux.js.org/tutorials/essentials/part-2-app-structu...
Context is not an "improvement" over Redux, because they are different tools with different purposes. (This is the primary misunderstanding people have when they try to compare Context and Redux.)
Context is a Dependency Injection tool for a single value, used to avoid prop drilling.
Redux is a tool for predictable global state management, with the state stored outside React.
Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state you are managing, or whatever other value you're passing through it (event emitter, etc).
I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this:
- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
So redux is for "managing and updating" shared state. And context is for "sharing values". All this seems to suggest that react actually isn't that good at shared state, at least when it can change.
React is based on the core concepts of encapsulated components, with the ability to manage state on a per-component-instance basis, and for parent components to pass _any_ values they want to their children as props, forming a "one-way data flow" approach.
This is _good_, because it both enables predictable behavior and React's overall rendering model.
It's _limiting_, because it means that React's own state management is inherently tree-shaped. If two widely separated components need to access the same data, you have to hoist the ownership of that state up to the nearest common ancestor, which could easily be the root `<App>` component. To put it another way, not all state is inherently tree-shaped, so there's often a mismatch.
Context is essentially "props at a distance". Put a value in a `<MyContext.Provider>` component somewhere in your tree, then any deeply nested component can read it via `useContext(MyContext)` without having to explicitly pass the value as a prop through however many intervening levels of components.
This simplifies making values accessible to that subtree, but doesn't solve the tree-vs-nontree-shaped state management question.
You _can_ build an entire app out of nothing but React component state. Plenty of folks have done it, but it's limited in what tools you have available and how you can structure things.
That's a large part of why there have been so many different state management libraries created for React, to provide alternative approaches that don't have the tree-shaped issue.
The declarative part is that the UI is recomputed from the state sorta-ex-novo at each update
I expect that in fifty years all programming will look declarative, either like HTML (which is sorta 'natively declarative') or more like React (which shims it into an imperative language).
https://www.tiktok.com/@user2571420815968/video/720501112959...
But both the JavaScript and Lua versions of React are full of high fructose corn syrup, anyway.
https://www.youtube.com/watch?v=H_zsZMn5Efk
I'd prefer a low-calorie high-performance port of Svelte to Lua.
React is a tool for writing 3D scenes that can handle state updates: https://github.com/pmndrs/react-three-fiber
React is a tool for writing music that can handle state updates: https://github.com/FormidableLabs/react-music
React is a tool for writing infrastructure-as-code templates that… um… could with some additional work handle state updates: https://www.linkedin.com/pulse/aws-terraform-generator-using...
[1]: https://devforum.roblox.com/t/how-to-react-roblox/2964543
Roblox is a game engine, like unity or unreal or godot, that produces games which run within their proprietary platform. But you still have to code the games from an empty starting point.
And that one supports writing pretty much actual React tsx but with Roblox primitives.
One of my clients asked me to make a Roblox plugin, it was my first time, and I was very pleasantly surprised with this workflow. There are also tools to enable really high iteration speed. It felt nicer than Unity at some moments. I didn't really need to write or know any Lua at all!
> When possible, upstream flowtype and definitely-typed types have been translated into Luau type annotations.
> This repository is a fork of roblox/react-lua with the intention of being the Roblox and global Lua community go-to for React in Lua. Roblox's repository is a read-only mirror of their internal project, and as such cannot be contributed to by the community.
https://en.m.wikipedia.org/wiki/Real_Programmers_Don't_Use_P...
Which is itself a reference to:
https://en.m.wikipedia.org/wiki/Real_Men_Don%27t_Eat_Quiche
It’s all tongue-in-cheek references to stereotypes around what would now be called toxic masculinity/gatekeeping.
Of the Fortran programmers (real, manly programmers in this story) it says:
> Besides, the determined Real Programmer can write FORTRAN programs in any language.
In this vein there’s also the story of Mel the Programmer, a “Real Programmer” who would never stoop so low as to use so abstract a programming language as FORTRAN. Funny how perspectives change over time.
The reason you experience it as terrible is because it's today's visual basic: it's so easy to start with that everyone does, without needing to understand programming or specifically how React works. You can just throw shit together and it'll work. It's empowered an entire generation of web and app makers, with the cost being "and they're not good at that, through no fault of their own, but they are just good enough to be dangerous".