I am on the fence between rust and Odin. Help push me off

General
1

I was introduced to “systems” programming through rust. I was a python script kiddy before and I was tired of not understanding what the hell is going on “under the hood” and solving every problem with “pip install solution”. I tried going straight to C, but the build complexity and FUD about memory safety scared me off. Then I tried rust and it was great. It took me a while to get the hang of move semantics and ownership, but once those clicked I finally felt like I was doing “real” programming. I started writing a relational database server, to touch on as many aspects of low-level cpu programming as I could think of and that has been extremely rewarding.

Since then I have learned a staggering amount about programming and computers. I discovered Odin and finally “learned” C. Now rust is starting to piss me off more and more. The compile tile is very frustrating if you ever have to do a full rebuild, which happens quite often, and even with an incremental build my 10k line project takes about 2-5 seconds to compile on my shitty old laptop. The rust people’s insistence on ooping all their libraries makes using them very annoying. The borrow checker gets increasingly annoying as I become a better programmer and start to want to take more control over my programs memory model. There are whole sections of the language that I avoid like the plague (async, macros, most traits).

Nevertheless, I have not made the switch to Odin. I use very few dependencies, but the ones I do use it’s very convenient to be able to just cargo add them and there are some very good libraries. My project is a database which is inherently about shared data access so rusts threading guarantees are very useful. I really like the move semantics since they make it easier for me to reason about the “location” of data. Rusts portable_simd module, while still a nightly feature, is very good and seems to be able to optimize my simd code to use better aligned loads and not need so many loadu instructions. The way rust gives access to simd intrinsics like the aes-ni is very nice, if a bit verbose. The language is very mature already and the tooling and compiler messages are actually excellent.

Would anyone like to try to convince me to switch to Odin fully? I’ve tremendously enjoyed coding in Odin, I’ve written maybe 2k lines of it, but it’s not without downsides. Help me get off the fence

Tl;dr: Convince me that rust sucks and Odin is the best.

2 Likes
2

For me Rust is the “Java” or “Typescript” for system languages. So if you want something more verbose and C++ like you can go for Rust.

If you want something more succint and more similar to “Go”, you can choose Odin.

The main differences between the two appart from the verbose syntax of Rust compared to Odin. Is that

  1. Rust does not need bindings to C.
  2. Rust have more “libraries” and huge amount of books and learning resources.
  3. Rust can compile to older systems than Odin (Home · rust9x/rust Wiki · GitHub)
  4. Rust have more dependencies and require more configuration tools than Odin.

For me I choose Odin instead of Rust or Zig, because is more simple to understand, at least for me and I liked very much how the packages are organized and the proc declarations. I feel like I could learn Odin in a few hours, instead of months.

Rust feels overly complex to me and if Odin can run in my main systems and projects then Odin is ok for me.

PD: You can always bind rust and C libraries if you need something that is not available for Odin.

3 Likes
3

I think convincing anyone about what language to use is bad.

Pick a language that fits the problem domain and its benefits outweighs the language/ecosystem annoyances. If it is rust, use rust, if not use whatever else…

If I were you, I’d just write more Odin until I figure out where it’s located on the benefit-annoyance scale compared to rust.

edit: typo

12 Likes
4

rust compile times are insanely slow. if you develop by iterating a lot, you will go insane.

5

Rust memory safety approach makes doing some data structures will be hard and challenging without unsafe block.

like circular linked list, graph, quadtree, and octree.

And, it will be hard for games that uses custom allocators, some games might be have own subsystem dedicated to memory management, doing that is nearly impossible without unsafe block in Rust.

6

I have no problem with using unsafe blocks.

1 Like
7

It’s spelt “learnt” not “learned” lol. Like spelt is spelt “spelt”, not “spelled” lol

8

Rust asks you to be specific about what you are doing. It highlights UB at compile time, so when someone denigrates the Rust language all they are saying is they don’t actually understand computer science, they think they do because they get away with UB in other languages but really it’s a skill issue

9

Yep it’s like someone else telling you what you favourite colour is.

