5 ms·

I think Odin is the best language in this niche so far. And although I prefer it slightly to Zig, I expect Zig to eat Odin's lunch. Odin seems to have procras

I think Odin is the best language in this niche so far. And although I prefer it slightly to Zig, I expect Zig to eat Odin's lunch. Odin seems to have procrastinated the important things that cause a language to really take off, in favor more trivial features. At this point I think Odin has crossed into the territory of being wrong in the direction of too many features rather than too few. While having not delivered important tools that would cause the language to accrete an ecosystem. A must-have for wide adoption is a package/dependency manager. As I've said before: Just clone what Go has. Just take it, you need it to be popular, and you probably aren't going to do better. `import "github.com/whatever"`. I believe Zig has already started on a package manager, while the sentiment in the Odin community is that the unnecessary concept of "collections" somehow solves the dependency problem.

gingerBill 3y ago
I am the creator of the Odin programming language, and thank you for the rhetorical insult :) > procrastinated the important things that cause a language to really take off, in favor more trivial features. So I should have focused on making a hype language rather than actually solve problems in programming that can be solved a the language level? I don't think anyone would call that "procrastination". > At this point I think Odin has crossed into the territory of being wrong in the direction of too many features rather than too few. While having not delivered important tools that would cause the language to accrete an ecosystem. That's vague as anything. Can you give any concrete examples? > A must-have for wide adoption is a package/dependency manager. And because Odin has a well defined concept of what a package is in the language itself, then creating one would be trivial for someone to do. Now this is going to be a VERY VERY controversial take but I do not want to __officially__ support a package manager. I know it's "so nice" to do something like `go get`, but I am not a huge fan of package managers in general and I honestly and truly believe that they have caused a huge amount of problems that cannot be solved by their existence. Please do not speculate what I "prefer", but I will not explain in this comment since it would take an entire article's/video's worth of explaining. > while the sentiment in the Odin community is that the unnecessary concept of "collections" somehow solves the dependency problem. This is just incorrect. There are few people who are working on a package manager for Odin, there is just not an OFFICIAL package manager. And that is not what a library collection is for either. A library collection is a named search lookup. All imports are relative to either the current file OR a named library collection (a named directory). This solves the problem in C with `#include <...>` where you don't know how it is searching, whilst in Odin `import "core:fmt"` or `import gl "vendor:OpenGL"` or "import "../foo" has been made EXPLICIT where it is searching from. ---- I am not trying to create a "hype language" but actually make a language that solves mine and loads of people's actual problems. I do not view that as any form of procrastination whatsoever, and that you do is quite sad.
- tialaramex 3y ago
  > there is just not an OFFICIAL package manager I think the C++ experience gets to why a modern language intended for widespread use needs one package manager, whether that's an "official" package manager or a "de facto" package manager - not zero and not six. Having looked at the Odin "core" library it seems to me it's mostly "Stuff Bill wanted" which won't scale. But I'm not an Odin user, so there's no particular reason you should care what I think.
  - gingerBill 3y ago
    > C++ experience I have well over a decade of C++ experience, and the Odin compiler is written in C++. I agree having 1 de facto (not de jure) package manager is the best option. Making it official (de jure) does reduce the chances of de facto package managers from arising. A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library. I didn't even write half of the core library, loads of other contributors did. > But I'm not an Odin user, so there's no particular reason you should care what I think. So why comment? :P
    - tialaramex 3y ago
      > A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library. It's uh, esoteric is I guess the most polite term I can think of. SM3 hashes? TGA images? I found some typos for whatever that's worth: e.g. "If you the elements to remain in their order" is I think missing a word, maybe "want" or "intend") > So why comment? :P You don't have to read the comments either :D
      - gingerBill 3y ago
        `core:crypto/sm3` is just one of the many cryptographic hashes that exist in Odin. You've just told me you have never done any cryptographic work like SSL, and how useful that is for things like encrypted web protocols. As for TGA images, that is an image format that people still use, along with many others Odin supports. We want to be able to load an image regardless of its format, be it PNG, TGA, JPEG, etc.
