Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

Post reply on HN
Print view View original

101–110 of 211 posts

Re: I like Odin

#101

Post by gingerBill »

greaterthan3 wrote: post #61

When I'm evaluating an open-source project, I always check the quality of its commit messages. I don't care about following a specific format or something, all that matters is whether they are informative or not. Sadly, Odin doesn't seem to pass the test. It's full of commits labeled with just "fix ": https://github.com/odin-lang/Odin/commits/master A few examples of projects with better commit messages: Linux kernel…

Hello, I am the creator of the Odin programming language, and main architect of the codebase too. Being full of commits labelled "Fix " is absolutely fine and absolutely clear with all of the context of how the codebase operates.

Many of the things are "Fix #NNN` which means fixing a specific GitHub issue which usually has more information to it or has comments in the code, etc. There are many "Fix typo(s)" commits because I (and others) make a lot of typos; these are usually trivial/single-line fixes. Then it comes to the rest of "Fix ..." commits which are pretty much 1-2 line fixes of minor bugs; with large bugs having multi-line commit messages and many with huge comments within the code to explain everything.

Your metric of the quality of commit messages is not a bad one depending on the codebase, but it cannot be used blindly without knowing how that codebase operates. Especially comparing a mostly centralized codebases (like Odin) to very GNU-style decentralized codebases (all of the examples you gave).

Re: I like Odin

#102

Post by abainbridge »

ameliaquining wrote: post #94
sanderjd wrote: post #71

Earlier quoted context omitted.

By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…

GP's solutions to problems 1 and 2 are the same as Rust's; the difference is problem 3 ("temporal memory safety"). Rust solves this problem with statically analyzed lifetimes, which, in addition to the safety and correctness advantages of compile-time checking, also permit RAII (which answers your "natural question" with "no, it's not necessary to do that"), which makes programming more pleasant. The disadvantage is,…

I agree with all of that. How theoretical are the optimization gains from the extra constraints guaranteed by Rust's borrow checker?

Re: I like Odin

#103

Post by sanderjd »

ameliaquining wrote: post #94
sanderjd wrote: post #71

Earlier quoted context omitted.

By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…

GP's solutions to problems 1 and 2 are the same as Rust's; the difference is problem 3 ("temporal memory safety"). Rust solves this problem with statically analyzed lifetimes, which, in addition to the safety and correctness advantages of compile-time checking, also permit RAII (which answers your "natural question" with "no, it's not necessary to do that"), which makes programming more pleasant. The disadvantage is,…

Well put!

Re: I like Odin

#104

Post by sanderjd »

abainbridge wrote: post #97
sanderjd wrote: post #71

Earlier quoted context omitted.

By "manual memory management", I think of explicitly allocating and freeing memory. Assuming you're thinking of the same thing, are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? If so, the natural question is, why is it necessary to manually insert the allocations and frees, if the compiler knows where they are supposed to go? This path leads you to something li…

> Assuming you're thinking of the same thing Yes. > are you suggesting that the compiler (or other static analysis) could catch all of the issues you listed? Yes, the compiler for the first two and the standard library's heap implementation for the third. > This path leads you to something like Rust There are stops along this path before you get to Rust. If you just add the 3 things I mention above to a C like langua…

That makes sense! This isn't the set of tradeoffs that most appeals to me, but I can see your point that it's a different set of trade offs that may be good ones.

Re: I like Odin

#105

Post by tadfisher »

jeberle wrote: post #82

I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly. It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible. 0 https://github.com/ziglang/zig/issues/1097

My fingers hate snake_case unless I'm in an IDE with working auto complete, and even then the repeated "shift-minus" when defining variables/functions is just hell on my typing speed. I don't have to remap my keyboard to avoid RSI when using camelCase, and I also don't have to switch keyboard apps on my phone when typing code examples.

Re: I like Odin

#106

Post by MH15 »

ithrow wrote: post #96
jeberle wrote: post #82

I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly. It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible. 0 https://github.com/ziglang/zig/issues/1097

curious, why do you prefer snake_case to kebab-case?

kebab-case conflicts with binary expressions, specifically subtraction? Some parser jujitsu would be required to fix this.

Re: I like Odin

#107

Post by MH15 »

hestefisk wrote: post #91

FWIW, the Odin compiler seems to be written in C++. Are there any plans to make it self hosted?

The creator is explicitly against a self-hosted compiler, for better or worse.

Re: I like Odin

#108

Post by account-5 »

jeberle wrote: post #82

I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly. It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible. 0 https://github.com/ziglang/zig/issues/1097

I much prefer camelCase over snake_case. No idea why.

Re: I like Odin

#109

Post by Tozen »

renox wrote: post #65
Tozen wrote: post #37

Earlier quoted context omitted.

I see it more as Odin has a very strong Go-like foundation, and then borrowed heavily from Jai too, in terms of syntax and various features. So that superficially, it looks like Jai. To the point, people could think it was a clone or fork. Also, Jai is a lot more Go-like than many people realize. When Jai diverges from various C/C++ concepts and traditions, it can do so in Go-like ways. > ...Odin is ahead by many asp…

I wouldn't say that it has a very strong Go fondation because it seems that Odin doesn't have an equivalent to God's channels..

Well, such things can be subjective. Yes, Odin does not do concurrency and channels. This appears to be because Odin doesn't do automatic memory management, and has more limits on the language, in terms of focus. It can be argued that Odin adapted itself to being a strong Jai alternative and appealing to gaming, versus more general purpose.

My understanding is that Odin does not plan to ever attempt to put concurrency nor channels into the language. It looks like that some type of workaround, if it ever happens, will have to be implemented by a 3rd party library.

It should be added, Vlang (the other Go alternative mentioned) because it was designed for various memory management options (both automatic and manual), does do concurrency and channels (https://github.com/vlang/v/blob/master/doc/docs.md#concurren...). Vlang aims to be more general purpose versus more specific.

Re: I like Odin

#110

Post by avgcorrection »

ithrow wrote: post #96
jeberle wrote: post #82

I'm happy to see Odin chose snake_case instead of camelCase. At one time Zig debated switching to snake case, but that ship has sailed [0], sadly. It seems like a small bike-shed level comment, but when I consider the code I have left in me, I'd like it to look as nice as possible. 0 https://github.com/ziglang/zig/issues/1097

curious, why do you prefer snake_case to kebab-case?

I prefer kebab-case but it’s apparently too much to ask for in infix languages because most of them insist on allowing expressions like `a+b-c`.
Post reply on HN