วีดีโอ

says the loser who posts troll comments on the internet ol

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.

No, you can still have imports, they just can't be circular, i.e. you can't import something that imports the current file, transitively or directly. It's not particularly hard to avoid circular imports and it's still very useful to have packages

No, I think I'm fine with doing it this way for the most part. It's already helped several people to contrast the way things work with what they already know, and both instances of it in this video are things worth talking about so that viewers can store it in their mind for later understanding if it's something they're not currently getting. As for `undefined`, I've rewatched the video and there really is no reasonable ambiguity to it in the video. You can't use the word "undefined" in Odin, but you can use `---`, sort of, except you shouldn't, because you won't have uninitialized memory anyway since everything is zero-initialized... So just don't set a value at all and you'll be fine; this is what I mean in the section of the video where I talk about setting only the things that "matter right now".

I'll be honest, I have no idea what this comment is really trying to say.

@@mccGoNZooo no one knows what it means but its provocative

That's probably a reasonable suggestion for people who are stuck with Rust, but I think there are better directions to pick as base defaults in the end.

Thank you for watching! :)

Nevermind, I figured it out from another comment where you posted your Neovim config files. Turns out I needed to add Odin to treesitter!

No, I think Odin is far too reduced in terms of language functionality to be a replacement for C++ (basically no overloading, certainly no operator overloading, etc., no classes, just structs and procedures). On top of that literally all of the behavior is exactly like C and not C++ (no RAII). Odin has very little in common with C++ and basically everything in common with C, so I would never recommend it to someone who likes C++.

⁠@@mccGoNZooothanks for the answer! Sorry, it seems like my language wasn’t very precise: I don’t mean that Odin is like c++ but better, but rather it seems to occupy a use case that is similar to c++ but without the oop classes and complexity that I personally don’t like! i.e. it’s a good fit for game development and systems stuff that is currently occupied by c++, not c. By the way, I come from a computational modelling background so I’m using Julia and Python at the moment, but like the look of Odin for making binaries with simple memory management system.

@@alst4817 In terms of use cases I think they cover about the same space, yes, but I think games are only really written in C++ because of historical baggage like C99 being famously unsupported by the visual studio compiler for a very long time and you technically basically had to write C++. Most systems programming elsewhere is done more in C, I think; at least if you weigh importance and size of project over just number of projects. What are you thinking of making with Odin, by the way?

@@mccGoNZoooyes, historical path dependency can create strange outcomes! I don’t like Python much, lisp is a much better scripting language but that’s where a lot of science is at the moment… I research complex systems, so I make traditional models and ABM. Julia is great for that, but I would like to make something really large, and pass the binary around without the mess of non-technical colleagues dealing with the JIT. Plus, it looks cool!

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.

This is not a technical support channel, sorry. I recommend looking for a repair shop for mobile phones.

@@mccGoNZooo thank you sir😊

It's very useful indeed! :)

I've only looked Hare very briefly and it doesn't seem to have any concept of custom allocators, which makes it very awkward to use and makes me question the users' and creator's familiarity with the concerns that I usually have with systems level code. It's not a good look for any language that wants to make memory management sane and possible to make fast and efficient. Z I know nothing about. The list of languages is not exhaustive; there are plenty of languages that I simply didn't bring up because they're not worth bringing up: They're either not interesting enough to really talk about in a video like this. Hare strikes me as that kind of language; it has seemingly no benefits that aren't already in languages in this video.

@@mccGoNZooo I meant "V", not "Z".

@@MrApplewine I looked at V around 2019 and the unfortunate reality then and later was that it was sold as something it really wasn't; the compiler would produce code that had memory leaks for even the most basic of things while the claim was that it could somehow solve that issue on its own. All in all I would say V seemed to be a lot about perception rather than reality. I've also never seen anything from it that would make it actually better than Odin or Zig, so there really hasn't been any reason to "see past" these obvious lies and half-truths to see whether there was something actually useful there.

