Thanks for listening and thanks for appreciating the choice to make the video. Hopefully the graphics videos can start off with something interesting; I have yet to lay out the plan for exactly how to do it but I'll try to not be away for too long, overplanning it. If nothing else I will under-plan and adjust after instead. :)
That's absolutely awesome that you're working with Matthew! He's a great guy and a huge asset to every community he's a part of. Good luck on the project.
It makes a lot of sense. It's very, very hard to curate a language over time and overall Ginger Bill and the people working on the language have done a great job. You just can't really win them all.
it’s great to hear back from you! congrats on getting a job using odin, definitely a privilege. i can see how the hand made mindset is permeating you 😃
It is 100% a privilege and one that I hope will be given to way more people over time. I want this video and some upcoming ones to perhaps be more of a reason for these positions to be created over time.
I'll weigh in and say that I concur with all of these points. I'll add one point though. Rickard mentions that we code for debugging. Another idea that we have often riffed on is the idea that we optimize for writing code that will go far rather than optimizing for completing features quickly. This leads to the more lines of code and avoiding libraries but the codebase is easy to evolve and extend.
I really do think it's an excellent language choice, and the core + vendor libraries are a great start for working on tons of problems. I saw that you joined the Discord; don't hesitate to ask for help, it's a great place. :)
Honestly, I was still using them, wrote a few and was never really happy with them for the exact reasons mentioned in the video. I just hadn't given up on them yet, because I thought GingerBill is simply smarter than I am and they have to be good for something, maybe they save time in refactoring. But, really, you're better off typing out exactly what you want.
As far as I am concerned you can basically never go wrong with being more specific about which function you want to be calling. Proc groups as a feature really can be boiled down to saving on typing; it's safe to say you can go without it completely. Overall, just trust your gut and do what works for you in the end. Odin is just a tool, we can decide for ourselves how we use it.
Good to hear that it's useful. I'll likely try to make more videos with these updated and more informed opinions, but we'll see exactly how they shape up.
Hey, thanks for sharing your experience. I'm curious about the meta-programming workflow you have. What I gather from what you mentioned here is that it is mostly table generation / type generation to new files. So, any extra info on that you can afford to share would be awesome.
Right, so the purpose of it is that we have code paths that require us to binary serialize data. For this end goal we have a few things: - We have a `shared` package with just types that are shared across application boundaries - These types are strictly defined using basic data types plus slices, arrays and maps - When a package/binary that needs these types is compiled it usually has a pre-build step that runs serialization code generation - Serialization code generation is just a program that reads the `shared` package and spits out functions to serialize/deserialize every type in that package - The result is placed in a file in that very same package, so any package that does need to binary serialize these types will be able to call `shared.type_in_question_write` and `shared.type_in_question_read` with binary slices or returning them - The generated code is strictly imperative code that writes each component part (of a struct, for example) to binaries, or reads them. A `struct` with the fields `a: f64` and `b: string` might have a `struct_name_write` function that basically calls `write_f64(input_binary, struct_value.a, position_in_binary)` and `write_string(input_binary, struct_value.b, position_in_binary)`, for example. - Prior to this solution I had written a solution that relied entirely on reflection and was very, very slow in comparison; generating the code before-hand reduced the runtime of binary serialization by a few thousand times (I don't remember the actual difference, but it was very large)
@@mccGoNZooo Thanks a lot! It feels similar to Rust crate serde, but at optional build step rather than each compile. I've been experimenting with Jai lately, and I've been trying to evaluate how much I'd lose in opportunity if I kept using Odin (as it is the mature option). So far I have 2 mild *possible* usecases: - Linting. I'd like to decorate some of my structs with something like ``@complete`` that would require all of initializations of that to be explicitly complete, as I've burned myself multiple times with unwanted ZII behaviour during refactoring. - Generating extra metadata for some of the game resource structs. Both are kind of mild requirements, that I can probably (or should) ignore. As for macro kind of meta-programming, I'm unsure about them as they make debugging and reasoning harder. Yeah, I don't have any clear conclusion on it and if I were to confess, it unfortunately became a bit analysis paralysis on my side. Thanks again
We have toyed with the idea of creating a linter for special use cases and I do think that Jai (as it was designed/thought up in videos, at least) would be a boon to things like that with its mechanism for intercepting/processing expressions at compile time and being able to emit custom compilation errors based on them. With that said, it's very difficult to hypothesize about that, and I would still basically want to use very static compile-time generation of things. Programs that process things and spit out results are very easy to deal with; much more so than things that live within other execution environments, usually. With regards to macros in a more general sense I've come to sour a lot on these overall: I've used languages like Racket (a Scheme) and Elixir to great effect, but I have to say that macros as a concept are more exciting than they actually are useful in the long run. I think they do a lot for concretizing language design ideas and giving a playground for things like that, but for actual work and things you want to understand for a long time (even with breaks) they are poison.
@@mccGoNZooo Yeah, reading through Jai docs shipped with the compiler, I have similar feelings for that intercept stuff. Thanks a lot for the insight, especially the Scheme part as I lack the lisp experience. Unrelated note, if people are not able to see my comment in between, it looks like YT yet again flagged my comment as spam because it is long. *sigh*
I'm so surprised that you only recently realized the huge value gain of debugging pre-bugs as a sanity check and educational tool. It's basically the only way I could understand programming since I started (and it's also why I continue to suck at web dev). The reason I'm surprised is because you seem more knowledgeable (from having only watched this video) than me in several regards, and I can't imagine how hard it would be for me to learn as much as you must have, without debuggers.
I used C++ from ~2001 to ~2008/2009 and very rarely used debuggers back then (to be honest, I don't think there were particularly good ones, even, and for a large period of time there wasn't even a decent free development environment). At least 75% of that development was done in editors like Jed and Vim. After that I used Python for a couple of years, then Racket, Erlang, Elixir, Haskell, OCaml. Python probably had debuggers at the time, but I didn't know or use any, and the rest of the languages haven't had any decent debugging experiences at all in my experience. Usually what you see from users of those languages is just a lot of pretense about "not needing them". Granted, Erlang/Elixir is very hard to debug when it comes to actual issues because it's inherently a platform where stopping the world for debugging will dramatically alter what will happen in the platform. It kind of *isn't* as useful there. So yeah, the majority of my programming life I have definitely not really used debuggers. I've used debuggers a lot for actual debugging in Zig and Odin the past 4 or so years, but the practice of stepping through programs even before there is anything to debug is indeed a much more recent addition for me.
I'm currently using C a lot to develop tools from scratch, with a similar mindset as you. I don't have that much experience in C, but it is thrilling for me to write in a language where it's very easy to get something where I can predict the disassembly and write fast and simple code with basic knowledge of CPUs. I miss several of the features that I know Odin provides, but I'm a bit afraid of switching because I know how stable C is, and how easy I can debug things in it. But with Odin I have very little idea, and I'm unsure of its tradeoffs in the real world. So given that you're obviously biased toward Odin now: 1) what would you consider the biggest pitfalls or risks of using Odin professionally? In my case, I am the only programmer in my company who is comfortable with system programming, and 2) I'm also wondering if Odin is easier or harder (than C) to understand for programmers who only know C# for instance, which I'm not sure if you can answer. 3) Do you know if Odin natively supports writing a command line program?
1a. One risk with using Odin is that you'll use facilities that are badly or wrongly implemented in the core libraries. We used an encryption function that had a bug and while we found this out pretty easily this was only because the other side was correctly implemented (written in C#). To mitigate this you can simply use C-code from Odin and rely on well-known, stable C libraries but still use Odin yourself. 1b. There is a risk that debugging information is sometimes missing for certain variables when debugging in Linux (this is something I at least had issues with 6+ months ago). It usually isn't *all* variables, but there wasn't much rhyme or reason to what was missing as far as I could see (Coincidentally I had this issue also with Zig on Linux back in ~2020). I've had none of these issues on Windows with Odin. 1c. The core libraries *do* change sometimes, and it can be annoying. This can be mitigated by simply taking over the code that you might want to keep from a previous version; not as big a deal as it might seem. We've done this with one package from the core libraries. 1d. Odin experience won't necessarily be useful for your CV, but I would say that the mitigating factor here is that any Odin user that does real things is gaining tons of C experience, in many ways, so I wouldn't say it's not useful at all. 2. I would bet that it's slightly easier, but it's incredibly difficult to say. If you're using raw malloc + free for allocations it'd definitely be easier just to adopt some of the most basic allocators that you'll find in Odin's core libraries (arena allocators, etc.) and this is not as useful in C code usually because there is no standardization on what a custom allocator is. I also suspect that error handling is just in general an easier concept to grasp in Odin, but it's possible I'm wrong. 3. In terms of making command line apps the actual binary is produced exactly like you'd make it with C (a `main` function and that's it) and you'll find the same basic facilities there. I made a command line argument parser library (github.com/GoNZooo/odin-cli) that'll parse command line arguments into a given type automatically for the purposes of making nice CLI apps. I hope these answers make sense and are at least a little bit illuminating. I tried to not under- or over-sell any of them and be as factual as possible.
I don't use "using" either. I think the only situation where I think it's kinda handy is within a struct, because it's nicer to do "thing.x" instead of "thing.position.x", but I haven't used it enough to know if there are downsides to it. I wish there was a "while" keyword in Odin, thouhg. Just a couple weeks ago I mistakenly copy-pasted the wrong for loop because of that. I like looking at my code and have it be instantly obvious where things are different from each other (iterative loops vs conditional loops).
I have to disagree on the while loops. There’s nothing better IMO than to not have to think about which keyword to use, especially since Odin support 3 different loop kinds. But of course it’s just a preference thing
I could see arguments for either of these and I wouldn't be upset with a decision to add the `while` keyword, just as I'm fine with the status quo. I think part of this also comes down to what you're used to. I think `while` is more identifiable, but obviously only to people who learned that keyword as a formative part of their programming learning process.
@@captainfordo1 Well, considering that... 1 - there's virtually zero brain effort involved in using "while" 2 - there's quite some brain effort and time wasted in having to inspect for loops closer to see which kind they are, rather than them being instantly obvious 3 - the lack of "while" can induce human mistakes, as I mentioned 4 - it makes the code less explicit 5 - "for i < 10" reads weirdly like bad grammar, unlike "while i < 10", which makes logical sense ("for" makes sense in "for i in something") 6 - most people prefer using "while" for conditional loops, as proven by that being the case in C/C++, etc ... then I really don't think you have much of an argument there. The usefulness and logical purpose of "while" isn't trivial.
I wonder how many of these issues could be solved with a better lsp. OLS is pretty great, but I consistently run into major pain points. It crashes with some regularity, and fails to pull up definitions on nested variables. I sometimes code for hours after it crashes, with no issues. Just annoying file searching instead of the go to definition. I have started and stopped working on an lsp for Odin several times over the months I've been the language. I think a better lsp could also help with the proc group situation.
The reason I started looking elsewhere was exactly this; I had a feeling that maybe betting on something else was going to be fruitful. The principle of betting on escalators instead of elevators is sort of more about trying to not use language servers (or rather not language servers alone). We've had a really great experience with our project in IntelliJ so far; it's much, much more stable and hasn't broken down completely on me a single time in several full workdays, which was an impossible thing with VSCode/NeoVim + OLS. I think using *only* LSP is a losing bet in the long run; it's simply not a good bet overall. It's better to bet on something that isn't running some monolithic process that, when it dies or can't start, takes everything else with it.
Shared libraries are a nightmare. Definitely agree on that from a linux perspective but Windows makes me depressed to work on and with so I will make it work :)
I find that the entire landscape for when you want to get things done that aren't very basic CLI apps and so on just is depressing in Linux, and somehow good visual debuggers are just not a thing you can seem to get. With that said, I like using Linux otherwise more, but for native development I just can't pick it over Windows. I think the situation one is in really determines which environment and which tradeoffs one can stomach. I would say Linux seems fine for the vast majority of web dev, for example.
@@mccGoNZooo I think I have stockholm syndrome from my early career. I initially worked on writing security tooling, embedded software and then worked in reverse engineering applications for finding vulnerabilities. Even though I had the opportunity to use tooling such as IDA Pro, I mostly stuck to GDB w plugins and Radare as that was what I used at home because I could not afford IDA. Nowadays, you have Ghidra, Binary Ninja and IDA for paid tooling but back then it was slim pickings. Now that I mostly work in server development and cloud applications, I never really use the UI much for anything and so my workflow is much more comfortable using (n)vim + GDB for writing Go code. Now, if I were doing more graphical intensive work, I would probably pick the Windows ecosystem over linux and port over code as needed. I believe Ginger Bill said it is easier to start on Windows and build for Linux than the other way around.
For using a computer in general I prefer a good terminal + a tiling window manager (XMonad for me) and using terminal applications for most things, but yeah, it really does come down to what is most sensible for the type of development I do and what I want to work on.
I would really love to know WHY LLVM is so slow. As you mentioned parsing and even type checking is so fast so how did they make it orders of magnitude slower to generate assembly. I even asked the forums before and I was dismayed by how little they care about this. So long as the generated output runs fast their happy but they have no regard for how long the user of compiler has to wait to generate the code in the first place.
I think the main work to get around this issue is in a sub-project of Odin dedicated to outputting C (Tilde backend) code instead, which means that you could use that for your debug compilation purposes instead. I think people care, but the truth is that there really isn't any hope of changing LLVM at all, and there never will be. You can only work around it, which is what people are attempting to do.
@@mccGoNZooo that's sad. There's so many big and small projects using it so it's the best use of time to fix the problem at the core so we can all benefit. How they managed to be so slow is probably a very interesting computer science question too.
Are you saying these are problems with Odin's proc groups or the concept of overloading in general? Did you have these problems with other languages? I get the error message is not helpful when an overload couldn't be resolved (you could maybe give more hints if really wanted to) but the alternative is going to back to naming each function with different parameters and I personally didn't like doing that before overloading existed. My experience has been that you figure out pretty easily which overload you want and provide the correct the parameters. Can't say I ever spent much time fighting with overload resolution in any language. EDIT: some more thoughts. :) I remember not like the long variant names when the reading the code too, i.e. "make_xxx" which cluttered things for me. Also remember names become harder for me but those were the days before code completion.
You have to name your procs differently no matter what, a proc group doesn't help you here. It only sets up an overload that can then delegate to whichever of your functions you want to dispatch to. And yes, I think overloading without special constructs is usually a very bad idea.
@@mccGoNZooo are you saying Odin's implementation is worse than say C++? It sounds the same but forces you to be explicit (not sure what that helps with).
@@HairyPixels I am saying that yes, there is no implicit overloading. More importantly I'm also saying that overloading is not a problem worth solving, and solutions to it usually introduce more problems than the non-issue they solve.
I can't promise that it'll be soon, but I'm aiming to do at least something. Like I said in the video, I don't really want to do API-specific things because it's been covered quite extensively via other videos and guides on the Internet.
What were the problems you had with using? It's basically like implicit self in OOP languages where the fields are now part of the current scope so you don't need to do "context.xxxx" when you already know you're "in" the context. If you can reason about non-prefixed functions in global scope it should be just as easy to reason about fields in a procedure scope right?
`using` fundamentally is a basically useless construct. Making things implicit in itself is a generally bad thing, and not the kind of win most people think it is. It optimizes for short-term thinking and makes things harder in the end. I would say that your comparison to C++'s implicit access to member variables is a great one and `using` is bad for exactly the same reasons, except at least it has to be used in a per-function scope so it's not as bad as C++.
I think over time there has been a general consensus that most use cases really do not warrant `using`, yeah. It could definitely be deprecated and disappear over some time without much, if any, loss to most people.
You are one of the reasons why I got into Odin
That's awesome to hear, I hope I can continue doing more of that! :)
I love these "this is my opinion after being in the trenches" insights. Thanks for sharing! I look forward to some Odin graphics content too!
Thanks for listening and thanks for appreciating the choice to make the video. Hopefully the graphics videos can start off with something interesting; I have yet to lay out the plan for exactly how to do it but I'll try to not be away for too long, overplanning it. If nothing else I will under-plan and adjust after instead. :)
That's absolutely awesome that you're working with Matthew! He's a great guy and a huge asset to every community he's a part of. Good luck on the project.
Matthew is indeed fantastic and has been a key part in how great this experience has been! :)
When the the Primeagen asked Ginger Bill what he go wrong in Odin the first thing he said was the using statement.
It makes a lot of sense. It's very, very hard to curate a language over time and overall Ginger Bill and the people working on the language have done a great job. You just can't really win them all.
Glad you're back :)
Happy to be back, and happy to be back with something I think could be useful and good news! :)
it’s great to hear back from you! congrats on getting a job using odin, definitely a privilege. i can see how the hand made mindset is permeating you 😃
It is 100% a privilege and one that I hope will be given to way more people over time. I want this video and some upcoming ones to perhaps be more of a reason for these positions to be created over time.
I'll weigh in and say that I concur with all of these points. I'll add one point though. Rickard mentions that we code for debugging. Another idea that we have often riffed on is the idea that we optimize for writing code that will go far rather than optimizing for completing features quickly. This leads to the more lines of code and avoiding libraries but the codebase is easy to evolve and extend.
Awesome video! I am thinking about get into Odin, good to see this report :)
I really do think it's an excellent language choice, and the core + vendor libraries are a great start for working on tons of problems. I saw that you joined the Discord; don't hesitate to ask for help, it's a great place. :)
@@mccGoNZooo Thank you!
100% agree with the proc groups, the compiler errors don’t make sense
I knew I couldn't be the only one that's had these issues. :D
Honestly, I was still using them, wrote a few and was never really happy with them for the exact reasons mentioned in the video. I just hadn't given up on them yet, because I thought GingerBill is simply smarter than I am and they have to be good for something, maybe they save time in refactoring. But, really, you're better off typing out exactly what you want.
As far as I am concerned you can basically never go wrong with being more specific about which function you want to be calling. Proc groups as a feature really can be boiled down to saving on typing; it's safe to say you can go without it completely.
Overall, just trust your gut and do what works for you in the end. Odin is just a tool, we can decide for ourselves how we use it.
ty for your feedback and info, it is valuable
Good to hear that it's useful. I'll likely try to make more videos with these updated and more informed opinions, but we'll see exactly how they shape up.
Well, this should be an interesting watch...🍿😊
Hey, thanks for sharing your experience. I'm curious about the meta-programming workflow you have. What I gather from what you mentioned here is that it is mostly table generation / type generation to new files. So, any extra info on that you can afford to share would be awesome.
Right, so the purpose of it is that we have code paths that require us to binary serialize data. For this end goal we have a few things:
- We have a `shared` package with just types that are shared across application boundaries
- These types are strictly defined using basic data types plus slices, arrays and maps
- When a package/binary that needs these types is compiled it usually has a pre-build step that runs serialization code generation
- Serialization code generation is just a program that reads the `shared` package and spits out functions to serialize/deserialize every type in that package
- The result is placed in a file in that very same package, so any package that does need to binary serialize these types will be able to call `shared.type_in_question_write` and `shared.type_in_question_read` with binary slices or returning them
- The generated code is strictly imperative code that writes each component part (of a struct, for example) to binaries, or reads them. A `struct` with the fields `a: f64` and `b: string` might have a `struct_name_write` function that basically calls `write_f64(input_binary, struct_value.a, position_in_binary)` and `write_string(input_binary, struct_value.b, position_in_binary)`, for example.
- Prior to this solution I had written a solution that relied entirely on reflection and was very, very slow in comparison; generating the code before-hand reduced the runtime of binary serialization by a few thousand times (I don't remember the actual difference, but it was very large)
@@mccGoNZooo Thanks a lot! It feels similar to Rust crate serde, but at optional build step rather than each compile. I've been experimenting with Jai lately, and I've been trying to evaluate how much I'd lose in opportunity if I kept using Odin (as it is the mature option). So far I have 2 mild *possible* usecases:
- Linting. I'd like to decorate some of my structs with something like ``@complete`` that would require all of initializations of that to be explicitly complete, as I've burned myself multiple times with unwanted ZII behaviour during refactoring.
- Generating extra metadata for some of the game resource structs.
Both are kind of mild requirements, that I can probably (or should) ignore. As for macro kind of meta-programming, I'm unsure about them as they make debugging and reasoning harder. Yeah, I don't have any clear conclusion on it and if I were to confess, it unfortunately became a bit analysis paralysis on my side. Thanks again
We have toyed with the idea of creating a linter for special use cases and I do think that Jai (as it was designed/thought up in videos, at least) would be a boon to things like that with its mechanism for intercepting/processing expressions at compile time and being able to emit custom compilation errors based on them. With that said, it's very difficult to hypothesize about that, and I would still basically want to use very static compile-time generation of things. Programs that process things and spit out results are very easy to deal with; much more so than things that live within other execution environments, usually.
With regards to macros in a more general sense I've come to sour a lot on these overall: I've used languages like Racket (a Scheme) and Elixir to great effect, but I have to say that macros as a concept are more exciting than they actually are useful in the long run. I think they do a lot for concretizing language design ideas and giving a playground for things like that, but for actual work and things you want to understand for a long time (even with breaks) they are poison.
@@mccGoNZooo Yeah, reading through Jai docs shipped with the compiler, I have similar feelings for that intercept stuff. Thanks a lot for the insight, especially the Scheme part as I lack the lisp experience. Unrelated note, if people are not able to see my comment in between, it looks like YT yet again flagged my comment as spam because it is long. *sigh*
For what it's worth I have no held comments in my comments on this video and I received your latest one 9 minutes ago at the time of writing.
I'm so surprised that you only recently realized the huge value gain of debugging pre-bugs as a sanity check and educational tool. It's basically the only way I could understand programming since I started (and it's also why I continue to suck at web dev). The reason I'm surprised is because you seem more knowledgeable (from having only watched this video) than me in several regards, and I can't imagine how hard it would be for me to learn as much as you must have, without debuggers.
I used C++ from ~2001 to ~2008/2009 and very rarely used debuggers back then (to be honest, I don't think there were particularly good ones, even, and for a large period of time there wasn't even a decent free development environment). At least 75% of that development was done in editors like Jed and Vim.
After that I used Python for a couple of years, then Racket, Erlang, Elixir, Haskell, OCaml. Python probably had debuggers at the time, but I didn't know or use any, and the rest of the languages haven't had any decent debugging experiences at all in my experience. Usually what you see from users of those languages is just a lot of pretense about "not needing them".
Granted, Erlang/Elixir is very hard to debug when it comes to actual issues because it's inherently a platform where stopping the world for debugging will dramatically alter what will happen in the platform. It kind of *isn't* as useful there.
So yeah, the majority of my programming life I have definitely not really used debuggers. I've used debuggers a lot for actual debugging in Zig and Odin the past 4 or so years, but the practice of stepping through programs even before there is anything to debug is indeed a much more recent addition for me.
I'm currently using C a lot to develop tools from scratch, with a similar mindset as you. I don't have that much experience in C, but it is thrilling for me to write in a language where it's very easy to get something where I can predict the disassembly and write fast and simple code with basic knowledge of CPUs. I miss several of the features that I know Odin provides, but I'm a bit afraid of switching because I know how stable C is, and how easy I can debug things in it. But with Odin I have very little idea, and I'm unsure of its tradeoffs in the real world. So given that you're obviously biased toward Odin now: 1) what would you consider the biggest pitfalls or risks of using Odin professionally?
In my case, I am the only programmer in my company who is comfortable with system programming, and 2) I'm also wondering if Odin is easier or harder (than C) to understand for programmers who only know C# for instance, which I'm not sure if you can answer.
3) Do you know if Odin natively supports writing a command line program?
1a. One risk with using Odin is that you'll use facilities that are badly or wrongly implemented in the core libraries. We used an encryption function that had a bug and while we found this out pretty easily this was only because the other side was correctly implemented (written in C#). To mitigate this you can simply use C-code from Odin and rely on well-known, stable C libraries but still use Odin yourself.
1b. There is a risk that debugging information is sometimes missing for certain variables when debugging in Linux (this is something I at least had issues with 6+ months ago). It usually isn't *all* variables, but there wasn't much rhyme or reason to what was missing as far as I could see (Coincidentally I had this issue also with Zig on Linux back in ~2020). I've had none of these issues on Windows with Odin.
1c. The core libraries *do* change sometimes, and it can be annoying. This can be mitigated by simply taking over the code that you might want to keep from a previous version; not as big a deal as it might seem. We've done this with one package from the core libraries.
1d. Odin experience won't necessarily be useful for your CV, but I would say that the mitigating factor here is that any Odin user that does real things is gaining tons of C experience, in many ways, so I wouldn't say it's not useful at all.
2. I would bet that it's slightly easier, but it's incredibly difficult to say. If you're using raw malloc + free for allocations it'd definitely be easier just to adopt some of the most basic allocators that you'll find in Odin's core libraries (arena allocators, etc.) and this is not as useful in C code usually because there is no standardization on what a custom allocator is. I also suspect that error handling is just in general an easier concept to grasp in Odin, but it's possible I'm wrong.
3. In terms of making command line apps the actual binary is produced exactly like you'd make it with C (a `main` function and that's it) and you'll find the same basic facilities there. I made a command line argument parser library (github.com/GoNZooo/odin-cli) that'll parse command line arguments into a given type automatically for the purposes of making nice CLI apps.
I hope these answers make sense and are at least a little bit illuminating. I tried to not under- or over-sell any of them and be as factual as possible.
I don't use "using" either. I think the only situation where I think it's kinda handy is within a struct, because it's nicer to do "thing.x" instead of "thing.position.x", but I haven't used it enough to know if there are downsides to it.
I wish there was a "while" keyword in Odin, thouhg. Just a couple weeks ago I mistakenly copy-pasted the wrong for loop because of that. I like looking at my code and have it be instantly obvious where things are different from each other (iterative loops vs conditional loops).
I wouldn't say no to a `while` keywords, because it would make things more glancable, as you alluded to.
I have to disagree on the while loops. There’s nothing better IMO than to not have to think about which keyword to use, especially since Odin support 3 different loop kinds. But of course it’s just a preference thing
I could see arguments for either of these and I wouldn't be upset with a decision to add the `while` keyword, just as I'm fine with the status quo. I think part of this also comes down to what you're used to. I think `while` is more identifiable, but obviously only to people who learned that keyword as a formative part of their programming learning process.
@@captainfordo1 Well, considering that...
1 - there's virtually zero brain effort involved in using "while"
2 - there's quite some brain effort and time wasted in having to inspect for loops closer to see which kind they are, rather than them being instantly obvious
3 - the lack of "while" can induce human mistakes, as I mentioned
4 - it makes the code less explicit
5 - "for i < 10" reads weirdly like bad grammar, unlike "while i < 10", which makes logical sense ("for" makes sense in "for i in something")
6 - most people prefer using "while" for conditional loops, as proven by that being the case in C/C++, etc
... then I really don't think you have much of an argument there. The usefulness and logical purpose of "while" isn't trivial.
I wonder how many of these issues could be solved with a better lsp. OLS is pretty great, but I consistently run into major pain points. It crashes with some regularity, and fails to pull up definitions on nested variables. I sometimes code for hours after it crashes, with no issues. Just annoying file searching instead of the go to definition.
I have started and stopped working on an lsp for Odin several times over the months I've been the language. I think a better lsp could also help with the proc group situation.
The reason I started looking elsewhere was exactly this; I had a feeling that maybe betting on something else was going to be fruitful. The principle of betting on escalators instead of elevators is sort of more about trying to not use language servers (or rather not language servers alone). We've had a really great experience with our project in IntelliJ so far; it's much, much more stable and hasn't broken down completely on me a single time in several full workdays, which was an impossible thing with VSCode/NeoVim + OLS.
I think using *only* LSP is a losing bet in the long run; it's simply not a good bet overall. It's better to bet on something that isn't running some monolithic process that, when it dies or can't start, takes everything else with it.
the "len arg is missing" thing is probably a compiler bug
Thanks for clarifying, I actually wasn't really sure if I was the one misunderstanding something or what was going on.
Shared libraries are a nightmare. Definitely agree on that from a linux perspective but Windows makes me depressed to work on and with so I will make it work :)
I find that the entire landscape for when you want to get things done that aren't very basic CLI apps and so on just is depressing in Linux, and somehow good visual debuggers are just not a thing you can seem to get. With that said, I like using Linux otherwise more, but for native development I just can't pick it over Windows. I think the situation one is in really determines which environment and which tradeoffs one can stomach. I would say Linux seems fine for the vast majority of web dev, for example.
@@mccGoNZooo I think I have stockholm syndrome from my early career. I initially worked on writing security tooling, embedded software and then worked in reverse engineering applications for finding vulnerabilities. Even though I had the opportunity to use tooling such as IDA Pro, I mostly stuck to GDB w plugins and Radare as that was what I used at home because I could not afford IDA. Nowadays, you have Ghidra, Binary Ninja and IDA for paid tooling but back then it was slim pickings. Now that I mostly work in server development and cloud applications, I never really use the UI much for anything and so my workflow is much more comfortable using (n)vim + GDB for writing Go code.
Now, if I were doing more graphical intensive work, I would probably pick the Windows ecosystem over linux and port over code as needed. I believe Ginger Bill said it is easier to start on Windows and build for Linux than the other way around.
For using a computer in general I prefer a good terminal + a tiling window manager (XMonad for me) and using terminal applications for most things, but yeah, it really does come down to what is most sensible for the type of development I do and what I want to work on.
I would really love to know WHY LLVM is so slow. As you mentioned parsing and even type checking is so fast so how did they make it orders of magnitude slower to generate assembly. I even asked the forums before and I was dismayed by how little they care about this. So long as the generated output runs fast their happy but they have no regard for how long the user of compiler has to wait to generate the code in the first place.
I think the main work to get around this issue is in a sub-project of Odin dedicated to outputting C (Tilde backend) code instead, which means that you could use that for your debug compilation purposes instead. I think people care, but the truth is that there really isn't any hope of changing LLVM at all, and there never will be. You can only work around it, which is what people are attempting to do.
@@mccGoNZooo that's sad. There's so many big and small projects using it so it's the best use of time to fix the problem at the core so we can all benefit. How they managed to be so slow is probably a very interesting computer science question too.
which vscode color theme is this?
It's a theme I made, you can find it in the extension marketplace with the name "Aurora GoNZooo".
@@mccGoNZooo thanks
Are you saying these are problems with Odin's proc groups or the concept of overloading in general? Did you have these problems with other languages? I get the error message is not helpful when an overload couldn't be resolved (you could maybe give more hints if really wanted to) but the alternative is going to back to naming each function with different parameters and I personally didn't like doing that before overloading existed. My experience has been that you figure out pretty easily which overload you want and provide the correct the parameters. Can't say I ever spent much time fighting with overload resolution in any language.
EDIT: some more thoughts. :) I remember not like the long variant names when the reading the code too, i.e. "make_xxx" which cluttered things for me. Also remember names become harder for me but those were the days before code completion.
You have to name your procs differently no matter what, a proc group doesn't help you here. It only sets up an overload that can then delegate to whichever of your functions you want to dispatch to.
And yes, I think overloading without special constructs is usually a very bad idea.
@@mccGoNZooo are you saying Odin's implementation is worse than say C++? It sounds the same but forces you to be explicit (not sure what that helps with).
@@HairyPixels I am saying that yes, there is no implicit overloading. More importantly I'm also saying that overloading is not a problem worth solving, and solutions to it usually introduce more problems than the non-issue they solve.
@@mccGoNZooo Explicit vs implicit behavior has a very strong reaction with some programers. It's all very interesting to me, thanks for sharing.
Looking forward to the graphics stuff. Great deep dive btw
I can't promise that it'll be soon, but I'm aiming to do at least something. Like I said in the video, I don't really want to do API-specific things because it's been covered quite extensively via other videos and guides on the Internet.
What were the problems you had with using? It's basically like implicit self in OOP languages where the fields are now part of the current scope so you don't need to do "context.xxxx" when you already know you're "in" the context. If you can reason about non-prefixed functions in global scope it should be just as easy to reason about fields in a procedure scope right?
`using` fundamentally is a basically useless construct. Making things implicit in itself is a generally bad thing, and not the kind of win most people think it is. It optimizes for short-term thinking and makes things harder in the end. I would say that your comparison to C++'s implicit access to member variables is a great one and `using` is bad for exactly the same reasons, except at least it has to be used in a per-function scope so it's not as bad as C++.
I hate that feature of OOP languages and always use “this->” in C++
I feel like using should be phased out. Usually the advice even in discord is don't use it.
I think over time there has been a general consensus that most use cases really do not warrant `using`, yeah. It could definitely be deprecated and disappear over some time without much, if any, loss to most people.
Grug brained development
100%, I was actually thinking about mentioning that by name while talking about this; it's been a great inspiration to me for some time.