I like Odin • Hacker News Board

Re: I like Odin

#171

Post by gingerBill » Sun, Aug 28, 2022, 7:57 PM UTC

avgcorrection wrote: post #21

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

I've replied to you before on this in other comments. (here is one such example: https://news.ycombinator.com/item?id=32629951)

Odin has numerous memory safety features enabled by default. Having manual memory management does not entail no "memory safety". You could easily have a language with GC or ARC and still have all of the unsafe features of C. Objective-C is a brilliant example of this.

Many memory safety can be achieved with many constructs such as:

* Bounds checking for array-like types

* Having no pointer arithmetic

* Having distinct typing (virtually no implicit type conversions)

* Having no array-to-pointer demotion like in C (combination of the above to problems)

* Having actually decent array types: fixed-length arrays, slices, dynamic arrays, #soa arrays, etc

* Have length-bound strings rather NUL-terminated strings

* `Maybe(^T)` type to allow for non-nil pointers to be explicitly checked

* Built-in discriminated `union`s (of which `Maybe` is just one of those)

* Virtual Memory Protects

* And many more!

Most of the unsafe features in C/C++ come from most of the above features, especially pointer-semantics and the lack of a decent array type.

What Odin does not offer is ownership semantics and lifetime semantics, which is an entire discuss to itself which I won't talk in this comment.

Re: I like Odin

#172

Post by hsn915 » Sun, Aug 28, 2022, 8:14 PM UTC

sanderjd wrote: post #46

ceronman wrote: post #28

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…

If you had this belief say, 10 years ago, and because of it you decided to write your serious application in say, Java, you would have been in for a huge unexpected surprise last year when the now infamous log4j vulnerability was made public.

See, having memory safety did not prevent the language from causing arbitrary code execution vulnerabilities. Having the log4j project be open source and popular did not prevent that either (so much for the "enough eye balls" theory).

Going back to Odin, when I think memory safety is not as big a concern as people make it out to be:

Your only source of concern is C.

This would be like judging SQL statements as fundamentally unsafe because websites written in PHP tended to (specially in the early 2000) be written in a very unsafe manner where user input was put directly into SQL strings.

The lesson that people took is not to throw SQL out the window, but to properly sanitize user input before passing to the queries, and to never use plain string concatenation when doing that.

So for manual memory management, the lesson to take from the vulnerabilities that C has caused is not that manual memory mangement is bad. It's that you need some facilities in the language to minimize the chance of them occurring by several orders of magnitude.

Odin does this by providing the slice type (and string type) that have their length known and providing several custom allocators out of the box.

The cool thing about the slice type is not just that the length is known: the language provides facilities for iterating over the slice that automatically never goes out of bound:

    for item, index in slice {
        // do something
    }

