One thing that I'm surprised you didn't mention and that is a big deal to me: Odin is production ready, stable and is not planning on having major changes to the core language in the near future afaik. With Zig, the story is different and will be different for some years into the future. Now, I like Zig, I love the goals and ambition and I will certainly keep my eye on it, but if I work on something real, I also want some stability in my programming language of choice. Maybe I'm just misjudging Odin's maturity? EDIT: Also, thank you for the video, I like it! :)
I think there's a bit of column A and a bit of column B here. Odin, the language, doesn't have a lot on its roadmap and is very stable. At the same time we just had a period of maybe half a week or so where projects stalled because if you had LLVM17 installed and compiled with `o:speed` you'd get a compiler crash. There are disruptive things that happen still. On top of that it's generally advisable to stay at least abreast of what is going on in `master` and you'll likely be able to find places to make better or fix in the standard library still.
@@Z3r0XoL hm? odin is used in a few industry leader software, there's no better assurance than that that it will stay afloat. also it's an open source project. both projects have a stable future ahead of them. I don't know why you have to make it a either 1 or the other deal, it's not a zero sum game, both languages can exist and be valuable to the people interested in using them
Note that the video does not touch on things that are perhaps a bit more situational: - It doesn't cover array programming or swizzling which Odin has. This is covered in my Odin videos to a minor extent. - It doesn't cover the `vendor` libraries that Odin has, because they are highly situational. Odin is just generally significantly nicer for gamedev in general, so for that context this would come into play. - It doesn't cover `@cImport` which Zig has, mostly because while I think it's very good, it always required a lot of fiddling and writing wrappers for me anyway. This may have changed since I last checked. - It doesn't cover `async` in Zig because I'm not even sure I would ever want to use it in its final form and I don't know that it's even in a shippable state yet.
Regarding comp-time- in odin you can do a metaprogramming approach. I made a pair of videos showing how to do this. The most straightforward way is using custom attributes which you can pick up with the core/front-end (iirc) parser and then do operations on it. I had a use case where I populated a map from a table, the generated file then is used in the main project as if hand typed. It's a bit more work than zigs builtin approach, but it's not at all hard because we have the parser as a library.
As I alluded to, this is kind of a version of what I've done with code generation before and honestly, this is basically what I'd do in general if this problem came up again. I'm not sure that I believe in most metaprogramming solutions and stuff anymore anyway; they're usually just more code I didn't write that I now have to debug through compilation phases, etc., whereas with a separate solution I can be completely 100% sure what's going on.
@@mccGoNZooo i agree - i was only providing an argument that the loss of comp-time in odin is not so much of a loss as one would first think, the capability is there and easily accessible, but you do have to do something, putting a little bit of friction in place to perhaps drive you towards a better solution.
great breakdown. it tracks with my own experience as well. i tend to like zig slightly more than odin, but i wouldn't be unhappy with using either. i think people sleep on odin's swizzling though. i've been doing some game stuff and swizzling makes some things so much more expressive and understandable at a glance. thanks for the video.
Swizzling, array programming and the extensive vendor collection of libraries are really, really good for gamedev or other GPU programming-related things, yeah. I do think it's situational, though, and the reason I didn't mention these things that are *clearly* better in Odin is because that basically only pays off when you're doing certain things. I wanted to err on the side of caution and be as fair as possible in the general case.
I definitely don't find Zig a weekend language. It must be the things I choose to code to learn it with but I always run into frustrations. But I still like it. My only frustration with Odin was trying to install it without brew, but I finally got there today (my MacOS SDK is in a different location than Odin expects) and I'm finding it much quicker to pick up than Zig. Surprisingly the project I'm trying this time was really easy to get working in Rust!
I'm not sure what the things you've chosen to do are, but I don't usually find that learning a language has much to do with what you're choosing to do with it. I do think it's important to take things on that are managable for your skill level and it can be useful to spend your time doing things that aren't too far outside of your comfort zone in the beginning, i.e. probably very managable projects for a week or two. With that mindset I think Zig is actually very easy to learn and certainly in 2019 it was doable in a weekend. I certainly felt very productive very fast. Granted, I wouldn't touch their `async` stuff that they're trying to do with a 10 foot pole... So, you know, things change... Very happy to hear that Odin is making sense to you. I think, to be fair, that previous exposure to Zig helps a lot with learning Odin because there's a lot that's shared between them. Edit: I guess I should ask what "easy to get working" means, because I'm not sure I understand what you mean from context.
@@mccGoNZooo Well in my case I'm an old programmer used to low-level and high-level languages but stopped as a job ages ago and now just do recreational programming on things I find interesting. I'm always finding bugs and problems my professional friends never hit. Usually I try out a new language by reimplementing something I've already got working in one or more other languages. So not outside my general skill level but often outside my skill level in a new language. First go at Zig I hit a problem where I wanted to check for existence of a group of files with patterned names but in Zig filenames and paths are always comptime and string formatting didn't work with unused parameters. Nobody had wanted to do that before but it was doable in every other language. Zig has completely removed the old async system for a while now. Andrew recently postponed implementing a new system. I spoke a bit too soon with Odin. When I got to gigantic inputs the OS was killing my process due to leaking memory reading from stdin, presumably because I don't understand context and allocators yet. In Zig allocators are always explicit so you always know when you'll have to free something.
Anything that returns values that outlive the scope of your current function is going to likely be heap allocated. The main exception would be values that are made up of values you've used as input, i.e. sub-strings of strings you passed in, etc.; they'll have the same lifetime as the values they're derived from. This really only applies to anything involving pointers; normal values can be interpreted from just data and will outlive anything because they're just values: Numbers, booleans, characters, arrays of all of those (but not slices; those are pointers with a length attached). Things to look for that are Odin-specific that'll tell you something allocates: - It's a function that takes an allocator, usually as an optional argument. The default value of that parameter is commonly `context.allocator` - It works on a structure that stores a `mem.Allocator` - It produces a value that involves a pointer but there seems to be no backing value (a passed-in buffer/string, etc.); this backing value and/or the value itself is probably heap allocated With all of this said I'd recommend just using a backing buffer that you read file/handle contents into via functions like this: github.com/odin-lang/Odin/blob/master/core/os/os.odin#L77 `read_full` will read into the buffer you specify and you can then work on the contents after the call is done. You'll get the amount of bytes it actually read as a return value so you can slice into your backing buffer: ``` backing_buffer: [4096]byte bytes_read, read_error := os.read_full(os.stdin, backing_buffer[:]) content := backing_buffer[:bytes_read] // do whatever you want with `content` ``` Put part of the above into a loop that exits on `EOF` or whatever and you'll be golden.
This is a really good comparison! Would be cool to see a similar one for other languages one could consider for math-heavy work like C++, Fortran and Rust.
Maybe in the future this would be an interesting thing to do, but I'll be honest and say that the main reason I did it for Odin and Zig is that I actually like Zig, which is more than I can say about Rust. I'm not sure I could sit through coming up with what needs to be done for a comparison to Rust without wanting to just melt into the floor and disappear. It's also hard to be fair about Rust when I am so clearly biased against it. With that said, it could be interesting to take something a *bit* more adventurous like Ada or something. C++ I'm undecided about, but I do have a bias against it as well. It's also unclear *which* C++ you would compare to since there are so many ways of writing it and the last one I used for real was back in 2010/2011, which is not "modern C++". Fortran I have basically zero opinion on because I've literally never used it.
C++ and Fortran have direct GPU support by GPU manufacturers while Rust doesn’t and will probably always stay behind both because of need for constantly updating wrappers and also because of its incompatible operation model (safe mode).
@@PRIMARYATIAS what do you mean by direct support? HLSL is neither C nor C++, and rust compiles to SPIR-V same as others... And how is this relevant to math-heavy work which is commonly done on CPU anyway?
This video was so nice I signed-in to TH-cam so that I can comment. I would agree with many things you have said. I wanted to know what is the font and color theme you are using. Thanks for good discussion, it is hard to find these days.
Very happy to hear that you liked the video. :) The font is called "Berkley Mono" and can be found here: berkeleygraphics.com/typefaces/berkeley-mono/ If I'm not using that one I usually use "Ubuntu Mono" or "JetBrains Mono". The colorscheme is my own and can be found here: github.com/GoNZooo/dotneovim/tree/master/colors If you only want the colorscheme you can copy `gonz-aurora.vim` there, but if you want to change it without writing the vimmy stuff you can use a Ruby gem called `palette` and pass `gonz-aurora.rb` into it and it will create the vim file.
I am a fan of zig since quiet recently. Odin seems a little annoying because I like attaching methods to structs, to me it makes a lot of sense that an datastructure can use methods for example. I wonder if Odin has actual comptime like Zig. One of the great usage of comptime in Zig is the ability to iterate other some struct and generate a function that will serialize/print it automatically. For example in zig std library, you have a json parser that can just read data into a struct, if the fields of the struct do not correspond to the json you read, you get validation error and be done with that. I find this type of thing to give a lot of power in development and avoid third party tools that I require when using C or C++.
The compile-time constructs in Odin only really stretch as far as being able to conditionally run code based on compile-time known booleans and other basic things like that, which is usually done with `when`. It's not trying to do even remotely what Zig is doing, which is definitely a good thing most of the time. I don't dislike `comptime` in Zig but beyond very basic usage it takes on a very similar character to macros where people need to stop and consider whether what they're doing is simply unnecessary and even understandable.
i fear odin might have get stuck in a similar reputation as swift. many people see swift as apple-pnky, which is not at all the case. odin caters quite a bit to gpu and game programming. it’s general purpose, but there’s just so little praise about it in comparison to game dev. similarities of syntax to jai don’t help in this regard. it will definitely develop into this reputation and it might push people away from considering it for other projects, as the features that are explicitly game-dev oriented might look like this field will (continue to?) get more attention as it’s developed. it’s probably not the case, but it’s not really at the forefront as gamedev is. thanks for the video, it’s important to pull odin into view with other general-purpose languages.
I think these kinds of worries are usually pointless in the end. The truth is that the eventual/hypothetical success of Odin doesn't impact writing code in it as much as we'd like to believe. JavaScript is one of the most widespread and popular languages out there with all of the supposed upsides of popularity. Despite these upsides it's one of the most painful experiences I have ever had and I've never seen these supposed upsides actually materialize in a way that felt meaningful to me. Wildly popular and well used libraries have obvious design deficiencies and problems that they shouldn't, etc. So I guess what I'm saying is that I'm less concerned about this than people expect me to be, because I don't think popularity is all it's cracked up to be.
But in what games are special from other software? I know answer - games are MUCH more complex and performance dependent than all of them. I think if you do language just for the hardest programming niche - it must be good in general.
@@iamdozerq Technically - not much, I guess? I've no clue. But socially - the community and the ecosystem! If a domain is emphasized, then it's bound to attract more people interested in exactly that domain. This would increase the rate of development of the ecosystem in that domain. But then whoever is uninterested in it can't see much momentum in the field of her interest, why would she think it would change in the future - and might look for other options.
Odin as a language cannot do GPU stuff by itself. You have to use DirectX, OpenGL, Vulkan or Metal shader API for writing shaders... Odin is general purpose language and the fact that you can make games with it is the same as telling you can make games in C++. Non trivial games require many algorithms and technics to accomplish, so being "game dev" language is nothing more than saying: it can do anything.
So, basicly - zig is more explicit, while odin allows you to write code that looks less verbose. While generally true (from what I saw in videos and odin's web page), some of the things mentioned in video can be less verbose in zig. Sorry in advance for upcoming rant. * The fact that you have to initialize all fields in structure initializer - you even mentioned yourself that you can define default values in structure declaration. Adding " = 0" to each field is literraly just 4 characters more, while giving you much more flexibility than just defaulting to 0 (although I don't know how it works in odin. Can you define default values for fields? Can you explicitly default them to be uninitialized?). * Multivalue returns - there are tupples in zig, but currently there are no tupple destructuring syntax, so yeah, win for odin. * But as for error values - zig errors is just default way for simple cases for "lazy" programmers. No one stopping you from inventing your own ways. In 12:00, for example, you could have just get inspired from rust and return some king of tagged union with success/all possible errors, wich would be easier for users of that function, since you wouldn't have to declare error value outside and pass a pointer to it. But sure, that's a little bit more code to write ("return .{.ok = Token{...}};" instead of just "return Token{...};"). And odin code just looks nicer in generall: * no parentheses for if statements and loops. * "for item in iterable {...}" instead of "for (iterable) |item| {...}" * consistency between constants and functions (instead of "const x = ...;" for constanst and "fn x() T {}" in for functions) * no extra "const/var" keyword for each variable, and instead nice and simple "a := ...;" or "a :: ...;" etc. * snake_case for function, instead of cammelCase - consistent with variables (probably because there are no methods, so no real vallue in diffirentiating between functions, namespaces and variables - it's always obvious from usage without relying on code style). * "-> T" for function return types - questionable, but at least allows for easy searching in code. Don't know if syntax was inspired from jai, but it looks like it :). What I do personally love about zig is how easy it is to avoid unneccessary runtime penalties without relying on magic optimizer - I ALWAYS now what code is get executed at runtime, and what is at compile time, what values are actually passed to function, and what values are used to create generic variants of functions. Zig "comptime" is a magic that everyone can understand (so it's not magic anymore), while in other languages I would always need to add unneccecary runtime checks. For simple example, just look at "std.StaticBitSet" - one small integer for less than size of usize bits, and array of usize for more. That's a true ZERO cost abstraction. In other langs, I would probably settle for always using array (in some languages I would maybe even need an array pointer or slice, maybe even with allocation - just for bitset). While in odin I would be constantly thinking "Do I really need to return 2 values, when I only need result or an error? Do I really need a cost of one extra argument implicitly passed to each function just for convinience of not thinking about allocators unless I need to? How much implicit 0 values field initialization really cost me (esp. with big arrays)?". All of this is probably insignifficant anyway, but still... What I don't like about zig is the currently bad LSP support - zig heavily relies on comtime, but zls currently can't evaluate comptime expressions, so in 80% of the cases you won't get completions even for basic struct fields. But it's only temporary, since it is improving.
Heh, don't worry about ranting. You're correct that adding default values to struct members gives you more flexibility, but that flexibility also makes it unclear what values are going to be set to if you omit values. Since there is no clear rule that everything is zero value initialized now you're going to have to check all of the fields. The clearer strategy by far is to just not use default values, to be honest. I don't consider using unions for return values to be a good solution for Zig programs because this avoids one of the main features of Zig, which is recursive analysis of error codes and using `try` to bubble up errors automatically, like with `or_return` in Odin. I would rather those error codes turned into actual union values so we could have the actual best solution instead of either choosing between errors with values attached or nice language support for inferring error values. I have no real productive opinion of Odin "looking nicer" in the sense that the syntactic constructs make much of a difference, so I can't really comment on that too much. It's nice-ish, just like Zig. A function can opt out of the context system very easily by being declared with the calling convention "contextless" or "c", but I understand your point about context carrying overhead. Multiple return values and so on I think are a bit of a red herring, potentially, but I'm not sure. `zls` is not good, I agree. I didn't bring it up because I don't think it's fair to Zig to complain that the lack of even basic type checking isn't implemented (by design) even after years of `zls` existing. As it stands I wanted to lean on the side of being fair to Zig because otherwise (despite me using the language for years) it seems like some outsider trying to be unfair. `zls` is *not* Zig but it's definitely a point against me practically using Zig right now. Thanks for the comment, your rants are welcome when they are so clearly related to the content! :)
Tuple de-structuring wouldn't do much good unless we can also bubble up errors automatically. The good thing about having errors be returned is that Odin recognizes the last argument in a multiple return value as being for errors. If it is recognized as a non-zero-value that is an error. We use `procedure() or_return` the same way you would use `try procedure()` in Zig. Granted, if Zig now does the same thing and we can `try` with a normal union as an error value I think the point is very good. But, barring that, I just have slightly worse error handling to expect.
Oh yeah, I was mainly responding to @maxcross5454 I didn't mean that tuple de-structuring completely solves the error value propagation problem @@mccGoNZooo
I would say that it seems clear that Zig simply has more users and more exposure, especially with Bun becoming a public spectacle (with both upsides and downsides) at some point. The hype machine has done a lot for Zig and if even just 1% of the people who get exposed to it "get it" and realize what actually goes on, that's a lot of new users. That's not to say that this matters a lot to me. I've spent tons of time using things that were objectively impopular and it really only makes a difference if you're looking for tons of libraries and so on.
I'm playing with both and feel like there are more Zig videos but not enough for either and that Odin ones seem to be a bit older or more game-focused. It's hard to find Odin videos that are not either brief intros or game coding.
Thank you for the video, very informative. For me the namespacing in Zig is fundamental, and solves one of the typical problems with C, where you need to manually namespace your modules (foo_create(), foo_append(), foo_destroy()). I take it that Odin works like C in this regard?
Packages are accessed via `package_name.procedure_name(...)`. Namespacing otherwise is `object_do_thing(object, ...)` instead of `object.do_thing(...)`, yes. I prefer not having methods because they're usually a useless distinction over procedures for very little gain and can't be chained correctly in either Zig or Odin anyway. In languages where you're not expected to handle errors as diligently as you do in Odin and Zig I would think the pipelining from method call syntax was worth it, but it turns into a nothingburger once you actually do value-based error handling procedure by procedure.
Hare is pretty much useless for serious projects because it only supports non-proprietary operating systems (both: as host and as compile target). This means popular systems like Windows and MacOS etc. are all not supported. I like the general idea and concept of Hare, but this "no-proprietary-os"-thing is holding it back. For Hare to gain any popularity, they will need to reconsider this design choice.
i have used both Odin and Zig to develop Tetris.. I found much nicer to work with Odin.. error handling is better, syntax is nicer and cleaner..The thing that i dont like with Odin is you need to have binding to work with C libs.. thats not a problem if Odin have a binding generator like Jai.. In zig you can simply drop the header file and be done with it.. But i dont like with zig, they syntax is ugly, too much noise, having to pass allocator to each function is pure noise.. i wont touch zig any time soon
I would say that `@cImport` hasn't ever saved me as much time or effort as I would like. I don't think the syntax is particularly ugly and really I think differences overall aren't big enough to prefer one super strongly over the other. But, of course, we are all different and so there are things that make more of an impression on some of us than others, etc. :)
Zig syntax seems a bit polarizing. I've read from many people that they find the syntax simple and readable (some even claiming they could read it without knowing the language, which I doubt), while I personally also find it quite noisy and chaotic to look at. In short, a lot of the design decisions in the syntax and language are very opinionated & inflexible, and happen to oppose my opinions and preferences. Which is sad because the core ideas of the language are fantastic. But a lot of other people like it, so I guess it's just not for me.
I'm playing with about ten languages at the moment with the same little project and for me Odin feels noisier, closer to Go level of noise than Zig. Allocators are the exception, but so far I kinda like that Zig makes them explicit.
@@andrewdunbar828 How did this turn out? I've found Odin code to be much less noisy in general (even with always passing allocators explicitly) than Zig code, you end up talking way more about the things that matter in a given function as opposed to the ones that don't. Initialization-heavy code in particular can become much, much clearer if the consuming code uses zero values as defaults and you're not changing a lot of fields.
Hi, maybe I'm a bit late but did you try to speak with Andrew Keller about these issues on error handling? I'd love to know if there are any plans on changing this.
There were plans made a long time ago (and an issue might still exist for it) to add a way to provide more context for errors, but last I checked there were no started implementations for it.
zig claims to have good macros and toolchain, odin claims to have a huge math library and seamless AoSSoA transformation and other optimization tricks. both claim to have good memory management. these are some things to discuss, instead it was a discussion of fairly unimportant syntactic and semantic differences.
Odin doesn't *claim* anything with regards to its libraries. It has libraries for vector & matrix math and has some supporting syntax for them, it's not a claim. Both Zig and Odin have AoSSoA transformations so that's not unique to either. Memory management is, as you said, the same, so why would a video talking about differences bring it up in any great detail? I also have a pinned comment specifically calling out the fact that I didn't want to bring up situational differences like Odin's support for vector & matrix math because it's exactly that: Highly situational. The semantic difference in error handling makes a potentially huge difference depending on the size of your project. There's basically no difference between Odin and Zig except what I talked about in the video, if you think there is I think you're making a lot out of nothing. They're pretty much the same language functionality-wise except when it comes to error handling where Odin wins massively.
@@mccGoNZooo ok. i've not yet used both of them, that's why i was interseted in the video. i thought, there is more difference. I don't think LA is situational though, it is like half of all programming: graphics, simulations, statistics & ml, signal processing.
I think it can be a very meaningful feature in a lot of areas, but as an example I haven't used any vector or matrix math (or indeed any of the syntax sugar for it) in about 2 months of very active work on a real project (about 150 hours a week). It's useful and I like it a lot, but it's still situational. I use it for my current side project because it has to do with graphics, though. Given the above, I didn't really think it was prudent to make a big deal out of it, because the truth is that a lot of Zig programmers simply aren't really going to need it, and a lot of people who use Odin won't unless they specifically start working on game stuff. This is also the reason the big `vendor` part of Odin's standard library wasn't mentioned. It's great, but it's very situational. You won't reach into there unless you specifically are working on gamedev type stuff.
Honestly, I couldn't really say. I haven't inquired about it because the similarities are more or less obvious and even if the answer was "Oh, no, some language from the 90's/2000's actually had this syntax" I'm not sure it would matter much to me. I will say I like the syntax and by extension Go's syntax, though.
The zig code looks convoluted and pedantic. I don't know either language but I wouldn't be excited to learn zig just looking at the syntax. Odin looks more welcoming for sure.
It's unlikely that I will compare to VLang because I have no real interest in the language. Last time I tried it was a long time ago but it basically didn't work at all, it would crash and have memory leaks no matter what you did. This was also around the same time the creator was in hot water because he overpromised and underdelivered on basically everything.
Zero/null default field values in Odin / C / C++ / C# is the reason I will not touch them for the code I want to write and own. Having to explicitly initialize every field OR set a good default means that during refactors, I have one less thing to think about - I can rename fields, add fields, and if I don't absolutely cover every case where that struct is initialized, I will get a compiler error. Anything else is, to me, a waste of my time and a lot of added stress, when I'm just writing code for my own enjoyment or personal ventures. Yeah I'll suck it up and deal with it if it's my job, but otherwise, I'm staying far-far-far away.
Go - I would love go if not for this exact same issue. Ergonomics is a terrible reason to have this be the default. C# only recently introduced Records to provide the ability to define a structure concisely without repeating yourself that requires all fields to be initialized. Man do I get bothered by this, but it's how it goes.
For what it's worth my experience has been basically the exact opposite in hobby and professional Odin code. On top of that the guarantee that literally everything has a zero value and the zero value is useful is even more comforting.
From the lack of response we can gather: As expected, @JimBalter is a loser that doesn't actually know anything and his opinion is based on that fact. He can't make a good argument about what the differences are, hence why he clicked on the video to hear what someone who actually works with these things says.
As someone who has written a fair amount of C I can see where you're coming from and broadly I agree with the sentiment, but I can say that Odin definitely solves more problems than it introduces. Most things are alike in Odin and C and where there are differences I would say it's fairly easy to make a case for the Odin way being a distinct upgrade: - Actual string types are nice - Slices (fat pointers) are good to have as a default - Actual array types that don't decay to pointers meaninglessly in general - Real union types that the compiler actually helps you manage - Standardized ideas about what an allocator is Honestly, the list goes on. All of the above are reasonably good wins in my book, and worth using Odin instead for. We still use plenty of C-like constructs in our programs, because that's the best way to do things, but we leverage the above stuff to get more managable programs out of the process.
@@R00kTruth It's up to you to inform yourself, my main point is that Odin provides many upsides. No one is forcing you to switch to any language in the end and you should use whatever you're comfortable with. The statement that Odin/Zig don't provide any upsides is false, however.
@@mccGoNZooo to be honest, there might be upsides to odin, but I am one of these people who will need to see a massive improvement before switching, for now I can't see any benefit's from my own perspective, I could be wrong but hey, that's life, also with my own project that is heavily using ASM and some C, I would most likely have a brain(stack) overflow trying to learn something else on top.
@@R00kTruth The kind of peace of mind and velocity you gain from using simple things in simple ways is astounding, and doubly so when it's something you're intimately familiar with down to the very core, so I think it's a very reasonable thing to simply stick to C. The main reason I looked to Zig and later Odin was really that I saw an opportunity to get back to lower-level programming and still get access to certain things that I had (conceptually) grown accustomed to (real union types managed by the compiler being one example) and be rid of some of the warts that I had previously identified, so learning a new language made sense. Happily I'll say that Odin represents (to me) the epitome of "You don't need much more than C, and you certainly don't need anything more than procedural/imperative code". From a semantics standpoint we (on the project I work on and have worked on since December last year) largely think in terms of C, and we treat lots of concepts really mostly like we're writing C, and we write aggressively simple code using only simple mechanisms that can be traced right back to C, with only things like compiler-managed tags for unions being the exception, and error handling that carries more context with it, for the most part.
![กี่หมื่นฟ้า | Your Sky Series EP.1 [1/4]](http://i.ytimg.com/vi/vLGjxFL6U_I/mqdefault.jpg)
One thing that I'm surprised you didn't mention and that is a big deal to me: Odin is production ready, stable and is not planning on having major changes to the core language in the near future afaik.
With Zig, the story is different and will be different for some years into the future.
Now, I like Zig, I love the goals and ambition and I will certainly keep my eye on it, but if I work on something real, I also want some stability in my programming language of choice.
Maybe I'm just misjudging Odin's maturity?
EDIT: Also, thank you for the video, I like it! :)
I think there's a bit of column A and a bit of column B here. Odin, the language, doesn't have a lot on its roadmap and is very stable. At the same time we just had a period of maybe half a week or so where projects stalled because if you had LLVM17 installed and compiled with `o:speed` you'd get a compiler crash. There are disruptive things that happen still. On top of that it's generally advisable to stay at least abreast of what is going on in `master` and you'll likely be able to find places to make better or fix in the standard library still.
zig has a more stable future as a nonprofit
@@Z3r0XoL hm? odin is used in a few industry leader software, there's no better assurance than that that it will stay afloat. also it's an open source project.
both projects have a stable future ahead of them. I don't know why you have to make it a either 1 or the other deal, it's not a zero sum game, both languages can exist and be valuable to the people interested in using them
Note that the video does not touch on things that are perhaps a bit more situational:
- It doesn't cover array programming or swizzling which Odin has. This is covered in my Odin videos to a minor extent.
- It doesn't cover the `vendor` libraries that Odin has, because they are highly situational. Odin is just generally significantly nicer for gamedev in general, so for that context this would come into play.
- It doesn't cover `@cImport` which Zig has, mostly because while I think it's very good, it always required a lot of fiddling and writing wrappers for me anyway. This may have changed since I last checked.
- It doesn't cover `async` in Zig because I'm not even sure I would ever want to use it in its final form and I don't know that it's even in a shippable state yet.
Regarding comp-time- in odin you can do a metaprogramming approach. I made a pair of videos showing how to do this. The most straightforward way is using custom attributes which you can pick up with the core/front-end (iirc) parser and then do operations on it. I had a use case where I populated a map from a table, the generated file then is used in the main project as if hand typed. It's a bit more work than zigs builtin approach, but it's not at all hard because we have the parser as a library.
As I alluded to, this is kind of a version of what I've done with code generation before and honestly, this is basically what I'd do in general if this problem came up again. I'm not sure that I believe in most metaprogramming solutions and stuff anymore anyway; they're usually just more code I didn't write that I now have to debug through compilation phases, etc., whereas with a separate solution I can be completely 100% sure what's going on.
@@mccGoNZooo i agree - i was only providing an argument that the loss of comp-time in odin is not so much of a loss as one would first think, the capability is there and easily accessible, but you do have to do something, putting a little bit of friction in place to perhaps drive you towards a better solution.
great breakdown. it tracks with my own experience as well. i tend to like zig slightly more than odin, but i wouldn't be unhappy with using either. i think people sleep on odin's swizzling though. i've been doing some game stuff and swizzling makes some things so much more expressive and understandable at a glance. thanks for the video.
Swizzling, array programming and the extensive vendor collection of libraries are really, really good for gamedev or other GPU programming-related things, yeah. I do think it's situational, though, and the reason I didn't mention these things that are *clearly* better in Odin is because that basically only pays off when you're doing certain things. I wanted to err on the side of caution and be as fair as possible in the general case.
I definitely don't find Zig a weekend language. It must be the things I choose to code to learn it with but I always run into frustrations. But I still like it. My only frustration with Odin was trying to install it without brew, but I finally got there today (my MacOS SDK is in a different location than Odin expects) and I'm finding it much quicker to pick up than Zig. Surprisingly the project I'm trying this time was really easy to get working in Rust!
I'm not sure what the things you've chosen to do are, but I don't usually find that learning a language has much to do with what you're choosing to do with it. I do think it's important to take things on that are managable for your skill level and it can be useful to spend your time doing things that aren't too far outside of your comfort zone in the beginning, i.e. probably very managable projects for a week or two.
With that mindset I think Zig is actually very easy to learn and certainly in 2019 it was doable in a weekend. I certainly felt very productive very fast. Granted, I wouldn't touch their `async` stuff that they're trying to do with a 10 foot pole... So, you know, things change...
Very happy to hear that Odin is making sense to you. I think, to be fair, that previous exposure to Zig helps a lot with learning Odin because there's a lot that's shared between them.
Edit:
I guess I should ask what "easy to get working" means, because I'm not sure I understand what you mean from context.
@@mccGoNZooo Well in my case I'm an old programmer used to low-level and high-level languages but stopped as a job ages ago and now just do recreational programming on things I find interesting. I'm always finding bugs and problems my professional friends never hit.
Usually I try out a new language by reimplementing something I've already got working in one or more other languages. So not outside my general skill level but often outside my skill level in a new language.
First go at Zig I hit a problem where I wanted to check for existence of a group of files with patterned names but in Zig filenames and paths are always comptime and string formatting didn't work with unused parameters. Nobody had wanted to do that before but it was doable in every other language.
Zig has completely removed the old async system for a while now. Andrew recently postponed implementing a new system.
I spoke a bit too soon with Odin. When I got to gigantic inputs the OS was killing my process due to leaking memory reading from stdin, presumably because I don't understand context and allocators yet. In Zig allocators are always explicit so you always know when you'll have to free something.
Anything that returns values that outlive the scope of your current function is going to likely be heap allocated. The main exception would be values that are made up of values you've used as input, i.e. sub-strings of strings you passed in, etc.; they'll have the same lifetime as the values they're derived from. This really only applies to anything involving pointers; normal values can be interpreted from just data and will outlive anything because they're just values: Numbers, booleans, characters, arrays of all of those (but not slices; those are pointers with a length attached).
Things to look for that are Odin-specific that'll tell you something allocates:
- It's a function that takes an allocator, usually as an optional argument. The default value of that parameter is commonly `context.allocator`
- It works on a structure that stores a `mem.Allocator`
- It produces a value that involves a pointer but there seems to be no backing value (a passed-in buffer/string, etc.); this backing value and/or the value itself is probably heap allocated
With all of this said I'd recommend just using a backing buffer that you read file/handle contents into via functions like this:
github.com/odin-lang/Odin/blob/master/core/os/os.odin#L77
`read_full` will read into the buffer you specify and you can then work on the contents after the call is done. You'll get the amount of bytes it actually read as a return value so you can slice into your backing buffer:
```
backing_buffer: [4096]byte
bytes_read, read_error := os.read_full(os.stdin, backing_buffer[:])
content := backing_buffer[:bytes_read]
// do whatever you want with `content`
```
Put part of the above into a loop that exits on `EOF` or whatever and you'll be golden.
@@mccGoNZooo Both Odin and Zig, and Rust too actually, have very helpful communities on Discord so I've got working great now. Thanks for the tips!
Nice overview!
FYI: the audio in the outro is left ear only for me
Heh, yeah, I exported it as "mono" thinking it would just be uniform in both but I guess it didn't quite turn out that way.
This is a really good comparison! Would be cool to see a similar one for other languages one could consider for math-heavy work like C++, Fortran and Rust.
Maybe in the future this would be an interesting thing to do, but I'll be honest and say that the main reason I did it for Odin and Zig is that I actually like Zig, which is more than I can say about Rust. I'm not sure I could sit through coming up with what needs to be done for a comparison to Rust without wanting to just melt into the floor and disappear. It's also hard to be fair about Rust when I am so clearly biased against it.
With that said, it could be interesting to take something a *bit* more adventurous like Ada or something. C++ I'm undecided about, but I do have a bias against it as well. It's also unclear *which* C++ you would compare to since there are so many ways of writing it and the last one I used for real was back in 2010/2011, which is not "modern C++".
Fortran I have basically zero opinion on because I've literally never used it.
C++ and Fortran have direct GPU support by GPU manufacturers while Rust doesn’t and will probably always stay behind both because of need for constantly updating wrappers and also because of its incompatible operation model (safe mode).
@@PRIMARYATIAS what do you mean by direct support? HLSL is neither C nor C++, and rust compiles to SPIR-V same as others... And how is this relevant to math-heavy work which is commonly done on CPU anyway?
This video was so nice I signed-in to TH-cam so that I can comment. I would agree with many things you have said. I wanted to know what is the font and color theme you are using. Thanks for good discussion, it is hard to find these days.
Very happy to hear that you liked the video. :)
The font is called "Berkley Mono" and can be found here: berkeleygraphics.com/typefaces/berkeley-mono/
If I'm not using that one I usually use "Ubuntu Mono" or "JetBrains Mono".
The colorscheme is my own and can be found here: github.com/GoNZooo/dotneovim/tree/master/colors
If you only want the colorscheme you can copy `gonz-aurora.vim` there, but if you want to change it without writing the vimmy stuff you can use a Ruby gem called `palette` and pass `gonz-aurora.rb` into it and it will create the vim file.
I am a fan of zig since quiet recently.
Odin seems a little annoying because I like attaching methods to structs, to me it makes a lot of sense that an datastructure can use methods for example.
I wonder if Odin has actual comptime like Zig. One of the great usage of comptime in Zig is the ability to iterate other some struct and generate a function that will serialize/print it automatically. For example in zig std library, you have a json parser that can just read data into a struct, if the fields of the struct do not correspond to the json you read, you get validation error and be done with that. I find this type of thing to give a lot of power in development and avoid third party tools that I require when using C or C++.
The compile-time constructs in Odin only really stretch as far as being able to conditionally run code based on compile-time known booleans and other basic things like that, which is usually done with `when`. It's not trying to do even remotely what Zig is doing, which is definitely a good thing most of the time. I don't dislike `comptime` in Zig but beyond very basic usage it takes on a very similar character to macros where people need to stop and consider whether what they're doing is simply unnecessary and even understandable.
i fear odin might have get stuck in a similar reputation as swift. many people see swift as apple-pnky, which is not at all the case. odin caters quite a bit to gpu and game programming. it’s general purpose, but there’s just so little praise about it in comparison to game dev. similarities of syntax to jai don’t help in this regard. it will definitely develop into this reputation and it might push people away from considering it for other projects, as the features that are explicitly game-dev oriented might look like this field will (continue to?) get more attention as it’s developed. it’s probably not the case, but it’s not really at the forefront as gamedev is.
thanks for the video, it’s important to pull odin into view with other general-purpose languages.
I think these kinds of worries are usually pointless in the end. The truth is that the eventual/hypothetical success of Odin doesn't impact writing code in it as much as we'd like to believe. JavaScript is one of the most widespread and popular languages out there with all of the supposed upsides of popularity. Despite these upsides it's one of the most painful experiences I have ever had and I've never seen these supposed upsides actually materialize in a way that felt meaningful to me. Wildly popular and well used libraries have obvious design deficiencies and problems that they shouldn't, etc.
So I guess what I'm saying is that I'm less concerned about this than people expect me to be, because I don't think popularity is all it's cracked up to be.
But in what games are special from other software? I know answer - games are MUCH more complex and performance dependent than all of them. I think if you do language just for the hardest programming niche - it must be good in general.
@@iamdozerq Technically - not much, I guess? I've no clue. But socially - the community and the ecosystem! If a domain is emphasized, then it's bound to attract more people interested in exactly that domain. This would increase the rate of development of the ecosystem in that domain. But then whoever is uninterested in it can't see much momentum in the field of her interest, why would she think it would change in the future - and might look for other options.
Odin as a language cannot do GPU stuff by itself. You have to use DirectX, OpenGL, Vulkan or Metal shader API for writing shaders... Odin is general purpose language and the fact that you can make games with it is the same as telling you can make games in C++. Non trivial games require many algorithms and technics to accomplish, so being "game dev" language is nothing more than saying: it can do anything.
11:30 I too have been following this Zig issue for a long time ^^
It's definitely worth following, I think it would do a lot for Zig to catch up to Odin in terms of language capability.
So, basicly - zig is more explicit, while odin allows you to write code that looks less verbose.
While generally true (from what I saw in videos and odin's web page), some of the things mentioned in video can be less verbose in zig.
Sorry in advance for upcoming rant.
* The fact that you have to initialize all fields in structure initializer - you even mentioned yourself that you can define default values in structure declaration. Adding " = 0" to each field is literraly just 4 characters more, while giving you much more flexibility than just defaulting to 0 (although I don't know how it works in odin. Can you define default values for fields? Can you explicitly default them to be uninitialized?).
* Multivalue returns - there are tupples in zig, but currently there are no tupple destructuring syntax, so yeah, win for odin.
* But as for error values - zig errors is just default way for simple cases for "lazy" programmers. No one stopping you from inventing your own ways.
In 12:00, for example, you could have just get inspired from rust and return some king of tagged union with success/all possible errors, wich would be easier for users of that function, since you wouldn't have to declare error value outside and pass a pointer to it.
But sure, that's a little bit more code to write ("return .{.ok = Token{...}};" instead of just "return Token{...};").
And odin code just looks nicer in generall:
* no parentheses for if statements and loops.
* "for item in iterable {...}" instead of "for (iterable) |item| {...}"
* consistency between constants and functions (instead of "const x = ...;" for constanst and "fn x() T {}" in for functions)
* no extra "const/var" keyword for each variable, and instead nice and simple "a := ...;" or "a :: ...;" etc.
* snake_case for function, instead of cammelCase - consistent with variables (probably because there are no methods, so no real vallue in diffirentiating between functions, namespaces and variables - it's always obvious from usage without relying on code style).
* "-> T" for function return types - questionable, but at least allows for easy searching in code.
Don't know if syntax was inspired from jai, but it looks like it :).
What I do personally love about zig is how easy it is to avoid unneccessary runtime penalties without relying on magic optimizer - I ALWAYS now what code is get executed at runtime, and what is at compile time, what values are actually passed to function, and what values are used to create generic variants of functions. Zig "comptime" is a magic that everyone can understand (so it's not magic anymore), while in other languages I would always need to add unneccecary runtime checks. For simple example, just look at "std.StaticBitSet" - one small integer for less than size of usize bits, and array of usize for more. That's a true ZERO cost abstraction. In other langs, I would probably settle for always using array (in some languages I would maybe even need an array pointer or slice, maybe even with allocation - just for bitset).
While in odin I would be constantly thinking "Do I really need to return 2 values, when I only need result or an error? Do I really need a cost of one extra argument implicitly passed to each function just for convinience of not thinking about allocators unless I need to? How much implicit 0 values field initialization really cost me (esp. with big arrays)?". All of this is probably insignifficant anyway, but still...
What I don't like about zig is the currently bad LSP support - zig heavily relies on comtime, but zls currently can't evaluate comptime expressions, so in 80% of the cases you won't get completions even for basic struct fields. But it's only temporary, since it is improving.
Heh, don't worry about ranting.
You're correct that adding default values to struct members gives you more flexibility, but that flexibility also makes it unclear what values are going to be set to if you omit values. Since there is no clear rule that everything is zero value initialized now you're going to have to check all of the fields. The clearer strategy by far is to just not use default values, to be honest.
I don't consider using unions for return values to be a good solution for Zig programs because this avoids one of the main features of Zig, which is recursive analysis of error codes and using `try` to bubble up errors automatically, like with `or_return` in Odin. I would rather those error codes turned into actual union values so we could have the actual best solution instead of either choosing between errors with values attached or nice language support for inferring error values.
I have no real productive opinion of Odin "looking nicer" in the sense that the syntactic constructs make much of a difference, so I can't really comment on that too much. It's nice-ish, just like Zig.
A function can opt out of the context system very easily by being declared with the calling convention "contextless" or "c", but I understand your point about context carrying overhead. Multiple return values and so on I think are a bit of a red herring, potentially, but I'm not sure.
`zls` is not good, I agree. I didn't bring it up because I don't think it's fair to Zig to complain that the lack of even basic type checking isn't implemented (by design) even after years of `zls` existing. As it stands I wanted to lean on the side of being fair to Zig because otherwise (despite me using the language for years) it seems like some outsider trying to be unfair. `zls` is *not* Zig but it's definitely a point against me practically using Zig right now.
Thanks for the comment, your rants are welcome when they are so clearly related to the content! :)
Zig does have tuple de-structuring syntax now fyi.
Tuple de-structuring wouldn't do much good unless we can also bubble up errors automatically. The good thing about having errors be returned is that Odin recognizes the last argument in a multiple return value as being for errors. If it is recognized as a non-zero-value that is an error. We use `procedure() or_return` the same way you would use `try procedure()` in Zig.
Granted, if Zig now does the same thing and we can `try` with a normal union as an error value I think the point is very good. But, barring that, I just have slightly worse error handling to expect.
Oh yeah, I was mainly responding to @maxcross5454 I didn't mean that tuple de-structuring completely solves the error value propagation problem @@mccGoNZooo
@@permutationlock Thanks for the info! I've been using latest stable release (0.11.0) and wasn't aware of the changes in the master branch.
if you're talking about which made more of a mark, i do see a lot more videos on youtube of people coding in odin than i do of zig.
I would say that it seems clear that Zig simply has more users and more exposure, especially with Bun becoming a public spectacle (with both upsides and downsides) at some point. The hype machine has done a lot for Zig and if even just 1% of the people who get exposed to it "get it" and realize what actually goes on, that's a lot of new users.
That's not to say that this matters a lot to me. I've spent tons of time using things that were objectively impopular and it really only makes a difference if you're looking for tons of libraries and so on.
I'm playing with both and feel like there are more Zig videos but not enough for either and that Odin ones seem to be a bit older or more game-focused. It's hard to find Odin videos that are not either brief intros or game coding.
Thank you for the video, very informative. For me the namespacing in Zig is fundamental, and solves one of the typical problems with C, where you need to manually namespace your modules (foo_create(), foo_append(), foo_destroy()). I take it that Odin works like C in this regard?
Packages are accessed via `package_name.procedure_name(...)`. Namespacing otherwise is `object_do_thing(object, ...)` instead of `object.do_thing(...)`, yes. I prefer not having methods because they're usually a useless distinction over procedures for very little gain and can't be chained correctly in either Zig or Odin anyway. In languages where you're not expected to handle errors as diligently as you do in Odin and Zig I would think the pipelining from method call syntax was worth it, but it turns into a nothingburger once you actually do value-based error handling procedure by procedure.
You can do exact same thing with Odin packages (which are folder/directory)
Is there a Kratos language too?
If you like Zig and Odin then checkout hare. I don't think it will ever be a huge language, but some pretty interesting stuff.
I'll take a look at it, thanks. :)
Hare is pretty much useless for serious projects because it only supports non-proprietary operating systems (both: as host and as compile target). This means popular systems like Windows and MacOS etc. are all not supported. I like the general idea and concept of Hare, but this "no-proprietary-os"-thing is holding it back. For Hare to gain any popularity, they will need to reconsider this design choice.
As C3 falls somewhere between the two, I’d love to hear your take on it as well.
i have used both Odin and Zig to develop Tetris.. I found much nicer to work with Odin.. error handling is better, syntax is nicer and cleaner..The thing that i dont like with Odin is you need to have binding to work with C libs.. thats not a problem if Odin have a binding generator like Jai.. In zig you can simply drop the header file and be done with it.. But i dont like with zig, they syntax is ugly, too much noise, having to pass allocator to each function is pure noise.. i wont touch zig any time soon
I would say that `@cImport` hasn't ever saved me as much time or effort as I would like. I don't think the syntax is particularly ugly and really I think differences overall aren't big enough to prefer one super strongly over the other. But, of course, we are all different and so there are things that make more of an impression on some of us than others, etc. :)
Zig syntax seems a bit polarizing. I've read from many people that they find the syntax simple and readable (some even claiming they could read it without knowing the language, which I doubt), while I personally also find it quite noisy and chaotic to look at. In short, a lot of the design decisions in the syntax and language are very opinionated & inflexible, and happen to oppose my opinions and preferences. Which is sad because the core ideas of the language are fantastic. But a lot of other people like it, so I guess it's just not for me.
I'm playing with about ten languages at the moment with the same little project and for me Odin feels noisier, closer to Go level of noise than Zig. Allocators are the exception, but so far I kinda like that Zig makes them explicit.
@@andrewdunbar828 How did this turn out? I've found Odin code to be much less noisy in general (even with always passing allocators explicitly) than Zig code, you end up talking way more about the things that matter in a given function as opposed to the ones that don't. Initialization-heavy code in particular can become much, much clearer if the consuming code uses zero values as defaults and you're not changing a lot of fields.
Great explanation
Happy to hear that you thought so. If nothing else I hope I was fair and at least a little bit informative.
Hi, maybe I'm a bit late but did you try to speak with Andrew Keller about these issues on error handling? I'd love to know if there are any plans on changing this.
There were plans made a long time ago (and an issue might still exist for it) to add a way to provide more context for errors, but last I checked there were no started implementations for it.
zig claims to have good macros and toolchain, odin claims to have a huge math library and seamless AoSSoA transformation and other optimization tricks. both claim to have good memory management. these are some things to discuss, instead it was a discussion of fairly unimportant syntactic and semantic differences.
Odin doesn't *claim* anything with regards to its libraries. It has libraries for vector & matrix math and has some supporting syntax for them, it's not a claim. Both Zig and Odin have AoSSoA transformations so that's not unique to either. Memory management is, as you said, the same, so why would a video talking about differences bring it up in any great detail? I also have a pinned comment specifically calling out the fact that I didn't want to bring up situational differences like Odin's support for vector & matrix math because it's exactly that: Highly situational.
The semantic difference in error handling makes a potentially huge difference depending on the size of your project.
There's basically no difference between Odin and Zig except what I talked about in the video, if you think there is I think you're making a lot out of nothing. They're pretty much the same language functionality-wise except when it comes to error handling where Odin wins massively.
@@mccGoNZooo ok. i've not yet used both of them, that's why i was interseted in the video. i thought, there is more difference.
I don't think LA is situational though, it is like half of all programming: graphics, simulations, statistics & ml, signal processing.
I think it can be a very meaningful feature in a lot of areas, but as an example I haven't used any vector or matrix math (or indeed any of the syntax sugar for it) in about 2 months of very active work on a real project (about 150 hours a week). It's useful and I like it a lot, but it's still situational. I use it for my current side project because it has to do with graphics, though.
Given the above, I didn't really think it was prudent to make a big deal out of it, because the truth is that a lot of Zig programmers simply aren't really going to need it, and a lot of people who use Odin won't unless they specifically start working on game stuff. This is also the reason the big `vendor` part of Odin's standard library wasn't mentioned. It's great, but it's very situational. You won't reach into there unless you specifically are working on gamedev type stuff.
Is Odin's syntax designed to be similar to Golang?
Honestly, I couldn't really say. I haven't inquired about it because the similarities are more or less obvious and even if the answer was "Oh, no, some language from the 90's/2000's actually had this syntax" I'm not sure it would matter much to me.
I will say I like the syntax and by extension Go's syntax, though.
It’s inspired by Jai
Nice video, Thank you ❤
Glad you liked it!
The zig code looks convoluted and pedantic. I don't know either language but I wouldn't be excited to learn zig just looking at the syntax. Odin looks more welcoming for sure.
Zig is definitely pedantic, I think it's a design goal for sure.
@@mccGoNZooo lol. imagine...
Thx for the video!
Thank you for watching! :)
Vs Vlang?
It's unlikely that I will compare to VLang because I have no real interest in the language. Last time I tried it was a long time ago but it basically didn't work at all, it would crash and have memory leaks no matter what you did. This was also around the same time the creator was in hot water because he overpromised and underdelivered on basically everything.
Zero/null default field values in Odin / C / C++ / C# is the reason I will not touch them for the code I want to write and own. Having to explicitly initialize every field OR set a good default means that during refactors, I have one less thing to think about - I can rename fields, add fields, and if I don't absolutely cover every case where that struct is initialized, I will get a compiler error. Anything else is, to me, a waste of my time and a lot of added stress, when I'm just writing code for my own enjoyment or personal ventures. Yeah I'll suck it up and deal with it if it's my job, but otherwise, I'm staying far-far-far away.
Go - I would love go if not for this exact same issue. Ergonomics is a terrible reason to have this be the default. C# only recently introduced Records to provide the ability to define a structure concisely without repeating yourself that requires all fields to be initialized. Man do I get bothered by this, but it's how it goes.
For what it's worth my experience has been basically the exact opposite in hobby and professional Odin code. On top of that the guarantee that literally everything has a zero value and the zero value is useful is even more comforting.
played at 1.25 speed and still boring , focused on the wrong things, overly specific examples rather than general descriptions of differences
Since you seem to be in the know, what are the right things to focus on when it comes to the differences between Odin and Zig?
Have you tried playing it at 1.5 speed?
From the lack of response we can gather:
As expected, @JimBalter is a loser that doesn't actually know anything and his opinion is based on that fact. He can't make a good argument about what the differences are, hence why he clicked on the video to hear what someone who actually works with these things says.
I'll stick with C, all of these other useless languages, don't fix anything, they don't make anything easier,
it's all the same concept but more mess
As someone who has written a fair amount of C I can see where you're coming from and broadly I agree with the sentiment, but I can say that Odin definitely solves more problems than it introduces.
Most things are alike in Odin and C and where there are differences I would say it's fairly easy to make a case for the Odin way being a distinct upgrade:
- Actual string types are nice
- Slices (fat pointers) are good to have as a default
- Actual array types that don't decay to pointers meaninglessly in general
- Real union types that the compiler actually helps you manage
- Standardized ideas about what an allocator is
Honestly, the list goes on. All of the above are reasonably good wins in my book, and worth using Odin instead for.
We still use plenty of C-like constructs in our programs, because that's the best way to do things, but we leverage the above stuff to get more managable programs out of the process.
@@mccGoNZooo Well You have made some good points, but I will have to see some more well explained examples before I'll make my mind up..
@@R00kTruth It's up to you to inform yourself, my main point is that Odin provides many upsides. No one is forcing you to switch to any language in the end and you should use whatever you're comfortable with. The statement that Odin/Zig don't provide any upsides is false, however.
@@mccGoNZooo to be honest, there might be upsides to odin, but I am one of these people who will need to see a massive improvement before switching,
for now I can't see any benefit's from my own perspective, I could be wrong but hey, that's life, also with my own project that is heavily using ASM and some C, I would most likely have a brain(stack) overflow trying to learn something else on top.
@@R00kTruth The kind of peace of mind and velocity you gain from using simple things in simple ways is astounding, and doubly so when it's something you're intimately familiar with down to the very core, so I think it's a very reasonable thing to simply stick to C.
The main reason I looked to Zig and later Odin was really that I saw an opportunity to get back to lower-level programming and still get access to certain things that I had (conceptually) grown accustomed to (real union types managed by the compiler being one example) and be rid of some of the warts that I had previously identified, so learning a new language made sense.
Happily I'll say that Odin represents (to me) the epitome of "You don't need much more than C, and you certainly don't need anything more than procedural/imperative code". From a semantics standpoint we (on the project I work on and have worked on since December last year) largely think in terms of C, and we treat lots of concepts really mostly like we're writing C, and we write aggressively simple code using only simple mechanisms that can be traced right back to C, with only things like compiler-managed tags for unions being the exception, and error handling that carries more context with it, for the most part.