@@mccGoNZooo I see. What do you think about C-Odin, or "Codin" the Odin to C compiler written in C? I just watched a the video on C-Odin by Dale Weiler. The 3 main reasons for C-Odin are supposed to be 1.LLVM (not using it) 2. Speed 3. Debugging.

@@MrApplewine I don't have much of an opinion on it. As far as I can see it hasn't really materialized in any meaningful way and the Tilde backend for Odin will do the same thing and will be built into the Odin compiler.

It's definitely worth following, I think it would do a lot for Zig to catch up to Odin in terms of language capability.

On the other hand: Large teams are not desirable either (they produce garbage, they produce it slowly and are usually unable to fix that garbage in a timely fashion, they are everything you don't want in software development) and I don't know what "diverse" is meant to mean here or why it has anything to do with package managers (or vendoring code). Distributed teams also has nothing to do with package managers. I think what you've written is fairly uninformed speculation, but it "sounds right" to a lot of people, i.e. it's the kind of thing you can get away with writing usually without getting much pushback, even though it has basically zero backing in any kind of observed reality or reason.

Thank you for watching and enjoying it! :)

Disingenuous is a bit of a stretch... Rust heavily promotes package-based development and the community heavily favors `serde` for things, it's not a stretch to say that "adding JSON decoding can add seconds to your compile times". It's true that you can actually have a Rust project that doesn't take a long time to compile, but I would argue that it's rarer, harder to come by in the wild and much harder to maintain that situation in Rust than it is in Odin. Everything is a tradeoff, and unless you end up in good company both C++ and Rust users will usually tend to favor more language candy, more dependencies and clever language usage over short compile times.

It depends on who you ask, of course, but in my book Haskell has a very distinct edge in anything that requires multiple threads and shared memory. It has transactional variables/STM, which allows you to treat memory as you would database values, i.e. with transactions, rollbacks, etc.. None of this requires the swamp that is Rust's `async` hell. On top of that Haskell does, if you are willing to get into it, have a compile-time only constraints system that allows you to very, very tightly control exactly what effects functions can execute without bothering with ridiculous things like algebraic effects. If that's your jam, Haskell will provide that safety whereas Rust cannot in any reasonable way do the same. Haskell is a better imperative language than most, and using mutable values in it is better than in most languages, IMO. Personally I'm much better off using something like Odin nowadays, because I think it just hits the right notes and makes the right tradeoffs for getting stuff done, but Haskell is a very reasonable language for getting stuff done for the most part. The only parts that annoy me greatly are error handling (which Rust doesn't improve on, by the way) and some slice of the community that doesn't appreciate that the language is only there to facilitate getting stuff done (where Rust is even worse).

Very happy to hear that you like them! :)

"EveryMilliseconds" is arguably more correct in the case of several milliseconds, i.e. "Every N milliseconds". "EveryMillisecond" would only really make sense if it was a singular millisecond.

There are official/big channels of communication that don't devolve very badly, yes, but I think there is a general tendency in these types of places to build up a cult-like feeling around the language. I've seen it in both the small and the large, growing over time. It can start out as innocent "Guys, I can't believe this language is so good!" type of stuff and with enough of that you very quickly get this tension between legitimate gripes (usually from people who have used the language more) with the language and the overenthusiastic beginner type of opinions. With that said I think Go and Odin have a very long lasting feeling of joy because they both have a very fundamental joy of simplicity to them, which takes you much further and lasts longer than just "Wow, this particular thing is so 'simple' in this language!" type stuff.

The gist is: - The functions need to be exported via a shared library - A declaration of which functions exist and their arities needs to exist in the exported library as well - Erlang/Elixir needs to be told to load the NIF (this is a module load directive in the module) and it will auto-direct any function calls with matching names and arities to the appropriate NIFs `erldin` is just a small collection of helper functions and types to expose Erlang's C library functionality

