Dynamo is an efficient dynamic(schemaless) buffer serialization library, instead of having to manually define fixed schemas, you simply pass the values you need serialized, and the library does that.
Code example
local Dynamo = require(path.to.Dynamo)
local encoded = Dynamo.Serialize1({
Health = 100,
Name = "Builder",
Position = Vector3.new(4, 8, 15),
})
local decoded = Dynamo.Deserialize1(encoded)
print(decoded.Name, decoded.Health, decoded.Position)
Benefits of Dynamo
Ultra fast: Outperforms other schemaless libraries and comparable to schematized libraries (benchmark)
Rich types support: 35+ types that can be serialized (primitives, collections, vectors, cframes, instances, etc.)
Easy to use
The documentation provides more details on the library(including the API)
Why not just writing direct buffer logic?
This is just inventing a problem to yourself and then making a middleware “solution”
Just don’t treat tables like they are structs
But then its even more innefficient because there is no schemas and it saves keys aswell rather than relying on a position offset
Buffers are incredibly easy to use manually already
You just have to understand how strings are implemented etc and what is a bit packing
There is no point of using middleware for them and even less point if such middleware is innefficient
i understand that you are against DX and you would rather inline everything instead of having an organized codebase, but there are developers that dont share the same opinion
I am not against developer experience.
I am against the idea that developers should be treated like ordinary users who require an abstraction layer between themselves and the logic they are supposed to be writing.
Developers are the ones writing the logic.
Why should the solution to making development “easier” be introducing more machinery between the developer and the system?
If the developer needs an interface to understand what their own code is doing, then I would rather improve the developer’s understanding than introduce another layer of abstraction.
I would rather write the logic directly.
I would rather understand the actual representation.
I would rather know what the code is actually doing.
I would rather remove unnecessary machinery than build more machinery to make the existing machinery easier to operate.
And “there are developers who don’t share the same opinion” doesn’t really address that.
Of course they don’t.
That does not make the additional machinery necessary.
A preference for abstraction is still a preference.
It does not magically turn the abstraction into an engineering requirement.
Calling direct code “unorganized” also doesn’t make it unorganized. Organization does not require burying straightforward logic underneath layers of indirection.
The developer should not have to fight through an architecture designed to make writing the architecture easier.
The code exists to execute the logic.
Not to provide an elaborate interface for the person writing it.
This is exactly the kind of mindset I am criticizing.
local function pi_ramanujan(terms)
terms = terms or 3
local sum = 0.0
local term = 1.0
for k = 0, terms - 1 do
sum = sum + term * (1103 + 26390 * k)
local n = k + 1
term = term
* (4*k + 1)
* (4*k + 2)
* (4*k + 3)
* (4*k + 4)
/ (n^4 * 396^4)
end
return 9801 / (2 * math.sqrt(2) * sum)
end
local pi = pi_ramanujan(3)
print(string.format("%.15f", pi))
Instead of math.pi!
I feel strongly for developers writing their own code, rather than use bloated middleware for their logic. Not only does this help us understand what happens internally, but it also allows us to optimize the code exactly how we want!
I’ll make sure to:
not make this a shared utility module
paste it in every script I’m using it in
You know what? Functions are abstractions anyway. Let’s just put this inline instead.
Cool, and we all respect that yarik. But ultimately I don’t think anyone cares. If you don’t like a resource, just ignore it, don’t interact with it, don’t shit on it, just leave it alone.
You are effectively doing the exact opposite of optimization and adding bloat for absolutely no reason.
You should either precompute the value and define it as a variable, or use the already integrated constant math.pi .
There is no reason to execute an entire approximation algorithm every time when the value you require is already provided by the standard library.
That is not optimization.
That is reconstructing the wheel and then calling the wheel more efficient because you personally assembled it.
No.
This is precisely the mindset that must be opposed.
If an inefficient practice is introduced, normalized, and then left unchallenged because “nobody cares” , it does not simply disappear.
It becomes normal.
It becomes conventional.
It becomes the recommended approach.
And eventually people stop questioning why it exists in the first place.
This is the same form of wishful thinking that has already poisoned countless projects.
The belief that if we simply ignore unnecessary complexity, it will somehow cease to matter.
It will not.
Bloat does not disappear because we refuse to criticize it.
It becomes entrenched.
It becomes normalized.
It becomes defended by the very people who inherited it.
We have seen this happen before.
The React bloat of 2019 was not defeated by everyone collectively deciding to ignore it.
It was normalized.
It was adopted.
It was allowed to spread.
And now that mindset has solidified its position across the ecosystem.
So no, I will not simply ignore it.
I will criticize it.
I will provide alternatives.
I will explain why those alternatives are better.
And I will continue doing so until the inefficient practice is abandoned.
Because silence is not neutrality when inefficiency is being normalized.
Every unnecessary abstraction that goes unchallenged becomes another precedent.
Every precedent becomes another convention.
Every convention becomes another justification for the next layer of machinery.
And eventually the project is buried underneath a mountain of complexity that nobody remembers asking for. We will not simply stand aside and watch the bloat consolidate its position.
The time for passive observation is over.
The time for optimization is now. We shall fight on the codebases. We shall fight in the code reviews. We shall fight in the Developer Forum. We shall fight wherever unnecessary machinery attempts to establish itself.
We shall not surrender to the doctrine that complexity should be tolerated merely because it has become popular.
We shall not mistake widespread adoption for correctness.
We shall not confuse familiarity with necessity.
And we shall not accept the argument that an inefficient practice should remain unchallenged simply because “nobody cares.”
Even if the bloat has already entrenched itself, that does not make it correct.
It merely means there is more work to do.
Lowk doesn’t even make sense like you thought it would. Obviously a joke but what Yarik is saying here is totally valid. If you really understood his points on optimization you wouldn’t have made this random joke.
I personally feel like if you are trying to optimize something just take the effort to learn it and not hand it off to a random module that has it’s own overhead.
Yarik really does have great points in optimization and coding. Tho Yarik please just use your own voice to talk it out. Walls of text like what you post don’t appeal anyone to read it and lead to reactions like these to your replies or posts.
I have been coding for close to a decade, and I literally code for a living. I’m not making baseless claims. I have experience in and out of Roblox, and even though I’m not a super genius when it comes to making software, it’s still pretty easy to determine that his posts are… bad.
I am usually professional on this forum since it’s a formal place, but his takes are just blatantly wrong and is essentially just sensationalist, reaction-seeking slop. Maybe he fully believes what he says, but 90% of his posts spread bad practice. There are beginners and people trying to learn on this forum. Seeing some supposed “optimization genius” making strong claims about random things is not helpful and leads them on the wrong path.
Now this isn’t an attack on you, I just want people to know.
It’s not
You literally save nothing or maybe even lose using this library
That’s not how you save data efficiently in any way; you always need to use compact representation
Why would you save the key for no reason?
The efficient representation would be U8 while this library, for example, would force [U8][String][U8]
Its extremely innefficient
Please don’t project your lack of knowledge onto me.
extremely ineffecient , Yes, i agree. But I think this library offers flexibility
usually schema based serializers are used if you know the data types upfront, like.
{health: u8, name: string, id: u8}
yeah using dynamo for this thing is bloat, I agree. But the moment you have …unpredictable or highly varied shapes save data with optional fields that differ per player, inventories where item schemas vary by type, replicated event payloads that carry different data depending on context writing and maintaining a hand-tuned positional buffer for every single one of those shapes stops being “efficient” and starts being a full time job tbh.
it loses on speed, size, well yeah cant doubt this. but when u’re in game jam and iteration speed matters?
tbh this library could be improved, not by speed, but by size such as providing columnar , compression, correlation, varints, interning and etc, thats where it shines, on very large complex data, optional fields, u could probably compress it more than JSON + Zstd lvl 22.
