Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

71–80 of 211 posts

Re: I like Odin

#71

Earlier quoted context omitted.

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…

You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap obj…

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 like Rust, which is safe without garbage collection or ARC, but I also wouldn't call it "manual memory management". The trade off they took for this is complexity in the language.

Re: I like Odin

#72
post #62

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…

How many developers are there? For single developer projects, commit messages have very little value compared to documentation and an extensive passing test suite. As the project grows in contributors, the commit log gains value

>How many developers are there?

According to GitHub, there are 132 contributors. Probably most of them were one-off drive-by PRs, but nonetheless, it's definitely not a one person project anymore.

Re: I like Odin

#73
post #67
post #60

Earlier quoted context omitted.

Because languages like Oberon exist, used to write graphical workstations operating systems, and Go has the same set of features as Oberon. Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels systems programming.

> Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels [to be] systems programming. Since you can write the above with any language, perhaps even Python or Lua if you wanted to, it's not exactly the ability to write the above or the fact of having written the above in a language, that makes a language to be considered a "systems programming languag…

Sure one can play word games all day long if that is your point.

Re: I like Odin

#74

Earlier quoted context omitted.

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…

You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap obj…

the last thing is safe concurrency. this is the greatest achievement of the rust borrower checker imo. the ownership model means data races are detected at compile time, eliminating a huge class of concurrent programming bugs without forcing a message passing architecture. deadlocks are still possible if you have two or more mutexes but that’s a much harder problem

Re: I like Odin

#75

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…

When I'm evaluating the quality of a nuclear plant, I focus on the shape and color of the bike shed.

Re: I like Odin

#76

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…

I think Odin is (mainly) written by a single dev. When I'm the solo dev on a project, I also don't put a lot of effort into commit messages.

Even if you're a solo dev, you will likely still have to debug your old code in the future. I'm sure most of HN is familiar with the Chesterton's fence. Proper commit messages aid you in understanding why the changes were made. This especially matters in complex codebases, like compilers.

Re: I like Odin

#77
Odin is currently at the top of my Rust exit-ramp strategy (for personal work).

As I grow older, I find myself wanting to use languages that are more conservative in their designs. Back in my 20s, I was all about expressivity and meta-programming: Scheme, Smalltalk, OCaml, and Haskell were my drugs of choice. I looked down upon those simple peons who used pedestrian languages like Java or PHP and I definitely looked down on those neckbeards who hadn't left their C caverns and didn't know the greatness of closures, higher-kinded types, hygienic macros and all those features that real languages had.

That's how I came to learn about Rust: in the early 2010s, there was a post on Reddit about a new programming language implemented in OCaml. Even before Rust 0.1 was released I was a Rust enthusiast. And what a ride it's been! Rust transformed and evolved a lot since its first days, but what a language it ended up becoming! In a just a few years, Rust went from being a hobbyist toy to an industrial-strength tool used by large projects and corporations like Mozilla, Dropbox, Discord, Amazon, Facebook, and more. I've been using it professionally myself for the past 5 years and it's been (mostly) a great experience.

But as Rust and I continue to change, it seems that the paths of our lives are diverging. As I gather more gray hair, I don't have the energy, the time, or even the passion for learning and master exotic language features anymore. I now avoid a lot of the "cool toys" that I was so enamoured with in my 20s. My programming style is now much closer to what it was when I first learned to program in Turbo Pascal in the mid-90s: mostly functions, arrays, and structs. Rust on the other hand continues its quest to be an industrial language that has ivory tower creds: the community and the core team enthusiastically look forward to having more ways to abstract code, more ways to express constraints at the language level. I feel that before long, my values and Rust's will have grown so far apart that we'll have no choice by to break up our long relationship.

So I've been looking for what else I could use for personal projects. (I think and hope that I continue to use Rust for my professional career.) Odin is at the moment my clear favorite, with Zig slightly behind, and Nim after that. I find that Odin's design represents my own values about what software and a programming language ought to be like better than anything else out there at the moment. It's high-level, has out-of-the-box support for dynamic arrays and dictionaries (I think, the two most useful data structures), and the whole language is simple enough that I learned most of it in a weekend. It does feel like a step back from Rust in certain areas -- null pointers, using product types for returning errors, no ownership checking -- but I think that I'm at a point where I'm ready to forgive and deal with these issues in order to have a tool that is simpler and doesn't evolve at the speed of 20 year olds.

Re: I like Odin

#78
post #75

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…

When I'm evaluating the quality of a nuclear plant, I focus on the shape and color of the bike shed.

Naturally, commit messages aren't the only criteria I'm using. But I wasted way too much time in my life on deciphering the purpose of 20+ year old commits to ignore this.

Re: I like Odin

#79
post #67
post #60

Earlier quoted context omitted.

Because languages like Oberon exist, used to write graphical workstations operating systems, and Go has the same set of features as Oberon. Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels systems programming.

> Unless one doesn't consider writing compilers, linkers, GPU debuggers, container management, syscall emulators, unikernels [to be] systems programming. Since you can write the above with any language, perhaps even Python or Lua if you wanted to, it's not exactly the ability to write the above or the fact of having written the above in a language, that makes a language to be considered a "systems programming languag…

I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming. If you succeed at that, I further challenge you to: find me two concurring definitions of systems programming language that include enough detail to qualify and disqualify languages consistently.

By "enough detail" and "clear bounds" i mean: a group of people independently arriving at the same sets of classification based on your provided definitions.

Re: I like Odin

#80

Odin is currently at the top of my Rust exit-ramp strategy (for personal work). As I grow older, I find myself wanting to use languages that are more conservative in their designs. Back in my 20s, I was all about expressivity and meta-programming: Scheme, Smalltalk, OCaml, and Haskell were my drugs of choice. I looked down upon those simple peons who used pedestrian languages like Java or PHP and I definitely looked…

Sounds like you’ve just found a new way to look down on other people’s PL preferences. Nothing’s really changed.
Post reply on HN