This, and providing a "string builder" type into the core library that lets you dynamically construct a string in a safe way (you don't have to write the code to grow the string dynamically because it has already been done).

These features make the "fear" of unsafe memory access largely unwarranted anymore.

What remains is a matter of what attracts you to programming: are you interested in having explicit control over a system to make it do what you want, or are you more interested in expressing some abstract ideas in an abstract mathematical virtual machine? If the latter, you might find Haskell or Lisp more appealing.

Re: I like Odin

#173

Post by WaffleIronMaker » Sun, Aug 28, 2022, 8:15 PM UTC

dqpb wrote: post #143

sirwhinesalot wrote: post #39

Earlier quoted context omitted.

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

I’ll admit, the fact that Hello World requires a macro, dissuaded me from learning Rust for years.

Technically, you don't need a macro at all:

    use std::io::Write;

    fn main() {
        std::io::stdout().write(b"Hello, world!\n").unwrap();
    }

The reason people often use println! is that println! is variadic and can support any number of arguments to format in the string. For example:

    println!("x is: {}", x);

This also has the benefit of allowing type checking at compile time, as opposed to using a function like printf in C, which does not have such power. Additionally, this allows Rust to take references to the variables entered without the programmer's specification, in order to prevent unnecessary copying.

These reasons tie directly into Rust's philosophy of making it easy to write reliable, performant code.

Re: I like Odin

#174

Post by still_grokking » Sun, Aug 28, 2022, 8:21 PM UTC

renox wrote: post #42

avgcorrection wrote: post #21

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.

That's not true. Memory safety could be free. Actually it would even outperform any memory unsafe language, when done right™.

The key would be hardware supported automatic memory management.

This tech exists since many years but nobody uses it (likely because our "good old friend": patents, which is a death sentence to any good idea).

https://researcher.watson.ibm.com/researcher/files/us-bacon/...

https://people.eecs.berkeley.edu/~kubitron/papers/holistic_r...

https://adept.eecs.berkeley.edu/wp-content/uploads/2018/06/A...

Re: I like Odin

#175

Post by davedx » Sun, Aug 28, 2022, 8:23 PM UTC

dxuh wrote: post #161

gingerBill wrote: post #113

Earlier quoted context omitted.

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…

My point was that I don't see much of a point in yet another language that is C with an extra 10%. There is another one like that almost every week. Plenty of applications that require manual memory management have been written in C++ or Rust, which do provide RAII. If you know that manual memory management is required for some applications, you also know it's not 100% of the code that needs it.

No post body was provided.

Re: I like Odin

#176

Post by avgcorrection » Sun, Aug 28, 2022, 8:28 PM UTC

gingerBill wrote: post #171

avgcorrection wrote: post #21

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

I've replied to you before on this in other comments. (here is one such example: https://news.ycombinator.com/item?id=32629951 ) Odin has numerous memory safety features enabled by default. Having manual memory management does not entail no "memory safety". You could easily have a language with GC or ARC and still have all of the unsafe features of C. Objective-C is a brilliant example of this. Many memory safety can…

If Odin is memory-safe by default then my bad, I was wrong.

Re: I like Odin

#177

Post by 4v0v » Sun, Aug 28, 2022, 9:10 PM UTC

I tried it for some basic 3d opengl stuff. I like it but the documentation is lacking and the standard library is all over the place. Also there is only one real big project using it afaik (EmberGen), not enough to bother switching from C/C++.

But i'm interested to see how the project will continue. :)

Re: I like Odin

#178

Post by baq » Sun, Aug 28, 2022, 9:13 PM UTC

jcelerier wrote: post #167

dxuh wrote: post #165

Earlier quoted context omitted.

I want to address some points for people that are reading and don't have enough C++ experience to judge that they are not as serious as they might seem. * You can just have your constructors not initialize your member variables. If they don't have default constructors that do work, then no work is done. * Yes, originally. Move-semantics are part of the language since C++11. Enough time has passed. * I read and write…

I absolutely agree, I've written a few hundred thousand loc of C++ at this point and I don't remember one time where I felt that having RAII was anything but great. It made me absolutely hate whenever I had to work in other languages Java and C# and had to remember to release non-memory resources manually.

That’s basically any gced language and the fix is present for decades at this point: try-with-resources, ‘using’, ‘with’ (with-whatever IIRC can be traced back to Lisp…)

Re: I like Odin

#179

Post by jcelerier » Sun, Aug 28, 2022, 9:21 PM UTC

baq wrote: post #178

jcelerier wrote: post #167

Earlier quoted context omitted.

I absolutely agree, I've written a few hundred thousand loc of C++ at this point and I don't remember one time where I felt that having RAII was anything but great. It made me absolutely hate whenever I had to work in other languages Java and C# and had to remember to release non-memory resources manually.

That’s basically any gced language and the fix is present for decades at this point: try-with-resources, ‘using’, ‘with’ (with-whatever IIRC can be traced back to Lisp…)

no, those are absolutely not fixes: you have to remember to use "using", "with", etc. whereas you have to go out of your way to circumvent RAII

Re: I like Odin

#180

Post by jessermeyer » Sun, Aug 28, 2022, 9:28 PM UTC

davedx wrote: post #175

dxuh wrote: post #161

Earlier quoted context omitted.

My point was that I don't see much of a point in yet another language that is C with an extra 10%. There is another one like that almost every week. Plenty of applications that require manual memory management have been written in C++ or Rust, which do provide RAII. If you know that manual memory management is required for some applications, you also know it's not 100% of the code that needs it.

Quoted post unavailable.

As someone who programs professionally in C but writes Odin as a hobby, Odin contributes more like 1000% ease of use, comparatively. And I bet that scales up even more on a team as compared to C.

ASAN, complex build tools, undefined behavior, implicit type conversions, etc, each of these contribute substantial problems all on their own, and they basically don't ever arise in Odin from the start.