I just started “Build Your Own Text Editor”[0], but using Odin instead of C. So far, I’m impressed with Odin. It’s the most ergonomic C replacement I’ve tried. I wish it had been around 25 years ago when I was professionally working with unmanaged code.
As being able to use a language to write an editor is a personal must-have in a language, your mention of kilo caught my eye. I did a quick read through of the Odin overview and FAQ and my initial impressions are positive. Bonus points to them for multiple return values and no automatic fallthrough on switch.
Have you tried zig? I'm casually looking for a C replacement and I took a quick look at zig but came away not liking the community vibe (some things were too dictatorial for my tastes).
If you did anything with zig, how would you say the languages compare?
Zig's compiler error on unused variables is a deal breaker for me unfortunately. The language author also has an insulting attitude towards anyone who wants otherwise, categorizing them as bad programmers he doesn't want to work with and doesn't want using Zig.
The compiler error on variables which are mutable when could be const is almost as annoying. Zig does not acknowledge that not all code is production code, that sometimes you want to prototype without having to backtrack and fix compiler errors to irrelevant things when the goal is prototyping and figuring out what you are building.
It also adds friction to learning the language because statements you write will immediately get flagged as wrong -- is it actually wrong due to your unfamiliarity with the language, or is it just the lsp immediately flagging and underlining all unused as red. Better take a moment to check.
Super annoying to me. I can't get past it, nor do I trust the author of Zig to not go even further in this direction. He has made it clear he will not compromise on this issue.
There are more planned similar errors on the way here. At least it looks like they are no loner planning to do compiler errors on unused pub functions if they are not accessible from outside the package.
Zig: Trust the programmer to manually manage memory, but not to clean up unused variables.
The language is weirdly pedantic, in ways orthogonal to Rust.
> Zig: Trust the programmer to manually manage memory, but not to clean up unused variables.
That's such a good tagline, actually one of the things that annoyed me with zig as well. The other one is the lack of attention to syntax aesthetics and ergonomics, it's a bit all over the place and I am also not fond of semicolons.
Go refuses variables that are declared and not used as well.
And honestly, I like the fact that it forces the source code to not include bloat. Lines of code that are there, but don't do anything, and can be misleading.
And in Zig, the language server can be configured to automatically add and remove `_ = variable;` statements, so this is frictionless.
>Odin’s creator has some strong opinions around not prioritizing LSPs and QoL tools around Odin.
no, he does not. He just doesn't use LSP but never did he ever oppose QoL tools.
Odin has great support for LSP and they are working on other tools as well. Do note that Odin doesn't have a foundation like Rust or Zig so their pace of development will be at their own discretion. Please don't expect it to be similar to Zig or other well funded languages.
I recall a thread from a few years ago where people were saying that zig had better LSO support than Odin and saying that Odin should prioritize that more.
I recall gingerBill saying that he’d rather work on the language than adoption. Which is a fine position to have.
Never did I say he was morally against LSPs or anything, just that he has strong opinions on prioritizing its development vs the language itself.
Please don’t put words in my mouth. I’m trying to be very clear.
The Odin lsp I found (ols) is not official and not made by gingerBill. Which, again, is fine. It’s good that the community took up the burden of making an LSP.
>Please don’t put words in my mouth. I’m trying to be very clear.
my bad then
>The Odin lsp I found (ols) is not official and not made by gingerBill. Which, again, is fine
Ginger Bill is just the creator of the language. He is already hands full with the front end and back end of the language alone. You pointing out "its fine" makes it seem like you expect him to work on LSP, web site, marketing and everything else all by himself, which he can't and I personally think he won't. LSP is a big mess and it is alright to not prioritize LSP and focus on working on the core language itself, especially if marketing is not a serious concern.
> no, he does not. He just doesn't use LSP but never did he ever oppose QoL tools.
He's somewhat against package managers (doesn't want Odin ecosystem turning into NPM or Crates.io where a single package draws in a thousand dependencies).
But yeah, Odin's LSP is used by most Odin users, including staff at JangaFX.
Its not just the dependencies bloatware, there is also an issue of accidentally pulling in a GLP license code base and several others. But if one wishes to make a package manager for Odin, they can do so and other Odin users may use it if they found it to be really helpful but from what I know, Ginger Bill will never officially support it as it doesn't align with his vision of the language.
If your goal is viral adoption, I agree, but it sounds like Odin is kind of geared towards the graphics programming world and doesn’t require vitality at this stage.
Odin does have a pretty nice "package management" story. You can literally just throw a folder with Odin files into your project structure and it "just works". The compiler sees it and includes it automatically.
I don't hate cargo either, I've also used Ruby for years, gem is nice, but in both ecosystems there's also a ton of abandoned packages, some that haven't been touched in years...
No, the "C community" and creators aren't making a political stance on things at all. Lua doesn't either. The Zig creator is very outspoken on political matters.
Not making a political stance is implicitly embracing the status quo. That’s usually fine because most hot political issues are far away from programming language design and implementation. Others feel differently, that political issues which affect community members (or people who could become community members) are important to speak out on. Regardless, every community takes political stances, some are just more upfront about it
I love Odin, and I'm glad to see it getting more attention. I've been working through Dave Churchill's COMP 4300 course[0] in Odin/Raylib rather than C++/SFML, and it's been a blast.
Flipped through the language overview on the website and noticed that matrices are limited in how large they can be because they're stack allocated [1]. Ergonomics of the language otherwise look solid but for my use case that would be fairly constraining
Matrices, like any other primitive data type, are stack-allocated. Do you want matrices to be allocated on the heap? If you're looking to do Pandas-style data science, you'd have to write your own implementation, where you could adjust for exactly how you want to do the multiplication. The builtin matrices are typically pretty small (~4x4 or 3x3), a very common use case in graphics or games programming.
It looks like some borrowed Go convention, where package statements don't need to be quoted, but import statements may include URLs and, therefore, they are expected to be quoted.
Any reading recommendations for introduction to the fundamentals of manual memory management specifically? I tried learning C in the past but didn’t get very far without a compelling need to learn it.
I’ve toyed with Odin a bit and the language in syntax is right up my alley, but the idea of manually managing memory is pretty foreign to me. I understand it broadly, but have no good idea about how to actually do it practically and properly.
I will give this book a look as well since I see it covers the topic in some chapters.
Odin has a builtin heap allocator that works the same way you would expect any other high-level language to do memory allocation–it's just that you have to free the memory yourself. Plus, Odin's built in `context` system makes it really easy to change what kind of allocator is used for different sections of code. For my use cases, I've never needed any more than a heap and an arena, detailed in this talk:
Personally, my large Odin project uses a series of arrays to store specific data, and then everything else is stored in a temporary allocator, which is wiped between frames. Besides some graphics initialization & path resolution at initialization time, the heap allocator is never used. I never really have to worry about memory. That's similar to the design detailed in this talk by Ryan Fluery:
Odin also has a tracking allocator which can be used to check for leaks or double frees. In debug mode, my program will print out all un-freed memory left after shutdown. If you're working outside of Odin, I've heard good things about Valgrind for C/C++:
Curious, why? I hate pdfs because of their fixed size. Whatever device I happen to use to view a pdf, it's always got a different size than I'd like... either too large (ok I can fix that by zooming out!), wrong proportions, or too small...
I like that it looks like the print book. I have dual screen and when it comes to tech books. I few the pdf fullscreen on one monitor while trying things out actively on another. when I'm on the go, it looks great on a ipad.
for novels where I'm reading for story, I use a kindle but for textbooks, I strongly prefer pdf
While not a first class solution, the EPUB version of the book converts to PDF fairly well (I'm not noticing anything wrong). There are plenty of tools to do so.
I believe the issue is that things are not properly formatted, and does not look as good as it could. For text-only, EPUB is fine, otherwise I would rather prefer PDF, too.
It may not be precise in its details but it's a very accessible explanation that's certainly "good enough." Maybe you could swap it in for "non-whole numbers" and still be reasonably accessible, but that's also not perfectly accurate since integers are stored just fine inside a float.
I'm certainly not going to fault them for using layman terms when addressing laymen.
Ideally for this work you want somebody who is capable of communicating in a way that doesn't feel dumbed down and yet also isn't actively wrong. This explanation of the floating point types does not hit that mark. I'm not in the market for an Odin book, so in some sense it doesn't matter what I think, but across fields it's better if what you're saying is able to both serve its immediate purpose and actually true.
People are going to remember (some of) what you taught them and even if it felt peripheral at the time they may have centred it. When they return to this teaching again, it's not surprising that they assume you meant what you said, even if in your mind it was figurative or targeted at a superficial understanding of the subject.
Decimal representations do exist in machines. Representations that can manage 1.2 exactly but can't handle a third, or pi, or the square root of 2 for example. But the floating point numbers aren't that, they're a weird (but useful) binary fraction and if we're going to mention them at all we need to make it clear what's going on here.
For example the "float" (32-bit IEEE floating point type) called 1.2 is actually 5033165 divided by 4194304 which isn't actually six over five (1.2) but it's pretty close.
I agree with OP that it's unnecessarily confusing. A "method" is a procedure. The floating point number is the result of that procedure, not the procedure itself.
"Decimal" implies a ten based system, even though it's perfectly fine to say "binary decimal".
Using your own replacement words, it would be clearer to write "A floating point number is a representation of a number with a fractional part".
Maybe it should've said "is a method of storing" instead of "for". It would make it clear it's not talking about a procedure, but a way or manner of doing something.
Maybe OP reacted because a float only looks like it is a way to store decimal numbers, when it's only an approximation of decimal numbers. If you really need decimal numbers you need something like mpmath¹.
As a shorthand to explain what a float is to someone, "a decimal number" is an OK start though.
But sometimes that approximation breaks down even for simple examples, i.e. 0.1 cannot be represented as a float. This can be quite unexpected if your mental model is that "floats are decimal numbers with a certain precision".
AI coding assistants are closing the door. They need a lot of training data to be good and useful.
Established programming languages have a tremendous amount of that, so AI coding agents will do a good job there. C, PHP, Python, Java, etc.
Garden variety and new programming languages have much less examples in the wild, so AI assistants will do a lesser job with those, unless their lineage leads to one of the established languages.
Finally, the bulk of future developers will be lured to AI assisted coding and therefore won’t generate much training data for new programming languages.
A vicious circle.
All of the above is speculation on my part, obviously.
Maybe AI assistants will get smart enough to master languages they have not been trained on.
I just started “Build Your Own Text Editor”[0], but using Odin instead of C. So far, I’m impressed with Odin. It’s the most ergonomic C replacement I’ve tried. I wish it had been around 25 years ago when I was professionally working with unmanaged code.
[0] https://viewsourcecode.org/snaptoken/kilo/index.html
As being able to use a language to write an editor is a personal must-have in a language, your mention of kilo caught my eye. I did a quick read through of the Odin overview and FAQ and my initial impressions are positive. Bonus points to them for multiple return values and no automatic fallthrough on switch.
Have you tried zig? I'm casually looking for a C replacement and I took a quick look at zig but came away not liking the community vibe (some things were too dictatorial for my tastes).
If you did anything with zig, how would you say the languages compare?
Odin and Zig both have dictators.
Both are very nice people as long as you’re nice yourself, imo.
My opinions:
Odin’s creator has some strong opinions around not prioritizing LSPs and QoL tools around Odin.
Zig’s is a little more hard nosed about simplicity. Zig is a very small language for a reason.
I’m on my zig arc now, but Odin is next.
Zig's compiler error on unused variables is a deal breaker for me unfortunately. The language author also has an insulting attitude towards anyone who wants otherwise, categorizing them as bad programmers he doesn't want to work with and doesn't want using Zig.
The compiler error on variables which are mutable when could be const is almost as annoying. Zig does not acknowledge that not all code is production code, that sometimes you want to prototype without having to backtrack and fix compiler errors to irrelevant things when the goal is prototyping and figuring out what you are building.
It also adds friction to learning the language because statements you write will immediately get flagged as wrong -- is it actually wrong due to your unfamiliarity with the language, or is it just the lsp immediately flagging and underlining all unused as red. Better take a moment to check.
Super annoying to me. I can't get past it, nor do I trust the author of Zig to not go even further in this direction. He has made it clear he will not compromise on this issue.
There are more planned similar errors on the way here. At least it looks like they are no loner planning to do compiler errors on unused pub functions if they are not accessible from outside the package.
Zig: Trust the programmer to manually manage memory, but not to clean up unused variables.
The language is weirdly pedantic, in ways orthogonal to Rust.
> Zig: Trust the programmer to manually manage memory, but not to clean up unused variables.
That's such a good tagline, actually one of the things that annoyed me with zig as well. The other one is the lack of attention to syntax aesthetics and ergonomics, it's a bit all over the place and I am also not fond of semicolons.
The worst part is if you have an unused variable the compiler won't even show you the real errors until you fix all the warnings first.
> Compile error: This variable of type `Foo` is unused
Ok then, I'll just remove that, and...
> Compile error: This function you're calling expects an argument of type `Foo`
Just kill me.
Go refuses variables that are declared and not used as well.
And honestly, I like the fact that it forces the source code to not include bloat. Lines of code that are there, but don't do anything, and can be misleading.
And in Zig, the language server can be configured to automatically add and remove `_ = variable;` statements, so this is frictionless.
"Let me comment this line out"
"Oh and I have to do this one too"
"Oh and this five as well"
"Almost there"
"Nope"
>Odin’s creator has some strong opinions around not prioritizing LSPs and QoL tools around Odin.
no, he does not. He just doesn't use LSP but never did he ever oppose QoL tools.
Odin has great support for LSP and they are working on other tools as well. Do note that Odin doesn't have a foundation like Rust or Zig so their pace of development will be at their own discretion. Please don't expect it to be similar to Zig or other well funded languages.
I recall a thread from a few years ago where people were saying that zig had better LSO support than Odin and saying that Odin should prioritize that more.
I recall gingerBill saying that he’d rather work on the language than adoption. Which is a fine position to have.
Never did I say he was morally against LSPs or anything, just that he has strong opinions on prioritizing its development vs the language itself.
Please don’t put words in my mouth. I’m trying to be very clear.
The Odin lsp I found (ols) is not official and not made by gingerBill. Which, again, is fine. It’s good that the community took up the burden of making an LSP.
> The Odin lsp I found (ols) is not official and not made by gingerBill
FWIW it's the same for Zig. ZLS is not official and not made by andrewrk.
>Please don’t put words in my mouth. I’m trying to be very clear.
my bad then
>The Odin lsp I found (ols) is not official and not made by gingerBill. Which, again, is fine
Ginger Bill is just the creator of the language. He is already hands full with the front end and back end of the language alone. You pointing out "its fine" makes it seem like you expect him to work on LSP, web site, marketing and everything else all by himself, which he can't and I personally think he won't. LSP is a big mess and it is alright to not prioritize LSP and focus on working on the core language itself, especially if marketing is not a serious concern.
Again, please don’t put words in my mouth. That’s what both your comments are doing.
For example: > You pointing out "its fine" makes it seem like you expect him to work on LSP, web site, marketing and everything else all by himself
How you extrapolated all that from me saying “it’s fine” is beyond me.
I’m not here to argue, just to state my opinion that both language creators are pretty nice people with some particular opinions.
I literally said that it’s fine that ols is community made. I even said it’s good that the community is willing to put in that work.
I also passed no judgement on his choice to not prioritize an LSP.
Take your outrage elsewhere, please.
honestly, that sounds like a 'normal' opinion, not a strong one.
I don’t mean strong as in weird and out there.
I mean strong as in I don’t believe his opinion will be easily swayed.
> no, he does not. He just doesn't use LSP but never did he ever oppose QoL tools.
He's somewhat against package managers (doesn't want Odin ecosystem turning into NPM or Crates.io where a single package draws in a thousand dependencies).
But yeah, Odin's LSP is used by most Odin users, including staff at JangaFX.
>He's somewhat against package managers
yes and that is a design decision.
Its not just the dependencies bloatware, there is also an issue of accidentally pulling in a GLP license code base and several others. But if one wishes to make a package manager for Odin, they can do so and other Odin users may use it if they found it to be really helpful but from what I know, Ginger Bill will never officially support it as it doesn't align with his vision of the language.
Not prioritizing tools is a mistake imho. I'd argue it helps a lot with adoption and you end up with useful tools.
Odin actually has a pretty great LSP already.
If your goal is viral adoption, I agree, but it sounds like Odin is kind of geared towards the graphics programming world and doesn’t require vitality at this stage.
Odin has a great LSP.
Gingerbill is mainly against package managers because ecosystems like NPM and Crates.io are a mess...
They are a beautiful mess. crates is actually fantastic. Being anti package management is very unproductive. It's gross but it's super productive
Odin does have a pretty nice "package management" story. You can literally just throw a folder with Odin files into your project structure and it "just works". The compiler sees it and includes it automatically.
I don't hate cargo either, I've also used Ruby for years, gem is nice, but in both ecosystems there's also a ton of abandoned packages, some that haven't been touched in years...
The Zig-community is annoyingly political, whereas the Odin community and -creator focuses on technology.
There's no community in the world that isn't political. Perhaps the issue is actually just that you disagree with the politics that are popular there?
No, the "C community" and creators aren't making a political stance on things at all. Lua doesn't either. The Zig creator is very outspoken on political matters.
Not making a political stance is implicitly embracing the status quo. That’s usually fine because most hot political issues are far away from programming language design and implementation. Others feel differently, that political issues which affect community members (or people who could become community members) are important to speak out on. Regardless, every community takes political stances, some are just more upfront about it
How is the Zig community political? I use the language but I’m not involved with the community at all.
Just follow Andrew Kelley on whatever platform he hasn't ragequit from these days.
I love Odin, and I'm glad to see it getting more attention. I've been working through Dave Churchill's COMP 4300 course[0] in Odin/Raylib rather than C++/SFML, and it's been a blast.
[0] https://www.youtube.com/playlist?list=PL_xRyXins84_Sq7yZkxGP...
Flipped through the language overview on the website and noticed that matrices are limited in how large they can be because they're stack allocated [1]. Ergonomics of the language otherwise look solid but for my use case that would be fairly constraining
[1] https://odin-lang.org/docs/overview/#technical-information-o...
Matrices, like any other primitive data type, are stack-allocated. Do you want matrices to be allocated on the heap? If you're looking to do Pandas-style data science, you'd have to write your own implementation, where you could adjust for exactly how you want to do the multiplication. The builtin matrices are typically pretty small (~4x4 or 3x3), a very common use case in graphics or games programming.
Looks like this is implemented with LLVM's builtin matrix type, also available as a Clang extension: https://clang.llvm.org/docs/MatrixTypes.html
This looks really nice and the prose had a positive/easy-going feel to it.
When the actual code examples begin, the very first couple of lines confused me:
Is the quoting of package names optional?It looks like some borrowed Go convention, where package statements don't need to be quoted, but import statements may include URLs and, therefore, they are expected to be quoted.
Based on the official website[0], it would appear the package name is necessarily not quoted.
This doesn't strike me as odd at all. It's an identifier, not a string. The quoting of the import, on the other hand...
[0] https://odin-lang.org/docs/overview/
Any reading recommendations for introduction to the fundamentals of manual memory management specifically? I tried learning C in the past but didn’t get very far without a compelling need to learn it.
I’ve toyed with Odin a bit and the language in syntax is right up my alley, but the idea of manually managing memory is pretty foreign to me. I understand it broadly, but have no good idea about how to actually do it practically and properly.
I will give this book a look as well since I see it covers the topic in some chapters.
Odin has a builtin heap allocator that works the same way you would expect any other high-level language to do memory allocation–it's just that you have to free the memory yourself. Plus, Odin's built in `context` system makes it really easy to change what kind of allocator is used for different sections of code. For my use cases, I've never needed any more than a heap and an arena, detailed in this talk:
https://www.youtube.com/watch?v=nZNd5FjSquk
Personally, my large Odin project uses a series of arrays to store specific data, and then everything else is stored in a temporary allocator, which is wiped between frames. Besides some graphics initialization & path resolution at initialization time, the heap allocator is never used. I never really have to worry about memory. That's similar to the design detailed in this talk by Ryan Fluery:
https://www.youtube.com/watch?v=TZ5a3gCCZYo
Odin also has a tracking allocator which can be used to check for leaks or double frees. In debug mode, my program will print out all un-freed memory left after shutdown. If you're working outside of Odin, I've heard good things about Valgrind for C/C++:
https://valgrind.org/
>Any reading recommendations for introduction to the fundamentals of manual memory management specifically
here is a series written by the creator of Odin programming language about memory allocation https://www.gingerbill.org/series/memory-allocation-strategi...
The core:mem package in standard library is a very great resource for memory management in Odin. The standard library's basically got it all.
Thank you, I’d missed that!
any word on this coming out in pdf? thats the version I strongly prefer for my ebooks
Curious, why? I hate pdfs because of their fixed size. Whatever device I happen to use to view a pdf, it's always got a different size than I'd like... either too large (ok I can fix that by zooming out!), wrong proportions, or too small...
I like that it looks like the print book. I have dual screen and when it comes to tech books. I few the pdf fullscreen on one monitor while trying things out actively on another. when I'm on the go, it looks great on a ipad.
for novels where I'm reading for story, I use a kindle but for textbooks, I strongly prefer pdf
While not a first class solution, the EPUB version of the book converts to PDF fairly well (I'm not noticing anything wrong). There are plenty of tools to do so.
I believe the issue is that things are not properly formatted, and does not look as good as it could. For text-only, EPUB is fine, otherwise I would rather prefer PDF, too.
Does the compiler log an error if you try to compile a line of code with more than one "i" in it?
> A floating point number is a method for storing decimal numbers...
I'm sorry, what?
It may not be precise in its details but it's a very accessible explanation that's certainly "good enough." Maybe you could swap it in for "non-whole numbers" and still be reasonably accessible, but that's also not perfectly accurate since integers are stored just fine inside a float.
I'm certainly not going to fault them for using layman terms when addressing laymen.
Ideally for this work you want somebody who is capable of communicating in a way that doesn't feel dumbed down and yet also isn't actively wrong. This explanation of the floating point types does not hit that mark. I'm not in the market for an Odin book, so in some sense it doesn't matter what I think, but across fields it's better if what you're saying is able to both serve its immediate purpose and actually true.
People are going to remember (some of) what you taught them and even if it felt peripheral at the time they may have centred it. When they return to this teaching again, it's not surprising that they assume you meant what you said, even if in your mind it was figurative or targeted at a superficial understanding of the subject.
Decimal representations do exist in machines. Representations that can manage 1.2 exactly but can't handle a third, or pi, or the square root of 2 for example. But the floating point numbers aren't that, they're a weird (but useful) binary fraction and if we're going to mention them at all we need to make it clear what's going on here.
For example the "float" (32-bit IEEE floating point type) called 1.2 is actually 5033165 divided by 4194304 which isn't actually six over five (1.2) but it's pretty close.
What do you mean? It's exactly that in almost any programming language.
What is it you don't understand: "method" (a representation) or "decimal" (a number that consists of a whole and a fractional part)?
I agree with OP that it's unnecessarily confusing. A "method" is a procedure. The floating point number is the result of that procedure, not the procedure itself.
"Decimal" implies a ten based system, even though it's perfectly fine to say "binary decimal".
Using your own replacement words, it would be clearer to write "A floating point number is a representation of a number with a fractional part".
Maybe it should've said "is a method of storing" instead of "for". It would make it clear it's not talking about a procedure, but a way or manner of doing something.
You cannot represent an arbitrary or fixed precision decimal number in a floating point format. Or to put it in another way:
"Most decimal fractions cannot be represented exactly as binary fractions." - from the Python tutorial
The word "decimal" does not simply mean "a number that consists of a whole and a fractional part".
Maybe OP reacted because a float only looks like it is a way to store decimal numbers, when it's only an approximation of decimal numbers. If you really need decimal numbers you need something like mpmath¹.
As a shorthand to explain what a float is to someone, "a decimal number" is an OK start though.
But sometimes that approximation breaks down even for simple examples, i.e. 0.1 cannot be represented as a float. This can be quite unexpected if your mental model is that "floats are decimal numbers with a certain precision".
1: https://mpmath.org/
Some programming languages differentiate between floats and decimals. But yeah, for laypeople, a float is a decimal.
The door for new languages is rapidly closing; unless you are a craftsman and dilettante.
Who's closing the door?
I should have explained my reasoning.
AI coding assistants are closing the door. They need a lot of training data to be good and useful. Established programming languages have a tremendous amount of that, so AI coding agents will do a good job there. C, PHP, Python, Java, etc.
Garden variety and new programming languages have much less examples in the wild, so AI assistants will do a lesser job with those, unless their lineage leads to one of the established languages.
Finally, the bulk of future developers will be lured to AI assisted coding and therefore won’t generate much training data for new programming languages.
A vicious circle.
All of the above is speculation on my part, obviously. Maybe AI assistants will get smart enough to master languages they have not been trained on.