No, I don't think using these things is fighting the language, but I think it's important to consider whether you actually need them. The truth is that a function working with a union is usually a much better way to have a function that works with multiple different things, and this is a much more common scenario. If you truly do need some kind of dynamic dispatch a function pointer on a struct is a perfectly fine way to do it.

There's nothing really special about sending data back, you just encode the data into the same format the server decodes it from and that's it.

When you use this syntax: x, y := union_value.(Union_Member) x is going to be a `Union_Member` that is filled in if `union_value` was a `Union_Member`, `y` is going to tell you whether it was. So `y` is always a `bool` and is there only to tell you whether you had a match.

Sorry the theme isn't to your liking. This is the first time anyone ever explicitly says it's too blue.

I'll keep that in mind for a potential return to the learning videos. There isn't *that* much to them, but it's certainly worth covering.

D is a gem of a language, but history has not been kind to it. I think D is one of those languages that would do extremely well with a group of certain people with very clear guidelines for how to do things. I also think those people probably should construct a solid way to use custom allocators, or maybe I'm underestimating the standard library allocators a bit. Last I checked they weren't great to use. I also think using `-betterC` as a default might be viable for the type of team I referenced above, which makes D a much, much better language than without it, IMO.

I think maybe this is mostly because I've seen what Rust turned out to be and it's scarcely more interesting than C++ with RAII, i.e. it's basically not useful at all. I think it's clear at this point that that design was a dead end and that it's probably more useful and will yield better results to expose the actual proofs as values for the programmer. With that said there's also the much more obvious alternative: Leave both of those paths entirely and just use a much less complex language and set of tools to get better end results. That's where I personally am right now and probably where I'll stay mentally for the foreseeable future.

Did you land on one yet? My personal vote would go towards Odin, but this depends a bit on whether what you're doing is something you're going to need a ton of domain-specific libraries for. Most problems are in fact *not* that, but this also depends on how ready you personally are to implement things yourself.

Haven't used it, it was wildly overhyped and proven to be completely broken very fast. This led to the creator making some very questionable posts on the Internet and I think this kind of soured a lot of people on the language, myself included. On top of that I don't think there is any real upside to using V over, say, Odin. At least this was the case last I checked.

Odin has a fair amount of structures in the standard library, but not nearly as many (or as badly implemented/incomprehensible) as the C++ STL ones. You can find the core library here: pkg.odin-lang.org/core/

Happy to hear it was useful! It's very fun to work with stuff like this, and lots of things are surprisingly simple once you have some exposure to this type of thing. :)

I can't say that I agree. The video is an hour, and the implementation of the file picker isn't even filling up the entire video. On top of that everything is slower to be implemented in a video than usual. Looking at the amount of work for a completely custom file picker this doesn't strike me as a lot at all. Did you expect us to call a platform file picker dialog window and be done with it?

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.

Emacs ships with functioning LSP nowadays, as does Neovim and (maybe?) Vim, I would use Odin with `ols`: github.com/DanielGavin/ols

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.

Zig is definitely pedantic, I think it's a design goal for sure.

@@mccGoNZooo lol. imagine...

As you probably have understood at this point I'm on hiatus, so I probably won't be making videos on it anytime soon. On top of that I'm definitely not a data structures person and I don't usually find that I have to implement custom ones very often; at least not ones that are much more than arrays in a trench coat, if you catch my drift. We'll see what the future holds, though. :)

@@mccGoNZooo Well, thanks, have fun and hopefully one day we will see you again here.

That's unfortunate. I suggest watching (some of) the videos on a computer monitor; that way you can also write code yourself to get more retention and comprehension from it. Mobile phones or really most non-computer devices aren't very useful in programming, so I would in general suggest not using them for your learning experience.

This is a great topic to cover in the future for sure. I've written my own SQLite bindings, so it wouldn't be new territory in that respect either. We'll see what the future holds; it's definitely a topic worth covering if only to show more FFI stuff in general.