Can Odin be considered as a reliable choice for a bindery ERP (we have a custom one and I would love to make it more modern) + vision systems (will be used in quality assurance of printed sheets of paper coming out at ~10000 sheets per hour, so we need the maximum speed available) what are the opinions of zig expert users? What are the benefits and drawbacks in terms of functionality, safety, and performance compared to other options (zig, rust, vlang) given that I am an only developer, also not a software engineer but a mechatronics engineer grad😂 ?
Ps. if this is not the place to ask say it to me immediately 🙂
#Questions on odin usecases
proud pelican
tiny wave
I have no idea what a ”bindery ERP” is but as long as you choose a natively compiled language one should be able to achieve comparitive performance and safety in any of them. It is going to more depend on your abilities as a programmer to write good code (surprise, surprise).
Also you must consider that none of the languages you listed are fully released or battle tested yet and you will hit compiler bugs more often than something that has been around for much longer.
proud pelican
thanks for the awnser bindery erp is only a translation error is only an erp used in a bindery
hollow glade
I'm afraid "bindery ERP" doesn't really convey anything to me either, so I can't comment on that.
Odin is in the same boat that Zig, language-wise.
The major features Odin has are things like the context system, the focus on making the intuitive thing work and make sense, and the overall focus on simplicity.
Odin has a very small number of implicit conversions.
- Any value to
any - Any pointer to
rawptr - A pointer to an array to
[^]T.
And that's it.
Zig has implicit conversions whenever the conversion is lossless, for context, as well as implicit conversions between pointers-to-arrays and slices, which Odin doesn't have.
In Odin, you use the slicing operator to get a slice: array[:] or array[a:b].
This all helps you to be more aware of what you're actually doing, and what is actually going on.
All Odin structures have a well-defined layout, and structs are compatible with C by default.
Odin doesn't have compile-time execution, but it does have some intrinsics for the stuff you typically need; like intrinsics.constant_utf16_string for Windows stuff, or intrinsics.type_is_integer (etc) + when statements for conditional compilation.
It also has file suffixes, like _windows, _linux, etc, for conditional compilation based on OS, which avoids a lot of the #ifdef nature of that stuff otherwise.
If you need to accomplish something at compile-time that's more drastic, like generating a lookup table, then the typical way to do that is to write a script that generates the values, and then cutnpaste them into an Odin constant declaration.
Or, you can generate Odin source code, and save it into a file that is included during compilation.
There's also an AST parser and printer in the stdlib, as well as the ability to mark declarations with an attribute of your creation, if you want to do something fancy.
It's set up this way because from experience, Bill has found that most of the problems that people use comptime execution (CTE) for are problems that don't really warrant a full-on comptime interpreter, and can be accomplished with much simpler measures, which also saves on compiler complexity.
You typically either want to generate things which you only want to do once in a blue moon (because they don't change very often), or a full-on metaprogramming solution, which Bill thinks can be accomplished more sanely as a standalone build step.
rotund citrus
Bindery ERP = book binding enterprise resource planning system.