Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

41–50 of 211 posts

Re: I like Odin

#41

What happens when you mutate the target of a pointer to the same memory as the target of an "immutable" reference (eg. function parameters and union switches)?

If I understand correctly, procedure parameters are only immutable in the scope of the procedure because the compiler will decide wether to pass them by value or reference.

At the calling scope, the parameter passed is not immutable. You can pass a pointer too, if you want.

There's also this pattern:

    name := name
which redeclares name in the current scope and shadows the name that exists in the outer scope

    call :: proc(b: int) {
        fmt.println(b)
        // c := &b // illegal!
        // b = 10 // illegal!
        b := b
        b = 10;
        fmt.println(b)
    }

Re: I like Odin

#42

Memory unsafety (by default without opt-in) is being treated like a feature in these newer languages.

That's because memory safety has a price: either a GC (which creates interoperability issues if you have two languages with GCs..) or a complexity price like in Rust..

So these languages stay memory unsafe but tries to minimise the issues caused by the lack of safety.

Re: I like Odin

#44

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…

The wikipedia definition of systems programming seems to exclude it

https://en.wikipedia.org/wiki/Systems_programming

Re: I like Odin

#45

Earlier quoted context omitted.

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

> Code that doesn’t create these types isn’t possible to have runtime errors

Rust code can still panic and unwind at runtime. There's some ongoing work on supporting guaranteed-not-to-panic code for very specific uses (similar for guaranteed-not-to-leak, which is a related problem), but it's a long way off and will not be applicable to anything that must interact with the system in any way.

Re: I like Odin

#46

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…

Yeah this kind of framing always rubs me the wrong way. I don't "dread" manual memory management. Indeed, from a personal standpoint I really like thinking about stuff like that while I'm programming. It's part of the fun puzzle aspect that got me into all this. But as a professional, I know that there is heaps of evidence over many decades that it is unwise for me to indulge this fancy, when working on real systems that real people use and which may be exposed to the internet. I consider it a bummer, but I'm very persuaded that this is unwise for pretty much all of the software I work on.

Re: I like Odin

#47
I like how newer languages with a C style syntax have more readable type declaration mechanisms than C (some even Pascal-like to an extent).

But I am not sure what I would prefer in some cases when looking at these new languages.

For example doing some alloc/pointer stuff in Odin is like:

    ptr := new(int)    
    ptr^ = 123    
    x: int = ptr^    
    free(ptr)
And in Hare:

    let ptr: *int = alloc(123);    
    let x: int = *ptr;
    free(ptr);
Which approach do you prefer, and why?

Re: I like Odin

#48
post #10
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#.

When Go was first announced ~2009, Rob Pike explicitly framed it as a systems language https://www.youtube.com/watch?v=rKnDgT73v8s I would not say it's the same as Java or C#. The crucial difference is that it compiles to a native executable binary file, not something that needs a virtual machine.

C programs are executed inside the C virtual machine.

Re: I like Odin

#49
post #17

i had to stop reading cause of all the ads ! Bloody hell !

I hadn't realized all the ads until I tried to read it from my mobile. Here's an alternative link (substack): https://hasen.substack.com/p/odin-praise

Firefox mobile works with adblockers ..

Re: I like Odin

#50

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.

And the compoper error messages are fantastic for beginners.
Post reply on HN