Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Odin, a pragmatic C alternative with a Go flavour

bitshifters.cc

Post reply on HN
Print view View original

41–50 of 131 posts

Re: Odin, a pragmatic C alternative with a Go flavour

#41

Post by throwawaymaths »

lerno wrote: post #25
throwawaymaths wrote: post #4

> This is the polar opposite of Zig’s embracing of metaprogramming for as much as possible. I found this claim a bit strange. do people actually use metaprogramming in Zig a lot?

Isn't all sorts of stuff metaprogramming in Zig? Generic types, vtable interfaces, printf. All use comptime to generate code.

i think "using comptime" as a definition of metaprogramming is not really accurate... for example, i think calling this metaprogramming is really stretching it:

    var x: [sqrt(LENGTH)]f32 = undefined
i think calling "instantiating a generic type" meta-programming is weak, since you're not doing any of the metaprogramming yourself, though i would concede that if debugging is the concern there is a point there.

same goes for "using std.debug.print"

Re: Odin, a pragmatic C alternative with a Go flavour

#43

Post by yawaramin »

johnnyjeans wrote: post #26

For me, I don't really look at Odin as a successor/fixer of C. There are other languages that can make a better case for that[1][2]. Instead, I look at it more like a successor/fixer of Pascal. It doesn't fall down the OO hole that so many others did. It has type casting, dynamic arrays, parametric polymorphism in both functions and data structures, is much less noisy (and in my opinion far more skimmable), more usef…

Isn't Go the modern successor of Pascal? It certainly didn't fall down the OO hole.

Re: Odin, a pragmatic C alternative with a Go flavour

#45

Post by az09mugen »

johnnyjeans wrote: post #26

For me, I don't really look at Odin as a successor/fixer of C. There are other languages that can make a better case for that[1][2]. Instead, I look at it more like a successor/fixer of Pascal. It doesn't fall down the OO hole that so many others did. It has type casting, dynamic arrays, parametric polymorphism in both functions and data structures, is much less noisy (and in my opinion far more skimmable), more usef…

Did you take a look at Ada as replacement for Pascal ? With the 'gnat' compiler and some doc (https://www.adaic.org/learn/) I think you can find what you are looking for.

Re: Odin, a pragmatic C alternative with a Go flavour

#46

Post by teo_zero »

bsrkf wrote: post #34
ZoomZoomZoom wrote: post #31

Earlier quoted context omitted.

Doesn't having a whole subset of the language called "Better C" qualify?

C is liked particularly, even considering all its shortcomings, for being a relatively limited language in scope, being raw but flexible. D's scope seems to go far beyond what your average C programmer would want in a language; "use only 15% of the language and you'll be fine" (paraphrasing: "use only the 'better-C' subset", if that is what you meant, and it does seem to be a subset of D) seems a weird proposition; i…

> "Better-C" still has things many C-programmers wouldn't particularly like

I'd say a couple, not many.

> RAII

Who wouldn't like RAII?

> Metaprogramming

As a way to avoid preprocessor macros? Yes please.

> Nested functions

Already offered as extension.

> Member functions

I'm sure no C programmer would object to that.

> constructors, destructors

This yes. Agreed.

> operating overloading

Instead of _Generic()? Why not?

Re: Odin, a pragmatic C alternative with a Go flavour

#47

Post by throwaway81523 »

I don't understand the point of this. When I say "Go flavour" I thought it would have lightweight threads like Go, but there is no mention of that in the description page. So it's another uninteresting curly brace language as far as I can tell. I'd rather use one with more traction.

Re: Odin, a pragmatic C alternative with a Go flavour

#49

Post by rednafi »

Odin truly feels like a C successor, and as someone who likes Go, it appeals to me a lot more than Zig or Rust. Partly because it took inspiration from the Pascal, Delphi, Oberon branch, same as Go.

I don’t particularly enjoy working on the types of problems Zig or Rust aim to solve. I spend the majority of my time working at layer 4, and Go makes it immensely enjoyable. But sometimes I want a bit more control over the hardware and don’t want to pay the cost of a GC. Odin feels just right.

In my case, the assortment of syntactic features like OOP, compile-time macros, or even the borrow checker suck all the fun out of programming. That’s why I still enjoy writing C programs, footguns and all.

Re: Odin, a pragmatic C alternative with a Go flavour

#50

Post by pjmlp »

johnnyjeans wrote: post #26

For me, I don't really look at Odin as a successor/fixer of C. There are other languages that can make a better case for that[1][2]. Instead, I look at it more like a successor/fixer of Pascal. It doesn't fall down the OO hole that so many others did. It has type casting, dynamic arrays, parametric polymorphism in both functions and data structures, is much less noisy (and in my opinion far more skimmable), more usef…

Hard disagree the simplicity of Pascal, is what made it unusable outside the original goal to learn programming.

Instead we ended up with UCSD Pascal, Object Pascal, TMT Pascal, Quick Pascal, VMS Pascal, Delphi and what not.

By the time it came to be, ISO Extended Pascal was largely irrelevant, outside some UNIX compilers that supported it.

The Borland linage, after taking over Apple's design, which had input from Niklaus Wirth, is my favourite, then their management messed up.

In an ideal world, Modula-2 or Ada would have taken over, sadly no big name OS vendor, ever felt like adopting them.

As for Oberon, when I came to learn it, Oberon-2 was already out, eventually Component Pascal and Active Oberon were much more interesting to me.

While I appreciate Niklaus Wirth work, I was never a fan of the minimalism he tried to pursue with Oberon-07. Then rather use Go.

In the end, nothing of this will matter in the age of AI assisted tooling and code generation.

Arguing what is the best language is getting akin to argue about Assembly language syntax, when most people are using optimizating compilers.

Post reply on HN