11

I guess if you are more the guy that wants something in his hand after the Endeviour and not spend days on talking to the compiler then odin is a good option. It does provide Slices so all the string and array stuff which is a pain in C is really nice. It does have builtin bounds checking which you can enable or disable.

With allocators you can basically get more peace of mind on how memory is managed. It doesn’t prevent you from shooting your self in the foot. But it fixes common Security bugs by doing ZII.
And also with defer you can easily handle scoped memory.

12

I can hate rust without saying that I like UB. Just cause a language fixes a problem that we all hate, doesn’t mean I need to like how it chooses to fix it.

13

Incidentally, you should go to YouTube and look for Tsoding’s farce-video in which he writes “C/Rust” (aka. “Crust” or “C-plus-Rust”)

I’ve been writing Rust since 2017 and, frankly, that single video was the most liberating and refreshing laugh I’ve had in the Rust domain for years, now.

Even the 2024 edition totally fell flat for me. It’s fine. It’s good, actually. But, to me, it absolutely does not address any of my needs in the Rust domain.

In no particularly order and non-exhaustively …

It does not fix macros: Rust is still in a situation where it has not one but TWO variations on macros and BOTH of them are totally abysmal for different reasons. (It also has generics and const for compile-time meta-programming so that’s no less than four meta-programming mechanisms.)

It does not make Cargo a nicer build system; it does NOT fix Cargo “Features” which were still-born, supposed to be additive only, are exhaustively abused as not-additive throughout the entire Crate ecosystem, and are generally just a blight on the landscape that, practically, offers just a clunky way to #define at the very, very best!

It does not fix the problem that any async code is kind of tied to the “runtime”, “executor”, or “reactor” it is expected to be driven with – in fact, it doesn’t even fix the problem that nobody can even agree on which of those terms is correct, let alone what that concept is supposed to be defined to do.

Meanwhile, throughout the Rust ecosystem, there is such an insistence on The One True Rust Way of doing things and that way is async-everything and throwing out every venerable C library in favour of some new Rust crate (and there will be half a dozen competing ones, introducing the paradox of choice, too) that nearly but just doesn’t quite meet your needs. That way involves hacking together macros and trait-piles to effectively write a novel DSL for whatever you’re doing – and that’s why it compiles so slowly.

The video I mentioned showed that Rust can actually just link to C libraries and call them with unsafe and extern and it actually works refreshingly well. The language – itself – isn’t “bad” but the periphery is just painful.

But it is what it is.

I’ve no problem writing Rust, I merely have no interest in doing it for anything other than money: if you pay me appropriately, I’ll write production-grade Rust for you.

Odin presents a chance for liberation. You can just link industry standard C libraries and work with pointers and memory. If you want vectorised, SIMD-powered mathematics, you don’t have to choose between glam and nalgebra, trading off actual niceness against hypothetical potential to do anything at all if you can just wrangle the latter’s template-generic-like API – maths is offered by Odin, the language, itself.

You won’t later learn that your choice (glam, obviously) will be wrong because the “rusty” 2D physics lib you end up with went with the other one – now you have both and you’re casting between them and your compile times are even slower – you can just link Box2D which really sets the benchmark, anyway.

Of course, you could use box2d and C-like maths libs with Rust but my experience says that won’t happen: Rust projects do things the rusty way.

Obsessively. And with stringent linter pedantry!

1 Like
14

I appreciate the advice.

My main barrier to “maining” Odin currently is thread safety. I don’t like rusts closure heavy thread model, but the fact that it can actually statically guarantee no race conditions is very cool. It’s also not that hard to write your own allocator in rust if you don’t mind unsafe code, all the std data structures are implemented with unsafe anyway. You don’t even need to use the allocator api at all if you’re willing to pass around references to the allocator struct.

I also worry that time I end up spending binding C libraries will outweigh time spent wrestling the borrow checker, which is really more helpful than annoying most of the time. While most rust libraries are very annoying, there are many fantastic ones, like… uhm… well I’m sure there must be some…I basically only use a few crypto libs and the nix library for linux specifics…maybe I won’t miss cargo as much as I thought…

