Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

111–120 of 211 posts

Re: I like Odin

#111
post #12

I think the reason why he is liking Odin, as a person who used Go, is because it's arguably an offshoot language of Go. Odin ( https://odin-lang.org/docs/overview/ ) has borrowed a lot from Go, which can be easily detected in various syntax and concepts. Another language which is in both the C and Go alternative language category, is Vlang ( https://github.com/vlang/v/blob/master/doc/docs.md ). For anybody that has u…

You can’t conclude that a language has taken direct inspiration from another just because they look similar.

https://odin-lang.org/docs/faq/#what-have-been-the-major-inf...

Fortunately there's a FAQ, and from that there are two Rob Pike languages (Newsqueak and Go) as well as a pair of Wirth languages (Pascal, Oberon-2).

Re: I like Odin

#112
post #106
post #96

Earlier quoted context omitted.

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.

Generally, kebab-case means that operators must be separated by spaces. Languages like FORTH or LISP might not even treat operators as separate from ordinary functions.

Re: I like Odin

#113
post #98

I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change. And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this proble…

And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. And that's absolutely fine, but don't criticize something which other people REQUIRE and DESIRE. You cannot "solve memory management" because there isn't just "one problem".

As for RAII, the article itself showcases some of the alternatives Odin has with the `defer` statement and `deferred_*` attributes. So Odin can have many of the aspects of RAII without tying it directly to a data-type/struct/class, which itself as many costs and trade-offs. RAII has loads of problems to it and many other things which are required to solve those problems.

This language is just not for you, and that is absolutely fine! But don't proclaim that it's "ignoring the biggest problem that needs solving" when you are assuming everyone has the same needs, requires, and desires as yourself.

n.b. I am the creator of the Odin programming language; go use a language that will help you solve your problems with your requirements.

Re: I like Odin

#114

Earlier quoted context omitted.

You can’t conclude that a language has taken direct inspiration from another just because they look similar.

https://odin-lang.org/docs/faq/#what-have-been-the-major-inf... Fortunately there's a FAQ, and from that there are two Rob Pike languages (Newsqueak and Go) as well as a pair of Wirth languages (Pascal, Oberon-2).

That’s fair. That’s however not what the OP claimed, which is what I was responding to.

Re: I like Odin

#115
post #37

Earlier quoted context omitted.

In terms of actual features though (ignoring trivial syntax), Odin resembles more of Jai. In fact, when I first found about it a few years earlier I though it was an open source clone of Jai. Today many features have diverged since then, and Odin is ahead by many aspects (mainly that the compiler is open source, but also that it’s already being used in production via EmberGen). I still really want the full metaprogra…

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…

> To the point, people could think it was a clone or fork.

You can’t clone code from YouTube videos (practically speaking).

Re: I like Odin

#116
post #98

I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change. And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this proble…

And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. And that's absolutely fine, but don't criticize something which other people REQUIRE and DESIRE. You cannot "solve memory management" because there isn't just "one problem". As for RAII, the article itself showcases some of the alternatives Odin has with the `defer` statement and `deferred_*` a…

But safe memory management is the biggest problem that needs solving. It’s empirically impossible for humans to write secure, complex programs while managing memory by hand.

I agree with OP, that Odin doesn’t go far enough toward safety in this regard. We do all require and desire security.

Re: I like Odin

#117
post #98

I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change. And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this proble…

And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. And that's absolutely fine, but don't criticize something which other people REQUIRE and DESIRE. You cannot "solve memory management" because there isn't just "one problem". As for RAII, the article itself showcases some of the alternatives Odin has with the `defer` statement and `deferred_*` a…

Quite the outlashing.

One can use both default RAII in a programming language as well as opt-in unsafe memory management. So you are clearly wrong in your assumptions about what the OP must clearly not require/want.

Re: I like Odin

#118
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 totally understand the preference, as using snake_case has grown on me. But, when you jump between many languages (with different case usage), you kind of have to be agnostic about such things.

Re: I like Odin

#119

Earlier quoted context omitted.

Seems like you need Go then? You mention you want memory management, type safety and proper abstractions, hence the suggestion. Of course, you also mentioned C's syntax as awkward for you, so you might feel the same with Go's syntax.

Go is not a fast language compared to C/C++/Rust. It’s more in line with Java as it’s also garbage collected.

Go, despite using GC, is still a compiled language. From what I've seen (including various test results), Go is usually faster than Java.

There is also the issue of, what is fast enough? A lot of times, people don't really have the speed requirements they say or think they do. To include the code they have written, could be better optimized. It's often better to be more specific about what the requirements are, before making blanket statements about a language not being fast enough. Clearly, many people are fine with how fast Go is.

Re: I like Odin

#120
The most important aspect of a system programming language, besides performance, is the readability of the code.

It will always be more difficult to read (and understand) a program than to write it, so, unless this is some throw away code, ease of reading should be the priority.

Unfortunately, the speed/ease of writing is often used instead.

Ease of reading means linear, boring, plain English with minimal use of arcane symbols or regex-like expressions.

In this regard, meta-programming is very often counter-productive, as it can introduce new idioms and constructs in the language that have to be understood before reading the program itself.

Overuse of C macros or C++ templates comes to mind, but I think that lack of readability was also a huge problem for LISP and Forth.

Post reply on HN