Is Odin just a more boring C?

https://dayvster.com/blog/is-odin-just-a-more-boring-c/

by birdculture • 9 months ago

57 71 9 months ago

I believe Odin's `^` syntax is a direct nod to Pascal. I for example had a prior experience with Delphi so it wasn't not too obscure.

vram22• 9 months ago

hmry• 9 months ago

That's true, but the keyboard issue is real. ` ^ ~ are dead keys on many keyboard layouts, requiring two keypresses to type.

I think they should be avoided for common operations in newly designed programming languages.

Scaevolus• 9 months ago

() are dead keys by that definition on almost every keyboard layout.

dismalaf3• 9 months ago

If you're a programmer you should know how to change keyboard layouts. I speak a couple languages that use accents, all my dead keys need to be combined with a compose key first.

JoshTriplett• 9 months ago

So is ' for some keyboard layouts, but ' is still useful and evocative in many contexts.

There are not enough good symbols trivially typed on a keyboard to sacrifice half of them to dead keys. Either the dead key or the programming symbol can be mapped to a key combination.

teo_zero2• 9 months ago

[dead keys] should be avoided for common operations in newly designed programming languages.

If that's the rationale for choosing which symbols should be allowed, then let's ban {} as they require AltGr+Shift in many layouts. And let's avoid <> (used as parentheses, e.g. for templates or XML tags, not as less-than/greater-than) because in ISO keyboards they loose all their symmetry. And what about shells, with /, one of the most used characters, relegated above 7 in many layouts?

