Is anyone doing desktop GUI apps with Odin? If so, what libraries are you using?
I use Dear ImGui and love it https://gitlab.com/L-4/odin-imgui
Thank you.
Odin, a pragmatic C alternative with a Go flavour
121–130 of 131 posts
Re: Odin, a pragmatic C alternative with a Go flavour
#122Earlier quoted context omitted.
^ and this person (no affiliation) has a much "truer" C alternative in the making, just for everyone's information: https://c3-lang.org/ Haven't gotten around to trying it out, but skimmed the documents a lot at one point. Always try to keep tabs on it, doesn't get the love it should.
Yeah, I have used Odin before, I am thinking of giving C3 a try as well. At a quick glance though: > Enum support various reflection properties: .values returns an array with all enums. .len or .elements returns the number of enum values, .inner returns the storage type. .names returns an array with the names of all enums. .associated returns an array of the typeids of the associated values for the enum. I do not lik…
Oh `.elements` would you believe that this is a remnant of C2's builtin function `elemsof`? Its used so rarely (I think two uses in the entire stdlib), so it hasn't come up. I opened an issue for it: https://github.com/c3lang/c3c/issues/2130
This is a good example of the sharp edges I hope to smoothen out in 0.7-0.9.
Re: Odin, a pragmatic C alternative with a Go flavour
#123For me, I don't really look at Odin as a successor/fixer of C. There are other languages that can make a better case for that[1][2]. Instead, I look at it more like a successor/fixer of Pascal. It doesn't fall down the OO hole that so many others did. It has type casting, dynamic arrays, parametric polymorphism in both functions and data structures, is much less noisy (and in my opinion far more skimmable), more usef…
I checked out bcrypt implementation in Hare, and I saw "errors::invalid" being used. It was not specified. What if I want to have more errors and in the documentation I want people to know which errors, say, my library may return from specific functions? C3 had some weird stuff going on at some places, not exactly sure why. In my other thread someone else already went into it in more detail. I hope the developer will…
I saw what you wrote about the enums, anything else? And feel free to add issues for things that feel off.
Re: Odin, a pragmatic C alternative with a Go flavour
#124Earlier quoted context omitted.
I checked out bcrypt implementation in Hare, and I saw "errors::invalid" being used. It was not specified. What if I want to have more errors and in the documentation I want people to know which errors, say, my library may return from specific functions? C3 had some weird stuff going on at some places, not exactly sure why. In my other thread someone else already went into it in more detail. I hope the developer will…
I saw what you wrote about the enums, anything else? And feel free to add issues for things that feel off.
Thank you! I appreciate you opening the issue with regarding to enum's "elements". I would have to take a serious look at C3 to be able to be useful, but I cannot do it right now due to some health and financial struggles. :( Hopefully soon enough though! I want to have C3 as a better C alternative.
Re: Odin, a pragmatic C alternative with a Go flavour
#125Earlier quoted context omitted.
I saw what you wrote about the enums, anything else? And feel free to add issues for things that feel off.
Thank you! I appreciate you opening the issue with regarding to enum's "elements". I would have to take a serious look at C3 to be able to be useful, but I cannot do it right now due to some health and financial struggles. :( Hopefully soon enough though! I want to have C3 as a better C alternative.
Amusingly enough, I found that the compiler also accepted MyEnum.len (completely undocumented!). That was an easter egg!
But I'm trying to update the docs for types now. It's reasonable to just have all the compile time type properties in one place so people can find them.
Re: Odin, a pragmatic C alternative with a Go flavour
#126Earlier quoted context omitted.
Thank you! I appreciate you opening the issue with regarding to enum's "elements". I would have to take a serious look at C3 to be able to be useful, but I cannot do it right now due to some health and financial struggles. :( Hopefully soon enough though! I want to have C3 as a better C alternative.
Amusingly enough, I found that the compiler also accepted MyEnum.len (completely undocumented!). That was an easter egg! But I'm trying to update the docs for types now. It's reasonable to just have all the compile time type properties in one place so people can find them.
I saw ".len" somewhere, I think I did mention it in my comment[1]. :)
Thank you for updating the docs!
[1] Oh, apparently I did, here: https://news.ycombinator.com/item?id=43954980, I quoted what I read in the documentation (?, may have been just on some part of the website) which included ".len", it is said somewhere as such: ".len or .elements returns the number of enum values".
Re: Odin, a pragmatic C alternative with a Go flavour
#127Earlier quoted context omitted.
Only if they aren't using anything beyond C99, because after that C is basically turning into C++ without Classes .
Most C programmers I know pretty much do that. I use C11 just for the atomics and that is it. And I know many C programmers who still use C89/C90 exclusively.
[deleted]
Re: Odin, a pragmatic C alternative with a Go flavour
#128Earlier quoted context omitted.
Only if they aren't using anything beyond C99, because after that C is basically turning into C++ without Classes .
Most C programmers I know pretty much do that. I use C11 just for the atomics and that is it. And I know many C programmers who still use C89/C90 exclusively.
Well yeah, I use C99. I would never use newer C, it is too C++-esque. You can actually use some stuff from stdatomic.h with -std=c99 -D_XOPEN_SOURCE=700, such as "atomic_bool" and whatnot.
Re: Odin, a pragmatic C alternative with a Go flavour
#129For me, I don't really look at Odin as a successor/fixer of C. There are other languages that can make a better case for that[1][2]. Instead, I look at it more like a successor/fixer of Pascal. It doesn't fall down the OO hole that so many others did. It has type casting, dynamic arrays, parametric polymorphism in both functions and data structures, is much less noisy (and in my opinion far more skimmable), more usef…
While I do agree that C3 tries a bit harder to keep closer to the look and feel of C, it has arguably already veered too far away, in order to be modern. These changes can be viewed as unacceptable to many fans of C. C3 has taken on a very strong Odin and Jai flavor. Since that's the case, the argument for Odin, Jai, Vlang, etc... would be equally valid. If you are going to make a modern language, then their creators should not feel too restrained.
There are other C family languages that have a Pascal influence and didn't go OO crazy, not just Odin. So in that context, languages like Golang, Vlang, Jai, etc... are equally viable alternatives to look at.
Re: Odin, a pragmatic C alternative with a Go flavour
#130Earlier quoted context omitted.
Isn't Go the modern successor of Pascal? It certainly didn't fall down the OO hole.
First it needs to catch up to some Pascal features like real enumerated types, no iota/const dance.
I don't understand why Go still resists enums, as if they didn't learn any lessons from continually denying their users generics for so many years.