I also wonder how much faster odins compile time will be in a decently sized project. I bet it will be faster than rust, but my small odin projects do not compile instantly. It still takes a second or three on my shitty old laptop. Rust is slower, of course, to the point of being unusable for anything graphical if you wanna tweak anything, especially since any graphical program in rust requires hundreds of external dependencies. I guess odin will be much faster in graphical stuff and it has a way better interface to the main graphics libraries like sdl.

Odins generic syntax is also not great and the lack of a Trait system makes implementing your own generic functions for any non-trivial types annoying. Then again, almost every time I am making a generic function for non-trivial types, I am making a mistake.

Probably the biggest reason I really want to switch to Odin is not having to type the full name of an enum every time I need to use it in context. Odin being able to infer the enum type from just a “.subtype” is just so good.

I think I’m talking myself into odin here…

15

Rust can’t do that. No language can. You should read Mara Bos’ book: Rust Atomics & Locks. It is really quite excellent and of far wider relevance than Rust alone.

Sure, you can “guarantee” thread safety if you don’t read or mutate anything outside of exclusively locked Arc<Mutex<...>>, in Rust, and, theoretically, that is “safe” as long as there isn’t a bug in the implementation of those primitives. You can make all your use of atomics sequentially consistent ordering, too, and that is closer to safe.

I do like the multi-threading quality-of-life in the Rust world. It is certainly top-tier stuff. Particularly, I absolutely adore rayon and that kind of thing! (Far more so than effing bl••dy async shenanigans which, apart from I/O-bound stuff, are nearly never good.)

But I don’t see anything missing from Odin’s thread-safety offering or synchronisation primitives or atomics. I’ve used some of them, already: they’re fine if one knows what one’s about.

Honestly, Odin’s compile times aren’t so much faster than Rust’s, today. Rust is fine in dev. – mostly – because full recompiles don’t happen all the time. But I have yet to be faced with a case, from Odin, where, for no reason at all, compile times suddenly jump from 800 ms to 8 seconds and dev. simply becomes infinitely painful until the problem resolves itself – also, on its own, without rhyme nor reason.

Rust does that. Not often, but often enough. (Lately: I think it’s syn. syn is like the DNS of compile times: it is never not syn)

16

Wise.

Unwise.

Every time you make a decision about your fundamental programming stack based on saving typing, you are making a mistake.

Relatively 0,00% of your coding time-cost is spent on typing identifiers.

Now: on the matter of choosing those identifiers – i.e. naming the enums in the first place – I’d say you’d have a point. :wink:

17

More wisdom. I’m glad I could help.

18

It’s not about saving typing. It’s the long lines. Encoding more useful information in fewer characters is often, but certainly not always, good. Pointless repeated verbosity makes reading harder.

I’ve been writing rust for a couple years now and that has never happened to me. I’ve never knowingly used syn, so maybe that is the big problem.

I’ve read Mara’s atomics article. It is indeed great. Rust certainly isn’t “actually” 100%“safe”, especially if you ever use unsafe, which I often do, but all the static analysis makes it much easier to know where you need to be extra careful.

One thing Odin does way better than rust is verbosity. Odin code is so easy to read that you barely need to document it, and you can often understand large blocks of code with a quick glance. Some rust code, especially generic libraey code, is nearly impossible to read, even though I have much more experience with it.

I really appreciate the advice.

19

I have now learned that what I thought was a short article is in fact a short book. I remember reading a chapter from it somewhere and I am delighted to see it expanded. I’ll post the link here to interested parties :Rust Atomics and Locks by Mara Bos

20

It is, indeed, an excellent book. I honestly wish it were longer or I could buy a second volume from Mara Bos, on more advanced topics or, perhaps, on async with her understandable style of writing.

You are not wrong about the verbosity of Rust, when reading it. I honestly think Rust survives as even-slightly-usable purely because of how excellent rust-analyzer and Treesitter are for tackling the verbosity of the actual text. And the doc comments are stellar.