3 ms·

I like odin a lot, however, there are two things that just don't stick with me, and i ended up quitting: - RTTI: just give me compile time type introspection a

I like odin a lot, however, there are two things that just don't stick with me, and i ended up quitting: - RTTI: just give me compile time type introspection and let me disable RTTI without making the language unusable - when/import: just let me wrap an import inside a when block, being forced to split my file in 3 made me quit the language

rwbt 1y ago
Can't comment on RTTI, but lack of conditional imports are indeed an annoyance but I'm willing to put up with it because of all the other niceties in the language.
- flysand7 1y ago
  I remember times before Odin banned conditional imports. Those were different times, I miss them
- drannex 1y ago
  You technically _can_ do conditional imports by mis(?)using the #load('') usage, its not perfect and might not work for all cases, but it can be done since #load() loads a file/entity in at compile time. It's a 'hack' but it can be used that way. Edit: This thread is useful: https://forum.odin-lang.org/t/conditional-imports/497/2 https://forum.odin-lang.org/t/conditional-imports/497/2
gingerBill 1y ago
There is compile time type introspection in Odin, it's just not that easy to use on purpose. But why do you not want RTTI? One of the reasons I wanted it over CTTI is because it's a fixed cost rather than an exponential cost—at both compile-time and run-time. People who want CTTI is because they think it will produce better code because it is specialized for that type, and that is partially true, but also it will produce a hell of a lot more code. The canonical example of what I mean is the difference between doing something like `core:fmt` in Odin, which is a fixed cost at both compile-time and run-time, and then doing something closer to `std::format` in C++ (or other similar things in other languages) which will do a specialized procedure for each set of argument types. The former might be a huge initial cost if you only have a single type you want to print, but that cost is always the same regardless of many more types you add, it's also easier to debug. The latter is a small initial cost per type, and when the types get more and more complex, you also produce more and more code, which in turn increases the compiling time and binary/executable size. As for the conditional imports, we did use to allow them but we found that what people were doing with them was kind of missing the point of the platform-specific features of the `package` system, and their code was always better if it actually utilized the package system correctly. There were some other quirks with the conditional imports which did confuse people because they didn't realize how things had to be executed (to allow for out-of-order type checking) and just disallowing it in the first place just solves that too (as a consequence, not as a goal).
thegeekpirate 1y ago
You should be able to import everything, then use `when` to generate a unified constant name: @(require) import "x_a" @(require) import "x_b" when ODIN_OS == .Windows { x :: x_a } else when ODIN_OS == .Linux { x :: x_b } x.do_thing()

rwbt 1y ago

Can't comment on RTTI, but lack of conditional imports are indeed an annoyance but I'm willing to put up with it because of all the other niceties in the language.

flysand7 1y ago
I remember times before Odin banned conditional imports. Those were different times, I miss them
drannex 1y ago
You technically _can_ do conditional imports by mis(?)using the #load('') usage, its not perfect and might not work for all cases, but it can be done since #load() loads a file/entity in at compile time. It's a 'hack' but it can be used that way. Edit: This thread is useful: https://forum.odin-lang.org/t/conditional-imports/497/2 https://forum.odin-lang.org/t/conditional-imports/497/2

gingerBill 1y ago

There is compile time type introspection in Odin, it's just not that easy to use on purpose. But why do you not want RTTI? One of the reasons I wanted it over CTTI is because it's a fixed cost rather than an exponential cost—at both compile-time and run-time. People who want CTTI is because they think it will produce better code because it is specialized for that type, and that is partially true, but also it will produce a hell of a lot more code. The canonical example of what I mean is the difference between doing something like `core:fmt` in Odin, which is a fixed cost at both compile-time and run-time, and then doing something closer to `std::format` in C++ (or other similar things in other languages) which will do a specialized procedure for each set of argument types. The former might be a huge initial cost if you only have a single type you want to print, but that cost is always the same regardless of many more types you add, it's also easier to debug. The latter is a small initial cost per type, and when the types get more and more complex, you also produce more and more code, which in turn increases the compiling time and binary/executable size. As for the conditional imports, we did use to allow them but we found that what people were doing with them was kind of missing the point of the platform-specific features of the `package` system, and their code was always better if it actually utilized the package system correctly. There were some other quirks with the conditional imports which did confuse people because they didn't realize how things had to be executed (to allow for out-of-order type checking) and just disallowing it in the first place just solves that too (as a consequence, not as a goal).

thegeekpirate 1y ago

You should be able to import everything, then use `when` to generate a unified constant name: @(require) import "x_a" @(require) import "x_b" when ODIN_OS == .Windows { x :: x_a } else when ODIN_OS == .Linux { x :: x_b } x.do_thing()