Marketing the Odin programming language is weird(gingerbill.org)
gingerbill.org
Marketing the Odin programming language is weird
http://www.gingerbill.org/article/2024/09/08/odin-weird-to-market/
105 comments
And if that's the case, me too. I understand that IRC is plain and boring but discord I avoid.
Shame, I've never seen Odin before and got excited over the show cases. I've been looking to tinker with another language outside of the main three, (python, go, rust) and this looks nice.
I think I may try Lazarus again.
Shame, I've never seen Odin before and got excited over the show cases. I've been looking to tinker with another language outside of the main three, (python, go, rust) and this looks nice.
I think I may try Lazarus again.
> I think I may try Lazarus again.
Why Lazarus? You're talking about the Pascal RAD IDE, right?
Why Lazarus? You're talking about the Pascal RAD IDE, right?
Yeah.
> I do find it quite irritating that only place to ask questions [is] discord
It's a tradeoff. The platform is a closed-source silo.
But for a lot of people, it works really well.
I avoided it until eventually one community made me want to be a member.
Those who dislike Discord in that community set up relay bots.
> Community questions and answers need to be readable and searchable without yet another login.
This is a big tragedy that any technical community will suffer from long-term for choosing Discord:
They may cultivate a community, but they will not grow their garden of knowledge.
But to have your resources and attention spread too thin can be devastating, too.
Only huge projects can afford to have multiple Discords, Telegrams, IRCs, Wikis, and not worry too much about the overflow and redundancy.
Small projects like Odin must focus on having a few high-traffic places.
It's a tradeoff. The platform is a closed-source silo.
But for a lot of people, it works really well.
I avoided it until eventually one community made me want to be a member.
Those who dislike Discord in that community set up relay bots.
> Community questions and answers need to be readable and searchable without yet another login.
This is a big tragedy that any technical community will suffer from long-term for choosing Discord:
They may cultivate a community, but they will not grow their garden of knowledge.
But to have your resources and attention spread too thin can be devastating, too.
Only huge projects can afford to have multiple Discords, Telegrams, IRCs, Wikis, and not worry too much about the overflow and redundancy.
Small projects like Odin must focus on having a few high-traffic places.
One word: Discourse.
> Only huge projects can afford to have multiple Discords, Telegrams, IRCs, Wikis
There's one option available to small projects and actually you already named it yourself:
> relay bots.
Take for example Nim community. It's not huge by any margin, but we have fairly active forum[0], occasionally active Telegram channel and most of activity is on Discord, IRC and Matrix. I've grouped these three because they're almost seamlessly connected with relay bots into one platform. You can join one of several bridged platforms[1] and talk to everyone on Discord, Gitter, Matrix, etc. with quotes, pings and attachments working as you'd expect them to.
It is certainly an extra burden to moderate and manage all of this, but now you can atleast have an IRC archive[2] that's indexable and searchable [3].
On the other hand, having Discord as your *only* place for discussions is plain stupid (read: foolish). Because I know several people, including myself some years ago, that just 'nope out' from using a project when they see that the only place to get support is a Discord channel.
[0] - https://forum.nim-lang.org/
[1] - https://nim-lang.org/community.html
[2] - https://irclogs.nim-lang.org/30-05-2012.html
[3] - https://duckduckgo.com/?t=ffab&q=site%3Airclogs.nim-lang.org...
There's one option available to small projects and actually you already named it yourself:
> relay bots.
Take for example Nim community. It's not huge by any margin, but we have fairly active forum[0], occasionally active Telegram channel and most of activity is on Discord, IRC and Matrix. I've grouped these three because they're almost seamlessly connected with relay bots into one platform. You can join one of several bridged platforms[1] and talk to everyone on Discord, Gitter, Matrix, etc. with quotes, pings and attachments working as you'd expect them to.
It is certainly an extra burden to moderate and manage all of this, but now you can atleast have an IRC archive[2] that's indexable and searchable [3].
On the other hand, having Discord as your *only* place for discussions is plain stupid (read: foolish). Because I know several people, including myself some years ago, that just 'nope out' from using a project when they see that the only place to get support is a Discord channel.
[0] - https://forum.nim-lang.org/
[1] - https://nim-lang.org/community.html
[2] - https://irclogs.nim-lang.org/30-05-2012.html
[3] - https://duckduckgo.com/?t=ffab&q=site%3Airclogs.nim-lang.org...
I think that it is hard to market a new "pragmatic" language because the pragmatic decision in most cases is to use an existing language that you already know, that has a community around it with all it's accumulated wisdom (documentation, tutorials, blog posts, StackOverflow Q&A), rich library ecosystem etc.
The main point of "killer feature" is not to make the language more "hypeable" but to give a potential user a clear reason why the benefits of learning your language will outweigh the costs of using a less mature or less popular technology.
The main point of "killer feature" is not to make the language more "hypeable" but to give a potential user a clear reason why the benefits of learning your language will outweigh the costs of using a less mature or less popular technology.
I think the best approach is to make your language seamlessly interoperable with some existing language.
Well that usually has significant downsides too so it's not as simple as "do that". But yeah if you can do that it's a big benefit.
I guess it does help by making the cost of adoption lower.
But my main point is that being an early adopter of a non-mainstream tech is fundamentally unpragmatic and usually people are driven to try something new by desire to try something __cool__ not by pragmatic considerations.
But my main point is that being an early adopter of a non-mainstream tech is fundamentally unpragmatic and usually people are driven to try something new by desire to try something __cool__ not by pragmatic considerations.
The success of TypeScript, a syntactic superset of JS and recently the fastest growing programming language, seems to confirm it.
[deleted]
That is one thing that could be a killer feature and I like Zig for it, but I can see myself using a language without that level of interoperability if it has a good enough killer feature set
One of the best ways for a developer to plead their case for using their language, is to have a book written about it. That's where to teach people how to use the language, show in code the advantages of using it, and elaborate in detail why its a better language.
If the language doesn't at least have a book written on it, then it can be argued it's way too early to take the language seriously. Some of the reasons why the language has not reached the stage to be written about: still too unstable, few followers, or still making a lot of breaking changes. Other reasons, like laziness or arrogance, are equally not good.
Some of these new hyped languages like Odin, C3, hare, beef, pony, etc... They get a lot of continuous attention on here and specific other places, but then when we go to find out more about them, there is little of real substance. Their GitHub has few stars, few contributors, no Wikipedia page, not a thing about them on Amazon, etc...
At least start with step 1. Where is the book on this programming language? Would be nice to be able to actually read or see more than just a blog entry or an ad.
If the language doesn't at least have a book written on it, then it can be argued it's way too early to take the language seriously. Some of the reasons why the language has not reached the stage to be written about: still too unstable, few followers, or still making a lot of breaking changes. Other reasons, like laziness or arrogance, are equally not good.
Some of these new hyped languages like Odin, C3, hare, beef, pony, etc... They get a lot of continuous attention on here and specific other places, but then when we go to find out more about them, there is little of real substance. Their GitHub has few stars, few contributors, no Wikipedia page, not a thing about them on Amazon, etc...
At least start with step 1. Where is the book on this programming language? Would be nice to be able to actually read or see more than just a blog entry or an ad.
I recently used Odin in a commercial project and had a great experience. For me the biggest hurdle was not the language, but having to write programs without an IDE like Visual Studio/Xcode. Having to write my own build scripts (shell or batch files) etc and maintaining them is a PITA.
But I'm glad I did it because it checks off all the "C but nicer" checkboxes.
But I'm glad I did it because it checks off all the "C but nicer" checkboxes.
The fact that it not only doesn’t have a built in build tool/package manager, but that the author has also said he doesn’t believe in them and will never make one was very off putting to me. I love how languages like Rust have cargo, or gleam has it built right into the compiler. I’m so fed up with how in C++ or Python there’s a billion competing tools. The language looked really cool, but without good author-blessed tooling, I doubt I’ll ever use it myself.
At least in Python you can probably download a project and run it even ignoring whatever tool the author used. In C++? Good luck!
Only if it doesn't depend on binary libraries, or anything beyond its batteries.
> The fact that it not only doesn’t have a built in build tool/package manager...
I've been programming in Odin for a few months now, and I've come to actually like this choice.
I still use the occasional dependency, and installing it is even easier than with a package manager!
I download a repo as zip from github, extract it in my project, and voilà, it's ready to use. No compilation, transpilation, peer dependencies, locking versions, etc.
Another positive of this approach is that I can now easily read the dependency source code and if needed modify it, as it's become a part of my project, not some transpiled and minified version of that code sitting in an unversioned folder.
Overall, in Odin I use dependencies much more sparingly than when I work with JS. The reason is that the core and vendor packages of the language already include a surprising amount of things you'd normally reach npm/cargo for. Need linear algebra primitives? Specialized data structures like a priority queue? SDL2? stbi? It's all included in the language (and so much more), ready to use.
I've come to realize that more often than not it's fine to reinvent the wheel to solve your specific problem rather than relying on a generalized (and thus unoptimized) 3rd party library.
I've been programming in Odin for a few months now, and I've come to actually like this choice.
I still use the occasional dependency, and installing it is even easier than with a package manager!
I download a repo as zip from github, extract it in my project, and voilà, it's ready to use. No compilation, transpilation, peer dependencies, locking versions, etc.
Another positive of this approach is that I can now easily read the dependency source code and if needed modify it, as it's become a part of my project, not some transpiled and minified version of that code sitting in an unversioned folder.
Overall, in Odin I use dependencies much more sparingly than when I work with JS. The reason is that the core and vendor packages of the language already include a surprising amount of things you'd normally reach npm/cargo for. Need linear algebra primitives? Specialized data structures like a priority queue? SDL2? stbi? It's all included in the language (and so much more), ready to use.
I've come to realize that more often than not it's fine to reinvent the wheel to solve your specific problem rather than relying on a generalized (and thus unoptimized) 3rd party library.
Thanks for taking the time to tell us about your experience! I’m happy it works well for you! With that said, that doesn’t sound like it’s for me.
This sounds like what I already do in C++ (except I use git submodules for dependencies because it makes it easier to pull new versions, check for versions, etc), and tbh I don’t much like it. I do it out of necessity. I’d much rather keep tabs of all my libraries and versions on a project file and have a tool that will download the version for me, build it, tell me when new versions are available, update to the latest version (if I so choose), and so on. In C++, I have to manually do to each dependency and check if there’s a new version, and pull it if I decide I want it. In, eg, Gleam, I can ask gleam what’s new.
In Odin, it sounds like I have to do the same — either use submodules or download the release files by hand. I have to manually check for updates and then replace my local files.
It’s just not something I personally like to do. The author is entitled to be opinionated about this, but it clashes with my own opinion, so that means I probably won’t try the language even though it looks pretty good from a language design point of view.
This sounds like what I already do in C++ (except I use git submodules for dependencies because it makes it easier to pull new versions, check for versions, etc), and tbh I don’t much like it. I do it out of necessity. I’d much rather keep tabs of all my libraries and versions on a project file and have a tool that will download the version for me, build it, tell me when new versions are available, update to the latest version (if I so choose), and so on. In C++, I have to manually do to each dependency and check if there’s a new version, and pull it if I decide I want it. In, eg, Gleam, I can ask gleam what’s new.
In Odin, it sounds like I have to do the same — either use submodules or download the release files by hand. I have to manually check for updates and then replace my local files.
It’s just not something I personally like to do. The author is entitled to be opinionated about this, but it clashes with my own opinion, so that means I probably won’t try the language even though it looks pretty good from a language design point of view.
As someone who writes C# for a living, I see some great advantages with package managers. We have setup a system where our own libraries are published to our local nuget repository and the results have been positive.
With that said, could we do this without a package manager? I mean.. yes.. instead of a nuget folder structure it would be a dll folder structure. Certainly possible, generally speaking.
I guess there is negatives on either side. Without a package manager you have to be more manual. With it updating is easy.. and I know developers that update them without looking into the details. There was one example where nuget said there was an update.. so the developer updated it and it caused errors. Thats because the update was for a later .NET version.
However, when it comes to odin, I have found it to be a pleasant experience doing a `git pull` of any odin library I need to a 'thirdparty' directory and to import them into my odin code.
So we have the builtin ones like core, vendor, etc... then I have thirdparty. If any of those libraries in thirdparty made its way into odins vendor.. it would be a simple change in the code.
I use Odin in my own personal projects but if I used it at my current workplace, I would likely setup a structure similar to my C# setup.. with a shared directory holding libraries we need -- simply git pulls, etc.
With that said, could we do this without a package manager? I mean.. yes.. instead of a nuget folder structure it would be a dll folder structure. Certainly possible, generally speaking.
I guess there is negatives on either side. Without a package manager you have to be more manual. With it updating is easy.. and I know developers that update them without looking into the details. There was one example where nuget said there was an update.. so the developer updated it and it caused errors. Thats because the update was for a later .NET version.
However, when it comes to odin, I have found it to be a pleasant experience doing a `git pull` of any odin library I need to a 'thirdparty' directory and to import them into my odin code.
So we have the builtin ones like core, vendor, etc... then I have thirdparty. If any of those libraries in thirdparty made its way into odins vendor.. it would be a simple change in the code.
I use Odin in my own personal projects but if I used it at my current workplace, I would likely setup a structure similar to my C# setup.. with a shared directory holding libraries we need -- simply git pulls, etc.
A modern language is a runtime library and ecosystem (a BIG one) ide tooling analysis, deployment, etc.
You can't be a general language without general tooling.
You can't be a general language without general tooling.
These dependency managers are something of a double-edged sword. They avoid a lot of work if your project has a lot of external packages, but they also encourage pulling in lots of external dependencies without much thought. Every one of those, and every one of their sub-dependencies, exposes users of the software to significantly more risk. It's a breeding ground for common vulnerabilities and supply chain attacks.
Partly because of this, I try to avoid external dependencies as much as possible. When I need something that's not built in to the language, I choose in the following order of preference:
1. The standard library and target platform libraries, augmenting any inadequate features with my own extensions if necessary.
2. A very well known, well maintained, and widely used library with few dependencies of its own. Something that could almost be mistaken for #1.
3. Write my own minimal version of what I need, if I can do so with a reasonable level of effort.
4. A lesser-known third-party library, if it appears well maintained, and if I am willing to audit it and every future update to it.
A happy side effect is that a language with no built-in dependency manager is still perfectly viable for me, since it wouldn't be saving me much work anyway.
Partly because of this, I try to avoid external dependencies as much as possible. When I need something that's not built in to the language, I choose in the following order of preference:
1. The standard library and target platform libraries, augmenting any inadequate features with my own extensions if necessary.
2. A very well known, well maintained, and widely used library with few dependencies of its own. Something that could almost be mistaken for #1.
3. Write my own minimal version of what I need, if I can do so with a reasonable level of effort.
4. A lesser-known third-party library, if it appears well maintained, and if I am willing to audit it and every future update to it.
A happy side effect is that a language with no built-in dependency manager is still perfectly viable for me, since it wouldn't be saving me much work anyway.
Well… we can’t save people from themselves. It’s always prudent to ensure the libraries you use are high quality, stable, and well maintained and your list is a good order of reference to live by, in any language.
The SoA features look really nice. I have wanted that forever.
Matrices are built in(!), and look nicely implemented. So are complex numbers and quaternions!
The array programming aspects in general look great.
Zig might be the nicer language for a kernel or a server of some kind, but Odin looks like the better language not just for games, but also for robotics and for scientific programming.
The only problem I forsee is that it seems hard to write nice mathematical libraries for anything that isn't built in.
For example, suppose I want to work with polynomials using a natural infix syntax. Or that I want to wrap matrices/quaternions in types representing various mathematical groups. Or that I want to implement geometric algebra with wedge products and such. Or that I want to form matrices of elements from some finite field. Those sorts of things might push a person back to C++ (or maybe Nim can do it).
I love the SoA/array/matrix stuff though, and the "standard package" selections look great.
Matrices are built in(!), and look nicely implemented. So are complex numbers and quaternions!
The array programming aspects in general look great.
Zig might be the nicer language for a kernel or a server of some kind, but Odin looks like the better language not just for games, but also for robotics and for scientific programming.
The only problem I forsee is that it seems hard to write nice mathematical libraries for anything that isn't built in.
For example, suppose I want to work with polynomials using a natural infix syntax. Or that I want to wrap matrices/quaternions in types representing various mathematical groups. Or that I want to implement geometric algebra with wedge products and such. Or that I want to form matrices of elements from some finite field. Those sorts of things might push a person back to C++ (or maybe Nim can do it).
I love the SoA/array/matrix stuff though, and the "standard package" selections look great.
The best marketing for me is to see lots of useful/large projects using the language. That's why I invest time in Rust: lots of things are built on Rust, as the constant flow of "ABC written in Rust" posts on HN and other forums can attest to. Because that means that people who are good enough to write those things thought that Rust was a good choice.
Go is the same thing: I learned it because in devops it's the dominant language, which tells me it must be pretty good for those use cases (even if so many people dislike it, no one can claim it's not good enough).
I've looked into Odin and thought it was interesting, but given the amount of work being put into Zig, right now I feel like that's the safest choice (I must say I dislike how even basic things are still being changed in Zig, but no one said it would be otherwise so that's on me). Zig gives very tangible benefits, like not depending on just the LLVM (WIP) as a compiler backend, being able to compile to basically any combination of C stdlib/arch/OS from anywhere without worrying about toolchains and other things that I believe Odin lags behind, despite perhaps being the better language of the two when looking solely at its design (I am not too sure about that as I haven't used Odin for anything yet, and done very little Zig).
Go is the same thing: I learned it because in devops it's the dominant language, which tells me it must be pretty good for those use cases (even if so many people dislike it, no one can claim it's not good enough).
I've looked into Odin and thought it was interesting, but given the amount of work being put into Zig, right now I feel like that's the safest choice (I must say I dislike how even basic things are still being changed in Zig, but no one said it would be otherwise so that's on me). Zig gives very tangible benefits, like not depending on just the LLVM (WIP) as a compiler backend, being able to compile to basically any combination of C stdlib/arch/OS from anywhere without worrying about toolchains and other things that I believe Odin lags behind, despite perhaps being the better language of the two when looking solely at its design (I am not too sure about that as I haven't used Odin for anything yet, and done very little Zig).
Odin's issue isn't hypeabilty but Googleability. I think for while I had to type odin-lang to find resources on it instead of The Odin Project.
I actually really enjoyed the language back when I'd used it. One issue I think every language leaves out there is that the language is just a tool and increasingly only one part of a larger tool the IDE/SDK/Engine/Platform. I don't want to really learn a language so much as make useful programs.
Right now we all pay attention when someone announces their new language that's supposed to do things better than existing ones out there but there is a limit to what problems a new language can address.
If you want to make a game for the Switch/PlayStation/Xbox you'll need an SDK and likely can't even use anything but c or c++. If you don't want to make your own engine you'll use whatever languages the engine uses to get things done in. If you want to make a cross platform app that handles accessibility and internationalization you're going to be making a web or electron app.
As much as I am interested in APL, Lisp and smalltalk right now, I get stuck when I ask 'What project am I interested in using this in?'
I actually really enjoyed the language back when I'd used it. One issue I think every language leaves out there is that the language is just a tool and increasingly only one part of a larger tool the IDE/SDK/Engine/Platform. I don't want to really learn a language so much as make useful programs.
Right now we all pay attention when someone announces their new language that's supposed to do things better than existing ones out there but there is a limit to what problems a new language can address.
If you want to make a game for the Switch/PlayStation/Xbox you'll need an SDK and likely can't even use anything but c or c++. If you don't want to make your own engine you'll use whatever languages the engine uses to get things done in. If you want to make a cross platform app that handles accessibility and internationalization you're going to be making a web or electron app.
As much as I am interested in APL, Lisp and smalltalk right now, I get stuck when I ask 'What project am I interested in using this in?'
Arguably the reason why Odin has no or less Googleability, is it has no Wikipedia page, no books on Amazon, and few third party code examples at known places for programming enthusiasts. For any language to be taken seriously, their developers or fans should at least spend more time on that than hype.
The main thing it seems to have, is the hype and the cult of personality around its creator, ginger bill and lots of interviews and close ups of red hair. The problem with that, it becomes more about him and the bragging about his achievements.
> I don't want to really learn a language so much as make useful programs.
That's why instead of the language creator bragging about themselves, many users want to be taught or see examples of what the language can actually do for them. That starts with books, code examples, more demo projects, etc...
The main thing it seems to have, is the hype and the cult of personality around its creator, ginger bill and lots of interviews and close ups of red hair. The problem with that, it becomes more about him and the bragging about his achievements.
> I don't want to really learn a language so much as make useful programs.
That's why instead of the language creator bragging about themselves, many users want to be taught or see examples of what the language can actually do for them. That starts with books, code examples, more demo projects, etc...
As someone who's working in gamedev but never ever considered Odin I think that Odin might get more attention if there will be a well known project that is a)open b)good fit for Odin c) not too simplistic. I do not think a game project can be that open but something smaller might do. A project like this would make it clear how language tools work, all integrations and interoperability with languages and libraries look like and such. Even basic questions on build systems and text editor autocomplete setups may throw off hobby devs. Without a hobby project I feel a pro will not have enough information to evaluate language in production environment.
Would a 3d animation software like EmberGen[0] qualify? Because they already have it[1]. I think it's going to take something bigger, like a massively popular indie or AAA game that programmed their game in odin using an open source engine. Quite the needle to thread.
[0]: https://jangafx.com/software/embergen
[1]: https://odin-lang.org/showcase/embergen/
[0]: https://jangafx.com/software/embergen
[1]: https://odin-lang.org/showcase/embergen/
Yeah, we need to see how all the pieces fit together. The renderer, physics, UI, sound, input handling, asset loading and memory management.
Rather sure that the only way to market most anything is to make it very visible and quickly understandable (or have the appearance of). It's unclear to me what Ginger Bill expects from the language, a less used and well loved tool is good too (tee hee). Amongst whom should it be popular? How do you make as many of them as possible understand what problems it solves?
Money's a different question hey - there's more funding in open source than there used to be and you can really just ask for money and fill out paperwork and get grants and such if it's a useful project, otherwise it will need to embed into some kinds of important projects so that companies need to invest in it. Can Odin do that?
Asking the internet how to market a niche thing that they've never built is questionable at the outset though :v) Do wish the best for Odin though, it's kino.
Money's a different question hey - there's more funding in open source than there used to be and you can really just ask for money and fill out paperwork and get grants and such if it's a useful project, otherwise it will need to embed into some kinds of important projects so that companies need to invest in it. Can Odin do that?
Asking the internet how to market a niche thing that they've never built is questionable at the outset though :v) Do wish the best for Odin though, it's kino.
Get some of those annoying YouTuber “dev influencers” to cover it and that will get all the developer teenagers hyped about it. It almost goes without saying that the YouTuber should also be gurning in the thumbnail.
Great way to get freshly made developers to use something, but for the rest of us? Probably has the opposite effect if any.
Why brand a language via “annoying” influencers? The pro is obviously visibility, but doesn’t that switch the problem from visibility into reputation management?
Did you even do a search in youtube for "odin language"? Lots of dev influencers have covered odin, including an hour long interview the Primeagen did with GingerBill about odin.
https://www.youtube.com/watch?v=nVa9mgRcVPs
https://www.youtube.com/watch?v=nVa9mgRcVPs
> those “killer features” are usually absolute nonsense, very niche, or they rarely have any big benefit
This is a fantastic way to turn everyone off of your language: dismiss everything they like about the ones they're already using!
This is a fantastic way to turn everyone off of your language: dismiss everything they like about the ones they're already using!
Right? So I'm apparently an idiot for thinking Rust's borrow checker, or Go's blissful deployment experience, or Zig's clever comptime system are good... Ok I guess I'm not going to like Odin then.
Very often these days I read about memory management as a differentiating factor. On one hand there's Rust with more "manual" memory management (I think) opposed to Go with its indeterministic GC pauses (see Discord blog posts about why they prefer Rust to Go because of that). On the other hand there's Go with its very simple automatic memory management. Where does Odin fit in?
I see that there are two paragraphs on memory management (https://odin-lang.org/docs/overview/#allocators) in the overview but they dive into the details very soon and don't really paint the big picture (I think the sentence "This means that Odin programmers must manage their own memory, allocations, and tracking" is not a great selling point, all other things being equal).
I see that there are two paragraphs on memory management (https://odin-lang.org/docs/overview/#allocators) in the overview but they dive into the details very soon and don't really paint the big picture (I think the sentence "This means that Odin programmers must manage their own memory, allocations, and tracking" is not a great selling point, all other things being equal).
[deleted]
>And before people say: “Odin’s ‘killer feature’ is that it has none”, how the heck do you market that? That seems like an anti-marketing feature.
Correct me if i'm wrong but it seems to me that there are Zig, Nim, Dart, Carbon, C3, ooc, (maybe Eiffel?) too in this space, and that only counting C/C++ replacements that you can compile in a way or another.
Correct me if i'm wrong but it seems to me that there are Zig, Nim, Dart, Carbon, C3, ooc, (maybe Eiffel?) too in this space, and that only counting C/C++ replacements that you can compile in a way or another.
IMO, Nim's killer feature is it's syntax. It's even in it's slogan "Efficient, Expressive, Elegant".
HN crowd would not agree with me, but indentation-based syntax is easier to read, less cluttered and more intuitive than multiple nested ()'s or {}'s . And the success of python, despite it's countless flaws is the proof.
HN crowd would not agree with me, but indentation-based syntax is easier to read, less cluttered and more intuitive than multiple nested ()'s or {}'s . And the success of python, despite it's countless flaws is the proof.
Looking over the Odin docs, it seems to me that a short summary might be: Nim provides almost all the same sorts of things as Odin, but with more Python-y syntax, more meta-programming, automatic memory management with opt-out, and less (no) built-in support for multi-dimensional arrays {EDIT: though, of course, Nim has multiple external impls like ArrayMancer, etc. and having flexible syntax makes this mostly a rendezvous-on-one-thing problem}.
I also like the way Nim with its command calls and so on is even more compact and "to the point" than Python is. Whenever I go back to Python from Nim, I think to myself "Why all this clutter?" :-)
I also like the way Nim with its command calls and so on is even more compact and "to the point" than Python is. Whenever I go back to Python from Nim, I think to myself "Why all this clutter?" :-)
I hate python's syntax, it might be less cluttered but it's a pain to refactor or play around, because a lot of times you have to re-indent everything before it will work again. And then I also tend to find it harder to find the end of blocks. I think the success of C-style bracket syntax in most other languages apart from Python is the proof of how superior it is.
I love everything Nim but that. Spaces-only indentation forces you to write with an at least mediocre code editor and that's a gripe, for the rest it's just me that i'm C-brain-damaged, i even wrote an awk preprocessor for writing multi-line blocks with curly braces delimitation. I don't recommend my habits as the right way, they are probably the wrongest of ways.
> Spaces-only indentation forces you to write with an at least mediocre code editor
I don't understand how is that an issue, unless you write your code in notepad =).
And even if you do use dumb text editor, you can quickly write code with 1-space indentation and reformat it with nph[0].
There's also a neat trick for people who like C-style languages. If you use sufficiently enough parenthesis and semicolons - you don't need indentation at all:
0 - https://github.com/arnetheduck/nph
I don't understand how is that an issue, unless you write your code in notepad =).
And even if you do use dumb text editor, you can quickly write code with 1-space indentation and reformat it with nph[0].
There's also a neat trick for people who like C-style languages. If you use sufficiently enough parenthesis and semicolons - you don't need indentation at all:
import os;proc main = (let file = paramstr(1);(for line in file.lines:(echo line; if line == "": return)))
0 - https://github.com/arnetheduck/nph
> import os;proc main = (let file = paramstr(1);(for line in file.lines:(echo line; if line == "": return)))
Yeah, bliss-style, you know in docs it isn't made clear that that works but i sensed that would.
> Random thought: it shouldn't be too hard to write a formatting tool that translates braces to indentation and vice versa. But I have yet to see a project like this for Nim.
It's a hour-long "project" if you don't care about how to treat pragma annotations. I did just that.
Yeah, bliss-style, you know in docs it isn't made clear that that works but i sensed that would.
> Random thought: it shouldn't be too hard to write a formatting tool that translates braces to indentation and vice versa. But I have yet to see a project like this for Nim.
It's a hour-long "project" if you don't care about how to treat pragma annotations. I did just that.
>People expect a programming language and compiler to be free
Yes, they should both be free.
Yes, they should both be free.
My understanding of Odin is that it's a relatively thin layer of preprocessor around C. So.. C but nicer?
Hey dang, why was this story completely removed?
It was near the top an hour or so ago, and now I can't even find it!
It was near the top an hour or so ago, and now I can't even find it!
Try the standard HN web page; it has a Search: box at the bottom, which will take you to something like https://hn.algolia.com/?dateRange=pastWeek&page=0&prefix=fal...
My point was that it was no longer accessible via normal HN perusing (went through a couple pages of stories), which I found odd since it was fourth or some such an hour prior!
To the 1st q: comments > upvotes indicated that it was generating drama, pending judicial review (it’s a reasonably nonGoodhartian measure, impervious even to meta from the likes of we)
Fwiw i really like the top comment (also related to the differentiable (for Rao observers: hypernormal) beast at the heart of Goodhart’s law)
And the second comment hints at a possible interesting non-Varian framing of solutions to “common antiresource pool” (nonexcludable but rivalrous antigoods) problems
Fwiw i really like the top comment (also related to the differentiable (for Rao observers: hypernormal) beast at the heart of Goodhart’s law)
And the second comment hints at a possible interesting non-Varian framing of solutions to “common antiresource pool” (nonexcludable but rivalrous antigoods) problems
Interesting, thanks for the clarification!
before reading the article, i have to say that odin won't make it unless it will invest serious time into networking. graphics, which is where odin shines, is very niche market and i bet that once JB's Jai comes to public, it might crush odin in this field by sheer persona behind the language in this specific niche. what makes or breaks language is the ecosystem and abilities to use it in various domains. today, the internet/networking moves mountains. it's where the most engineering and money is. if you cannot write fast http/rest/grpc servers with most used databases, your language will fade away into obsolescence, because it might bring nice new features, but if it cannot be used in the most popular fields, it will not make it. and odin is suffering in this aspect tremendously. it has the simple go-inspired syntax going on, but it has no oop/methods, so right there you have an obstacle for new users - it is too different from the norm. it might have great integration with various graphics libraries but it if is too different and lacks the ecosystem of libraries, package manager... there is no reason for it to exist. it also requires GIGABYTES of crap you need to download on windows in order to be able to compile a program. it also needs IDE support, mostly jetbrains, visual studio and vs code, which are the dominant IDEs today. in short, if it lacks convenience of Go or Zig, or even Rust, there really is no point in investing time into it.
PS: this is just off the cuff comment, not too thought out. also, Odin has a chance to beat Zig, due to better syntax and being essentially complete, beside having official spec. Which is not the case of Zig. Zig has traction but lacks in areas where Odin does not. So I would focus on Zig as the competitor, Rust as second. The simplified go-like syntax is one of the main selling points. But there must be more to the language.
PPS: I think the choice of ^ to handle pointers is one of the worst decision in the syntax. The * and & are the norm and should not be messed with.
PS: this is just off the cuff comment, not too thought out. also, Odin has a chance to beat Zig, due to better syntax and being essentially complete, beside having official spec. Which is not the case of Zig. Zig has traction but lacks in areas where Odin does not. So I would focus on Zig as the competitor, Rust as second. The simplified go-like syntax is one of the main selling points. But there must be more to the language.
PPS: I think the choice of ^ to handle pointers is one of the worst decision in the syntax. The * and & are the norm and should not be messed with.
> it also requires GIGABYTES of crap you need to download on windows
I was surprised by this since all I need on Linux is llvm and clang, but looking at the official getting started page, it does indeed say "MSVC compiler and windows SDK" are required. Is that really the only way to run it on windows, or is that just the path most familiar to a typical windows developer?
I personally disagree with saying it requires IDE support. I want to write a ctags parser for it, but that's all I would ever use; as a die-hard vim user, I never liked all the language server stuff people are so reliant on these days. But if that's what people want to use, it's available for Odin as well: https://odin-lang.org/showcase/ols/ -or- https://github.com/DanielGavin/ols
I was surprised by this since all I need on Linux is llvm and clang, but looking at the official getting started page, it does indeed say "MSVC compiler and windows SDK" are required. Is that really the only way to run it on windows, or is that just the path most familiar to a typical windows developer?
I personally disagree with saying it requires IDE support. I want to write a ctags parser for it, but that's all I would ever use; as a die-hard vim user, I never liked all the language server stuff people are so reliant on these days. But if that's what people want to use, it's available for Odin as well: https://odin-lang.org/showcase/ols/ -or- https://github.com/DanielGavin/ols
iirc it is about 6 or 7 GB on windows that you need to install. Zig can do it in 75MB, Go i think around the same. Rust has the same problem though.
As for IDE, people who use plain editors like vim, emacs... exist but their numbers are merely a statistical error compared to people that use IDEs(i am counting VS code into this category even though it's just electron). Of course we could debate what is and what is not IDE, but the point here is that we need syntax highlighting, refactoring, jumping to definitions, finding usages and other functionality that IDEs provide.
As for IDE, people who use plain editors like vim, emacs... exist but their numbers are merely a statistical error compared to people that use IDEs(i am counting VS code into this category even though it's just electron). Of course we could debate what is and what is not IDE, but the point here is that we need syntax highlighting, refactoring, jumping to definitions, finding usages and other functionality that IDEs provide.
It is the way to get the platform linker, and so if you’re using a Windows native toolchain, that’s what you have to do.
IIRC there are slimmer packages to get it but you’re still talking a gigabyte, not tens of megs.
IIRC there are slimmer packages to get it but you’re still talking a gigabyte, not tens of megs.
And not being dependent on the platform linker was a massive undertaking in Zig... I don't think many languages actually implemented their own cross-platform linker.
But anyway, if you're in the Odin target audience on Windows you most likely have Visual Studio installed anyway. Also IIRC even Clang and Rust depend on the MSVC linker on Windows, Zig is really an "outlier" (in a good way) in that regard.
But anyway, if you're in the Odin target audience on Windows you most likely have Visual Studio installed anyway. Also IIRC even Clang and Rust depend on the MSVC linker on Windows, Zig is really an "outlier" (in a good way) in that regard.
I can't think of any language where networking (or graphics for that matter) is built into the language.
At best you get support in the standard lib, but whether things like this should go into the stdlib or 3rd party libs is a decision that isn't set in stone forever, and probably doesn't even matter if it is easy to integrate 3rd party libs into Odin projects. AFAIK Odin has the concept of vendor libraries, which live somewhere between stdlib and 3rd party - so networking could go there).
Compared to Zig specifically, Odin has a couple of language features that might make it less pure from an academic language designers pov, but more convenient from the user's pov and only the last one matters for getting shit done. I wouldn't dismiss Odin only because it doesn't have features XYZ, because it does some other things very right compared to other languages.
Re IDE integration, google for "Odin language server".
At best you get support in the standard lib, but whether things like this should go into the stdlib or 3rd party libs is a decision that isn't set in stone forever, and probably doesn't even matter if it is easy to integrate 3rd party libs into Odin projects. AFAIK Odin has the concept of vendor libraries, which live somewhere between stdlib and 3rd party - so networking could go there).
Compared to Zig specifically, Odin has a couple of language features that might make it less pure from an academic language designers pov, but more convenient from the user's pov and only the last one matters for getting shit done. I wouldn't dismiss Odin only because it doesn't have features XYZ, because it does some other things very right compared to other languages.
Re IDE integration, google for "Odin language server".
>I can't think of any language where networking (or graphics for that matter) is built into the language.
Erlang has cluster aware message passing built in as a fundamental aspect of the language.
Erlang has cluster aware message passing built in as a fundamental aspect of the language.
go has both in the stdlib
the networking does not necessarily has to be in standard library, but there has to be some "official" package/library that handles these things on a superb level and is ready to go in an instant. for odin, there is one http server in the works, and according to bil it will be the "official" package but when you look at it, it is VERY lacking in many aspects. it's more like a guy made a library that kinda works, but it's nowhere near the expected standard and performance one expects.
That's probably relative to the few contributors on the project. Until recently, was even worse, as was mainly a one-man show. This can be seen by checking the contribution history.
.NET languages, Python, Java.
C++ before the days of C++98, when each C++ compiler vendor provided a nice C++ framework alongside their compiler.
C++ before the days of C++98, when each C++ compiler vendor provided a nice C++ framework alongside their compiler.
* for pointers was a stupid choice and there's no reason to keep it solely because people are used to it. Why not keep prefix dereference too? The syntax is attrocious but hey, C does it, so everyone else must.
What’s the problem with *? Do you just want a different symbol or an entirely different syntax?
Not the OP, but the '*' is already the common symbol for multiplication.
Not much of a problem for people who are used to C syntax of course, but may be confusing to anybody else, especially in expressions which have both pointer dereference and multiplication, for instance this is entirely valid C:
Not much of a problem for people who are used to C syntax of course, but may be confusing to anybody else, especially in expressions which have both pointer dereference and multiplication, for instance this is entirely valid C:
int a = 3 ** int_ptr;
That's horrifying, I think I would have preferred
int a = powl(3,int_ptr);
I’m not sure I understand your comment, wasn’t the point that
int a = 3 ** int_ptr;
It was a confusion between ** used as the rise to power operator in languages like Fortran or Python which just validated the grandparent point of confusing syntax for people not used with C that come from other programming languages.
In Python and Fortran for example:
In Python and Fortran for example:
3 ** 2 = 9See, it is confusing, because the code doesn't compute a power.
It's a multiplication with the value pointed to by int_ptr, e.g. rewritten to make more sense:
It's a multiplication with the value pointed to by int_ptr, e.g. rewritten to make more sense:
int a = 3 * (*int_ptr);
a := 3 * int_ptr^That's not what the code does.
3 ** int_ptr multiplies the vakue pointed at by int_ptr by 3. It is exactly the same code as 3 * (*int_ptr) which is the point the parent was making.
powl(3, int_ptr) would be (int)int_ptr * (int)int_ptr * (int)int_ptr which is also unlikely what you wanted. You probably wanted to say powl(3, *int_ptr)
EDIT: actually even my last paragraph is wrong because the first arg is base... I'm not going to write it out but you get the point...
3 ** int_ptr multiplies the vakue pointed at by int_ptr by 3. It is exactly the same code as 3 * (*int_ptr) which is the point the parent was making.
powl(3, int_ptr) would be (int)int_ptr * (int)int_ptr * (int)int_ptr which is also unlikely what you wanted. You probably wanted to say powl(3, *int_ptr)
EDIT: actually even my last paragraph is wrong because the first arg is base... I'm not going to write it out but you get the point...
Related: I like the "down to" operator: https://stackoverflow.com/questions/1642028/what-is-the-oper...
(No, it's not a real operator, it's another case of weird but allowed spacing causing confusion)
(No, it's not a real operator, it's another case of weird but allowed spacing causing confusion)
Ritchie's paper on the history of C discusses that prefix dereference thing: another Bell Labs researcher pointed out that C's notorious issues with declaration syntax, etc., would work much better if pointer deref were postfix instead. Ritchie said it was already too late by then to fix it in C, but didn't contradict the point.
Odin had no such block to improvement. Props to them.
Odin had no such block to improvement. Props to them.
> by sheer persona behind the language in this specific niche.
"Persona oriented development" (POP) when?
"Persona oriented development" (POP) when?
Will Jai be public? From the outside, it seems like the creator is using it to build his own software, but doesn't have that much interest in making it public? (which is fine, but I was surprised to hear talk of its impending release)
He wants to release it once it’s features and stdlib are stable; right now there’s a few things left to change so it’s not ready for release yet.
That may not be a bad idea by itself. With Zig they told people to not use it in production as it's still unstable, but of course people proceeded to use it in production, and now there's an incentive for the developers to avoid too many breaking changes. I don't know if that actually matters, but from what I've seen Jon Blow doesn't seem like the kind of person who wants half the internet to tell him how to do things or listen to complaints about a change he made.
It's already been a decade. Maybe someday it will happen but no sense in holding your breath. From an intellectual curiosity standpoint I don't think it actually helps to discuss Jai because it's not something we can form falsifiable theories about. For anyone not already bought in, not already in Jon's ingroup, it may as well not exist.
JB had a stream couple of weeks ago where he summarized that three things prevent the language to go public and he is working on them. hopefully next year should all be done.
> PPS: I think the choice of ^ to handle pointers is one of the worst decision in the syntax.
Funny that's my favourite aspect of Odin's syntax.
I also like the convention of the type on the left and its usage on the right:
And with structs:
Funny that's my favourite aspect of Odin's syntax.
p: ^int
I also like the convention of the type on the left and its usage on the right:
p: ^int // ^ on the left
x := p^ // ^ on the right
And with structs:
p^.x // not necessary
p.x // this will dothe main problem is keyboard layout and lack of easy access to ^ in most of them. not everyone uses US layout, it's actually minority of computer users. plus, the notion of whether the ^ goes before or after variable can cause a lot of programming and code reviewing issues. but it's just a personal opinion, obviously.
What layout specifically is a problem?
Odin uses curly braces which (in QWERTY) are shifted and typed with your pinky—the worst possible combination. Are there layouts where ^ is worse than that?
Odin uses curly braces which (in QWERTY) are shifted and typed with your pinky—the worst possible combination. Are there layouts where ^ is worse than that?
this could result in endless thread so all i will say is that you have * physically available as stand-alone key on the numerical side of every keyboard ever made(unless you are a weirdo(=micro minority) and use the variously mutilated physical keyboard layouts) and & is physically available as stand-alone key on iso 105 layout, for example, but most importantly it is a character widely used in most languages as actual character, whereas ^ is really not.
Moving your whole hand off home row to hit numpad * is even worse than shift-pinky.
try using your right hand ʕ·͡ᴥ·ʔ
If you think it's ergonomic to move your entire hand away from the letters to press a frequently used key, well... I guess now I understand why Odin's creator disagrees with you about keyboard layouts! ^_^
OTH accessing { and } on non US layouts is pretty much the worst case but people deal with it just fine.
From a look at Odin's site, its pitch sounds awfully similar to Zig
It seems that Odin and Zig target similar use cases.
How do they compare?
How do they compare?
I evaluated both some time ago. The standout difference for me was Zig requires you initialize all variables and struct fields explicitly, but Odin implicitly initializes variables and forgotten struct fields to their "zero value" (0/null).
Zig allows default values in the struct declaration which eases the pain quite a bit (while still making it impossible to forget initializing items).
Funny you should say that. I don't find it painful at all, I prefer the explicitness. I just wanted to relay my experience without unnecessarily bundling my opinion, since this is a thread about Odin after all.
This is a tiny difference in the context of all language design decisions!
[deleted]
Here are some references, I think Odin is more tasteful and sensible with a cleaner syntax.
https://www.gingerbill.org/article/2019/05/13/a-reply-to-the...
https://www.youtube.com/watch?v=vFFcCLzOOyw&t=676s
https://news.ycombinator.com/item?id=36162056
https://www.gingerbill.org/article/2019/05/13/a-reply-to-the...
https://www.youtube.com/watch?v=vFFcCLzOOyw&t=676s
https://news.ycombinator.com/item?id=36162056
Otherwise, I'm generally a fan of Odin, but I do find it quite irritating that only place to ask questions and participate in the "community" is locked behind discord. I even gritted my teeth and tried to make an account for discord just for this, but discord wouldn't accept my (apparently mandatory) phone number. Community questions and answers need to be readable and searchable without yet another login. If I'm learning a language and can't find an answer to a question that was almost certainly asked already, that's just another stumbling block that will prevent me from using said language.