lerno 3y ago
I would argue that Zig’s inability to produce static or dynamic libraries that use Zig features in its API is a much bigger problem that Odin’s lack of a package manager. Neither Odin nor C3 has any problems with this, and it simply follows from Zig’s semantics that it is rendered impossible. So will Zig semantics change (which would be a big change indeed), or will Zig precompiles libraries always be forced to go by way of special C-compatible calls and types? Before I’d declare Zig the winner due to a package manager I’d be sure to figure that one out.
AndyKelley 3y ago
Indeed, the Zig build system includes a package manager. Fetching, configuration, compilation, and installation are all 1 command: zig build Furthermore, C and C++ code can participate in the Zig package ecosystem. For example, here is ffmpeg packaged for consumption by a Zig project: https://github.com/andrewrk/ffmpeg https://github.com/andrewrk/ffmpeg Why not use a system package? Well, because the user's system might not have such a package. They might be on Windows, for example. Or their package might be out of date. [Or the system might have chosen sides in a nasty fork war](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html). So, while system packages are nice for end users, they might not always satisfy the needs of upstream application developers.
- pjmlp 3y ago
  When will the package manager support binary libraries? There is a world in the C and C++ commercial ecosystems that will never adopt tooling that doesn't support shipping some form of binary libraries.
  - flohofwoe 3y ago
    I haven't tried it yet, but the Zig package manager should be flexible enough to deal with binary blobs? After all it's just pulling in an external directory and runs its build.zig (which then can make available precompiled libraries to the rest of the build process).
    - pjmlp 3y ago
      I am more thinking in the lines of Conan, vcpkg, NuGet, npm, Maven, Gradle, and system packages (with pkg-config), it is more than just a binary blob. I remember reading somewhere that there was no plan for binary packages in Zig, given its FOSS point of view.
      - flohofwoe 3y ago
        Yeah I guess you'd need to wrap "binary packages" into a library with C API (even if the implementation is written in Zig).
stinkbutt 3y ago
what's the niche? the authors described it as general-purpose
- el_oni 3y ago
  The creator, gingerbill, uses it to build real time flame and smoke rendering [0]. AFAIK they have vectors and matrices built into the stdlib as well as various graphics apis[1]. So I'd say from what I know the niche is "batteries included high performance code that can target the gpu" [0]https://jangafx.com/software/embergen/ https://jangafx.com/software/embergen/ [1]https://odin-lang.org/news/major-graphics-apis/ https://odin-lang.org/news/major-graphics-apis/
- gingerBill 3y ago
  Odin is a general purpose language, in the same way C. Professionally, we use Odin to create all of our software at JangaFX: EmberGen, LiquiGen, and GeoGen. Many people have been using Odin for similar purposes: * game development * application development * 3D graphics * physics related stuff * etc This is what a lot of people feel Odin's "niche" is, even if it is not restricted to that. A good example of this is Odin's first class features for array-programming, swizzling, matrices, quaternions, and many other things useful when dealing with 3D related things (graphics, physics, games, etc).
- TylerE 3y ago
  People who still think C is basically a good idea?

gingerBill 3y ago

I am the creator of the Odin programming language, and thank you for the rhetorical insult :) > procrastinated the important things that cause a language to really take off, in favor more trivial features. So I should have focused on making a hype language rather than actually solve problems in programming that can be solved a the language level? I don't think anyone would call that "procrastination". > At this point I think Odin has crossed into the territory of being wrong in the direction of too many features rather than too few. While having not delivered important tools that would cause the language to accrete an ecosystem. That's vague as anything. Can you give any concrete examples? > A must-have for wide adoption is a package/dependency manager. And because Odin has a well defined concept of what a package is in the language itself, then creating one would be trivial for someone to do. Now this is going to be a VERY VERY controversial take but I do not want to __officially__ support a package manager. I know it's "so nice" to do something like `go get`, but I am not a huge fan of package managers in general and I honestly and truly believe that they have caused a huge amount of problems that cannot be solved by their existence. Please do not speculate what I "prefer", but I will not explain in this comment since it would take an entire article's/video's worth of explaining. > while the sentiment in the Odin community is that the unnecessary concept of "collections" somehow solves the dependency problem. This is just incorrect. There are few people who are working on a package manager for Odin, there is just not an OFFICIAL package manager. And that is not what a library collection is for either. A library collection is a named search lookup. All imports are relative to either the current file OR a named library collection (a named directory). This solves the problem in C with `#include <...>` where you don't know how it is searching, whilst in Odin `import "core:fmt"` or `import gl "vendor:OpenGL"` or "import "../foo" has been made EXPLICIT where it is searching from. ---- I am not trying to create a "hype language" but actually make a language that solves mine and loads of people's actual problems. I do not view that as any form of procrastination whatsoever, and that you do is quite sad.

