Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

31–40 of 211 posts

Re: I like Odin

#31

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulner…

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.

Re: I like Odin

#32
post #2

> As someone who is interested in systems programming, and has experience working with Go I wonder how Go got it's reputation as a systems language. Imo, it occupies the same abstraction level as Java or C#.

I always interpreted go "system" as networked async systems and not electronic chip systems.

I think this makes sense considering that most of the cloud-native software is written with Go. (Docker / Podman, Kubernetes, Helm, Istio, Terraform, etc.)

Re: I like Odin

#33

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulner…

I think Rust is what you need. It basically won’t compile if your code would have runtime errors or memory leaks, except for cases you need to explicitly handle. The linters in VSCode also make it pretty practical to use. It’s been a joy to program in since I started about a month ago.

Re: I like Odin

#34

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulner…

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.

Re: I like Odin

#35

A small but (IMHO) very neat detail is the Pascal-style syntax for defining variables (without requiring a separate 'var' or 'let' keyword): // inferred type: a := 23 // explicitly typed, the type is squeezed between the : and = a : u32 = 23 OTH constants now require special syntax: a :: 23 ...but at least this is consistent with other places in the language, like functions: my_func :: proc(...) ...and 'squeezing in…

So, the pattern is:

     : [type] : 
       : [type] = 
where the type is always optional as it can be inferred?

That's why `a :: 32` declares a constant, but `a := 32` declares a variable...

This is pretty neat, actually.

Re: I like Odin

#36

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.

That's fair. Go is not as fast and cannot manage resources as well as the languages you mentioned.

Re: I like Odin

#37
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…

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 aspects (mainly that the compiler is open source, but also that it’s already being used in production...

Totally agree with you here. It could be argued that Jai has fumbled its advantage or at least the window of opportunity to claim its more innovative or more game program friendly than other languages. Odin has pretty much covered that gap, so that most of what people liked about Jai, is in Odin and can be used today.

Re: I like Odin

#38

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulner…

I think Rust is what you need. It basically won’t compile if your code would have runtime errors or memory leaks, except for cases you need to explicitly handle. The linters in VSCode also make it pretty practical to use. It’s been a joy to program in since I started about a month ago.

> It basically won’t compile if your code would have runtime errors or memory leaks

While Rust does move a lot of errors from runtime to compile time, there are still a lot of ways to create runtime errors (which must obviously the case if your program handles any input at all).

Rust also does not stop you from creating memory leaks; there's even the `Box::leak()` method[1] that allows you to simply leak a heap allocation.

[1]: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...

Re: I like Odin

#39

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulner…

Rust sounds like what you want, though be prepared to deal with near C++ levels of complexity at times (lots of Rust code is too macro happy for my tastes).

That said, the way to deal with memory management in C is to... not do much of it. I know that sounds like a cop-out but the patterns you're supposed to use in languages like Zig and Odin are the same ones you'd use in C to keep your mind sane.

Do not do Reference Counting or Single Owner + Borrowing (RAII), it'll drive you insane without the automation languages like Swift and Rust or C++ give you.

Instead, the way you're supposed to do things, are big "manager objects". Only these manager objects are ever explicitly allocated and freed, everything stored within them is managed by them and they expose only safe handles to the outside world (e.g. generational handles).

Most of the time these manager objects will store some dynamic arrays, hash maps or pools within them that get freed when they are also freed. Note that unlike RAII there is no real "nesting". The managers are responsible for the lifetimes of their whole "object tree".

Any temporary data should be allocated using a temporary allocator (like an Arena allocator) which gets freed at the appropriate place for the application (end of a frame in a game, or end of a request in a web server). Never store pointers to something within the temporary allocator in "long lived" data structures inside the manager object.

Follow these rules and things get manageable, Zig and Odin have lots of facilities in their standard libraries to make this easier, in C you're mostly on your own but there are some libraries you could use like the Apache Portable Runtime.

Re: I like Odin

#40

Earlier quoted context omitted.

I think Rust is what you need. It basically won’t compile if your code would have runtime errors or memory leaks, except for cases you need to explicitly handle. The linters in VSCode also make it pretty practical to use. It’s been a joy to program in since I started about a month ago.

> It basically won’t compile if your code would have runtime errors or memory leaks While Rust does move a lot of errors from runtime to compile time, there are still a lot of ways to create runtime errors (which must obviously the case if your program handles any input at all). Rust also does not stop you from creating memory leaks; there's even the `Box::leak()` method[1] that allows you to simply leak a heap alloc…

The difference is you need to explicitly handle cases that would cause runtime errors where you have to use .unwrap() or match selectors, which makes it safer in general. Since the values are wrapped in Result or Option enums. Code that doesn’t create these types isn’t possible to have runtime errors which reduces cognitive burden when coding.

And yes you can write non-idiomatic Rust that lets you leak memory but it doesn’t happen by accident like in C/C++.

Post reply on HN