Jokes apart, I like the choice of ^ or any other characters distinct from * for pointer dereference. To be more precise, I despise the use of the same symbol with different meaning. In C the same * is used for multiplication, pointer dereference and takes part in commments, too. You need full context to parse some cases, or you have to play with spaces:

  (a)*(b) // multiplication or casted deref?
  x/ *y // multiplication
  x/*y  // comment start

Same with &

  m&&n  // logical and
  m& &n // masked address

throwaway81523• 9 months ago

And is that such a bad thing? C's biggest drawback is its many surprises, I thought. Some boredom would do it good.

Hasnep• 9 months ago

That's literally the point of the article:

Odin kinda feels like a modernized somehow even more boring C but in the best way possible.

scuff3d7• 9 months ago

He says the end "I'm using the word boring affectionately"

jibal5• 9 months ago

It helps to read the article before commenting.

msla• 9 months ago

In the code above, make([]proc(msg: string), len(arr)+1) generates a slice of procedure pointers with a length of len(arr)+1. Essentially, it allocates memory on the heap and returns a slice header, which includes a pointer to the allocated memory, along with the length and capacity of the slice.

I guess things get exciting when that allocation fails, given that such a failure is nowhere checked for and the possibility of such failure is nowhere mentioned.

rwbt3• 9 months ago

Odin supports multiple returns and the `make` proc returns an error value that can be optionally checked.

klardotsh• 9 months ago

Optional error checking based on a second return value is just asking for footgunnery, Go made this same (IMO) mistake.

billforsternz3• 9 months ago

I can't decide whether the double spaced code samples in this blog post are intended or a mistake. I kind of hope it's a mistake.

zabzonk• 9 months ago

seems to be single-spaced to me, and it is my own favourite code spacing

billforsternz3• 9 months ago

Do you still like it now that the author has fixed it?

jibal5• 9 months ago

The whole article is like that ... it's not in fact double spaced, it's the line height.

dayvster• 9 months ago

good catch, appreciate it!

it was indeed a mistake on my part, line-height got applied to code blocks as well as the paragraphs

I fixed it now so that codeblocks do not have a very loose line height.

billforsternz3• 9 months ago

Thanks for fixing the issue, appreciated.

scuff3d7• 9 months ago

No package manager

Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different language.

Ygg23• 9 months ago

Not that it stopped people in the past from adding their own. See JS.

scuff3d7• 9 months ago

Yeah. If it gets popular enough someone will build one, or get it working with an existing manager.

bxparks2• 9 months ago

Do you happen to know why? A package manager system seems essential for sharing and reusing code with other people.

For example, I don't particularly like Python as a language, but I will use it because it has 677,633 packages in PyPI.

badsectoracula2• 9 months ago

677,633 packages in PyPI.

Chances are 677,634 of those will be broken next week though :-P

The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees.

I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast.

[0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python

forrestthewoods3• 9 months ago

He's written about it repeatedly. https://www.gingerbill.org/article/2025/09/08/package-manage...

The short version is: projects should vendor their deps and manually resolve package versions. I don't think he states his argument very clearly. But I do think he's basically correct.

Vendor your damn deps!

pansa22• 9 months ago

I will use it because it has 677,633 packages in PyPI

Quality over quantity, please

dismalaf3• 9 months ago

Do you happen to know why?

Look at Rust and NPM... Insane amounts of dependencies for almost every library.

C and C++ famously don't have package managers, well, at least not blessed ones (although you could argue Linux/Unix is a C package manager).

The idea is to be more informed about the dependencies you're bringing in, to encourage libraries to be more standalone things, and just not to automate dependency hell.

On the plus side, the Odin compiler makes it very, very easy to compile your program with dependencies.

Hell, even in my Ruby journey I've realised that 99% of what's on Rubygems is absolute trash. I basically use Rails, Faraday, RubyLLM, and not much else.

17186274403• 9 months ago

Because pulling in, updating and verifying code is fundamentally a responsibility of the OS. Also language specific package managers are kind of stupid.

scuff3d7• 9 months ago

According to him, some things shouldn't be automated, and dependency hell is one of them. With package managers developers completely lose track of what code they're depending on, the quality of the code, and vulnerabilities it might have, etc. In addition they are probably pulling a ton of code they don't care about to do one thing, which leads to a lot of bloat.

I think he would say either copy the code you want into your own project, or clone down the repo and control the code yourself.

He hae interviews on Primeagens channel and Developer Voices where he talks about it.

FullGarden_S2• 9 months ago

and yet it never truly became an issue at all because there is an officially maintained, high quality package collection.

https://pkg.odin-lang.org/

GingerBill and the Odin community put tremendous effort into making sure that the Odin compiler ships with "batteries included". You get base, core and vendor library collection that cover almost everything a developer would need to the point that you can argue that you don't need a package manager for Odin.

Ygg23• 9 months ago

That's great. But I need an Aerospike/YAML/JPEGXL/Slint libraries first thing in the morning.

Is it in vendor package yet? No? Then Odin vendor package will be a bottleneck for development.

scuff3d7• 9 months ago

I'm aware, I've been following Odin for a few years. I wasn't saying that in judgement. I like Odin and I generally like Ginger Bill's approach to things.

That being said it's way to early to say it "never became an issue". Odin is still small and not well established. If/when it starts to grow in popularity someone is going to develop a solution eventually. It's impossible for the language to offer EVERYTHING people could need, and developers love package managers.

rwbt3• 9 months ago

I'll add another point i.e. Odin is effectively done from a language point of view unlike Zig or others. The project is currently working on improving the std library and toolchain but the language itself is finished according to it's BDFL.

From my experience so far, Odin is a delightful modern alternative to C.

pyrolistical• 9 months ago

What do you mean “unlike zig”?

cfiggers• 9 months ago

Zig is still pre-1.0, and the creators have been VERY clear that they're not done breaking stuff on the way to getting things right. It's a fair contrast to draw.

jibal5• 9 months ago

He's saying that the Odin language is effectively finished and not subject to change. That is not the case for Zig.

jibal5• 9 months ago

You mean the language is effectively finished and not subject to change.

teo_zero2• 9 months ago

Doesn't this code leak memory? I mean, even after adding the deinit procs. The point is that when a new_arr is created, the old one is not deleted.

Besides, the duo make-delete is easy to understand, but I find disturbing that one has to call delete on objects allocated with

  X=map[string][]proc(...){}

I think it breakes the symmetry.

Is Odin just a more boring C?

Related Stories