tialaramex 3y ago
> there is just not an OFFICIAL package manager I think the C++ experience gets to why a modern language intended for widespread use needs one package manager, whether that's an "official" package manager or a "de facto" package manager - not zero and not six. Having looked at the Odin "core" library it seems to me it's mostly "Stuff Bill wanted" which won't scale. But I'm not an Odin user, so there's no particular reason you should care what I think.
- gingerBill 3y ago
  > C++ experience I have well over a decade of C++ experience, and the Odin compiler is written in C++. I agree having 1 de facto (not de jure) package manager is the best option. Making it official (de jure) does reduce the chances of de facto package managers from arising. A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library. I didn't even write half of the core library, loads of other contributors did. > But I'm not an Odin user, so there's no particular reason you should care what I think. So why comment? :P
  - tialaramex 3y ago
    > A lot of "core" isn't "Stuff Bill wanted". There are loads of things in there that I never use, but I feel is necessary for a "core" library. It's uh, esoteric is I guess the most polite term I can think of. SM3 hashes? TGA images? I found some typos for whatever that's worth: e.g. "If you the elements to remain in their order" is I think missing a word, maybe "want" or "intend") > So why comment? :P You don't have to read the comments either :D
    - gingerBill 3y ago
      `core:crypto/sm3` is just one of the many cryptographic hashes that exist in Odin. You've just told me you have never done any cryptographic work like SSL, and how useful that is for things like encrypted web protocols. As for TGA images, that is an image format that people still use, along with many others Odin supports. We want to be able to load an image regardless of its format, be it PNG, TGA, JPEG, etc.

lerno 3y ago

I would argue that Zig’s inability to produce static or dynamic libraries that use Zig features in its API is a much bigger problem that Odin’s lack of a package manager. Neither Odin nor C3 has any problems with this, and it simply follows from Zig’s semantics that it is rendered impossible. So will Zig semantics change (which would be a big change indeed), or will Zig precompiles libraries always be forced to go by way of special C-compatible calls and types? Before I’d declare Zig the winner due to a package manager I’d be sure to figure that one out.

AndyKelley 3y ago

Indeed, the Zig build system includes a package manager. Fetching, configuration, compilation, and installation are all 1 command: zig build Furthermore, C and C++ code can participate in the Zig package ecosystem. For example, here is ffmpeg packaged for consumption by a Zig project: https://github.com/andrewrk/ffmpeg https://github.com/andrewrk/ffmpeg Why not use a system package? Well, because the user's system might not have such a package. They might be on Windows, for example. Or their package might be out of date. [Or the system might have chosen sides in a nasty fork war](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html). So, while system packages are nice for end users, they might not always satisfy the needs of upstream application developers.

pjmlp 3y ago
When will the package manager support binary libraries? There is a world in the C and C++ commercial ecosystems that will never adopt tooling that doesn't support shipping some form of binary libraries.
- flohofwoe 3y ago
  I haven't tried it yet, but the Zig package manager should be flexible enough to deal with binary blobs? After all it's just pulling in an external directory and runs its build.zig (which then can make available precompiled libraries to the rest of the build process).
  - pjmlp 3y ago
    I am more thinking in the lines of Conan, vcpkg, NuGet, npm, Maven, Gradle, and system packages (with pkg-config), it is more than just a binary blob. I remember reading somewhere that there was no plan for binary packages in Zig, given its FOSS point of view.
    - flohofwoe 3y ago
      Yeah I guess you'd need to wrap "binary packages" into a library with C API (even if the implementation is written in Zig).

stinkbutt 3y ago

what's the niche? the authors described it as general-purpose

el_oni 3y ago
The creator, gingerbill, uses it to build real time flame and smoke rendering [0]. AFAIK they have vectors and matrices built into the stdlib as well as various graphics apis[1]. So I'd say from what I know the niche is "batteries included high performance code that can target the gpu" [0]https://jangafx.com/software/embergen/ https://jangafx.com/software/embergen/ [1]https://odin-lang.org/news/major-graphics-apis/ https://odin-lang.org/news/major-graphics-apis/
gingerBill 3y ago
Odin is a general purpose language, in the same way C. Professionally, we use Odin to create all of our software at JangaFX: EmberGen, LiquiGen, and GeoGen. Many people have been using Odin for similar purposes: * game development * application development * 3D graphics * physics related stuff * etc This is what a lot of people feel Odin's "niche" is, even if it is not restricted to that. A good example of this is Odin's first class features for array-programming, swizzling, matrices, quaternions, and many other things useful when dealing with 3D related things (graphics, physics, games, etc).
TylerE 3y ago
People who still think C is basically a good idea?