6 ms·

Huge fan of Odin, true C successor. Much better ergonomics and fun to program than say Zig. But needs the following in my view - - A way to generate bindings a

by rwbt 3y ago

Huge fan of Odin, true C successor. Much better ergonomics and fun to program than say Zig. But needs the following in my view - - A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly. - Better tooling and standard library improvements. I think Odin & Nim are my two favorite "modern" languages but they fill different niches. I see Odin as mainly replacing C while Nim is more a C++ replacement (but with Python like rapid development). I'm always amazed at how productive Nim is but the language has many areas that I'm not familiar with (the AST Macros for example). But Odin mostly fits in my head.

gingerBill 3y ago
> A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly. We do want to have an official bindings generator as part of the toolchain. There have been numerous third-party ones that people have created, but we need to have an official one now. However, automatically importing C headers is not actually what virtually anyone wants in practice. Once you have imported the C header file, you pretty much want to: * wrap the entire thing * change the types to better reflect what things are (using Odin's richer type system) * change names of things to better reflect usage and intent * reorganize the declarations to better read things * etc There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs. And Odin's `foreign` system allows [1] for a lot of really nice things that most other languages cannot do so tersely. Here are two examples of demonstrating bindings of C libraries that feel as if they were native Odin libraries WITHOUT any wrappers: * https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx.odin https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx... (and the rest) * https://pkg.odin-lang.org/vendor/sdl2/ https://pkg.odin-lang.org/vendor/sdl2/ and https://github.com/odin-lang/Odin/tree/master/vendor/sdl2 https://github.com/odin-lang/Odin/tree/master/vendor/sdl2 > Better tooling and standard library improvements. Any concrete examples/ideas that you can give? --- [1] https://odin-lang.org/docs/overview/#foreign-system https://odin-lang.org/docs/overview/#foreign-system
- rwbt 3y ago
  > There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs. I completely agree that this a giant PITA. But glad it's being considered to be part of toolchain. I would also suggest you reconsider the functionality of importing C headers directly. Yes, they won't be as nice as Odin bindings but they'll definitely give a nice stop gap. Just recently I had a project that uses WebGPU but couldn't generate Odin bindings automatically or find an existing one. So had to go with C++. Another aspect is, many times I deal with proprietary APIs that have headers with all sorts of macros, bitfields and byte paddings. Having a direct C header import might also help with this case. Yes that API will still be ugly and less ergonomic but everything else would be nice. A bit like Futhark for Nim[0] or lcpp for LuaJIT[1] would really help to write more Odin. Standard Library - I don't remember off the top of my head but I tried strconv procs a while ago to parse OBJ files and found that the floating point parsing to be slower than strtod. Maybe it's not the case anymore I'll give it a try again and open issues on Github for any feature requests. Bitfields - In my line of work this is a must-have. [0] - https://github.com/PMunch/futhark https://github.com/PMunch/futhark [1] - https://github.com/m-schmoock/lcpp https://github.com/m-schmoock/lcpp
  - gingerBill 3y ago
    > I would also suggest you reconsider the functionality of importing C headers directly. Trust me, as this is not as good of an idea as you think. You will just wrap it regardless unless it is absolutely trivial, which in those cases, you could have manually written the code to call the foreign code. And even if it was not as trivial, the types will be mostly wrong too, which means you'd need to correct them. > Just recently I had a project that uses WebGPU WebGPU is a mess regardless. Automatic bindings would still not work as you'd expect. For this specific API, we will add it to the `vendor` library collection along with all of the other graphics APIs. No one has gotten around to adding it yet, that is all. To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against. It rare, if ever, that you need to regenerate the headers every single time you compile your Odin code, and that you don't even have wrap the code. Wrapping the code is effectively equivalent to just writing it yourself. I am talking from experience from other languages. Pretty much every time those languages have the automagical C header importer, they either: * The code had to be wrapped any way * The types need corrected (thus wrapping) * Rarely work correctly * Missed code * It didn't include everything you needed (e.g. preprocessor values as named constants, macros that were effectively normal wrappers, etc) Another problem is that Odin does not support C's way of doing bit fields either, so some concepts will not map directly either. This means that Odin would have to completely embed the entire C type system as part of its language, rather than have those types be _compatible_ and _transformable_ with Odin types.
pepa65 3y ago
I know it's hugely unpopular with some of the HN crowd, but V (vlang) is definitely a worthy competitor in this space. I tried Nim, Zig, etc. but liked Odin (in spite of some oddities in syntax and usage). Now I've moved over to V in this space (although Zig has a lot of traction, so I keep following it).
- gingerBill 3y ago
  Here is a recent review of the language: <https://n-skvortsov-1997.github.io/reviews/ https://n-skvortsov-1997.github.io/reviews/> TL;DR it does not make V, the community, nor the creator look good.
  - michaelolof 3y ago
    That is definetly not a review. Thats a shit post from an "hater" (He acknowledged this himself in the article) written caused he got banned. I doubt people know what an honest review looks like nowadays
- akkad33 3y ago
  V has a garbage collector, so it does not compare with zig or odin
- rwbt 3y ago
  Why is it hugely unpopular if you don't mind me asking?
  - recursivecaveat 3y ago
    Vlang is infamous for crowdfunding on the back of many extremely grandiose, but not actually implemented claims. The poor quality of what did exist was very evident as well. It also had at least a few keyboard warriors associated with it who would play motte and bailey up and down every comment section. I can't speak much to the present state, but I suspect only a few people view it in any serious light.
    - 3y ago

by rwbt 3y ago

gingerBill 3y ago

> A way to generate bindings automatically from C Headers or even better - not having to generate bindings separately and just import C headers directly. We do want to have an official bindings generator as part of the toolchain. There have been numerous third-party ones that people have created, but we need to have an official one now. However, automatically importing C headers is not actually what virtually anyone wants in practice. Once you have imported the C header file, you pretty much want to: * wrap the entire thing * change the types to better reflect what things are (using Odin's richer type system) * change names of things to better reflect usage and intent * reorganize the declarations to better read things * etc There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs. And Odin's `foreign` system allows [1] for a lot of really nice things that most other languages cannot do so tersely. Here are two examples of demonstrating bindings of C libraries that feel as if they were native Odin libraries WITHOUT any wrappers: * https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx.odin https://github.com/floooh/sokol-odin/blob/main/sokol/gfx/gfx... (and the rest) * https://pkg.odin-lang.org/vendor/sdl2/ https://pkg.odin-lang.org/vendor/sdl2/ and https://github.com/odin-lang/Odin/tree/master/vendor/sdl2 https://github.com/odin-lang/Odin/tree/master/vendor/sdl2 > Better tooling and standard library improvements. Any concrete examples/ideas that you can give? --- [1] https://odin-lang.org/docs/overview/#foreign-system https://odin-lang.org/docs/overview/#foreign-system

rwbt 3y ago
> There is also the second issue that C is technically TWO languages: the C programming language and the C preprocessor. People mix the two together and things cannot be easily translated. A good basic example of this is people using `#define` for constants, and thus that name has no semantic meaning in the language itself. A translator has to try and make some semantic meaning from the intersection of these two languages, even if people don't make a distinction when making APIs. I completely agree that this a giant PITA. But glad it's being considered to be part of toolchain. I would also suggest you reconsider the functionality of importing C headers directly. Yes, they won't be as nice as Odin bindings but they'll definitely give a nice stop gap. Just recently I had a project that uses WebGPU but couldn't generate Odin bindings automatically or find an existing one. So had to go with C++. Another aspect is, many times I deal with proprietary APIs that have headers with all sorts of macros, bitfields and byte paddings. Having a direct C header import might also help with this case. Yes that API will still be ugly and less ergonomic but everything else would be nice. A bit like Futhark for Nim[0] or lcpp for LuaJIT[1] would really help to write more Odin. Standard Library - I don't remember off the top of my head but I tried strconv procs a while ago to parse OBJ files and found that the floating point parsing to be slower than strtod. Maybe it's not the case anymore I'll give it a try again and open issues on Github for any feature requests. Bitfields - In my line of work this is a must-have. [0] - https://github.com/PMunch/futhark https://github.com/PMunch/futhark [1] - https://github.com/m-schmoock/lcpp https://github.com/m-schmoock/lcpp
- gingerBill 3y ago
  > I would also suggest you reconsider the functionality of importing C headers directly. Trust me, as this is not as good of an idea as you think. You will just wrap it regardless unless it is absolutely trivial, which in those cases, you could have manually written the code to call the foreign code. And even if it was not as trivial, the types will be mostly wrong too, which means you'd need to correct them. > Just recently I had a project that uses WebGPU WebGPU is a mess regardless. Automatic bindings would still not work as you'd expect. For this specific API, we will add it to the `vendor` library collection along with all of the other graphics APIs. No one has gotten around to adding it yet, that is all. To be clear, I am talking about a tool that will generate the Odin bindings for the specified C header(s). A magical "import c code", is what I am arguing against. It rare, if ever, that you need to regenerate the headers every single time you compile your Odin code, and that you don't even have wrap the code. Wrapping the code is effectively equivalent to just writing it yourself. I am talking from experience from other languages. Pretty much every time those languages have the automagical C header importer, they either: * The code had to be wrapped any way * The types need corrected (thus wrapping) * Rarely work correctly * Missed code * It didn't include everything you needed (e.g. preprocessor values as named constants, macros that were effectively normal wrappers, etc) Another problem is that Odin does not support C's way of doing bit fields either, so some concepts will not map directly either. This means that Odin would have to completely embed the entire C type system as part of its language, rather than have those types be _compatible_ and _transformable_ with Odin types.

pepa65 3y ago

I know it's hugely unpopular with some of the HN crowd, but V (vlang) is definitely a worthy competitor in this space. I tried Nim, Zig, etc. but liked Odin (in spite of some oddities in syntax and usage). Now I've moved over to V in this space (although Zig has a lot of traction, so I keep following it).

gingerBill 3y ago
Here is a recent review of the language: <https://n-skvortsov-1997.github.io/reviews/ https://n-skvortsov-1997.github.io/reviews/> TL;DR it does not make V, the community, nor the creator look good.
- michaelolof 3y ago
  That is definetly not a review. Thats a shit post from an "hater" (He acknowledged this himself in the article) written caused he got banned. I doubt people know what an honest review looks like nowadays
akkad33 3y ago
V has a garbage collector, so it does not compare with zig or odin
rwbt 3y ago
Why is it hugely unpopular if you don't mind me asking?
- recursivecaveat 3y ago
  Vlang is infamous for crowdfunding on the back of many extremely grandiose, but not actually implemented claims. The poor quality of what did exist was very evident as well. It also had at least a few keyboard warriors associated with it who would play motte and bailey up and down every comment section. I can't speak much to the present state, but I suspect only a few people view it in any serious light.
  - 3y ago