Live data from Hacker News

Odin, a pragmatic C alternative with a Go flavour

bitshifters.cc

91–100 of 131 posts

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

#91
post #35

Earlier quoted context omitted.

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

It was introduced in 2017, and not part of the original direction of D (it’s neither in 1.0 nor the 2.0 revision of the language) That D exposes a curated subset of D doesn’t make it a C alternative, even though the ”betterC” aims to target people looking for a C alternative

> That D exposes a curated subset of D doesn’t make it a C alternative,

But why? You comment does not clarify what does this subset lack which prevents it being used as a C alternative. The intention is explicitly stated and the "spirit" argument is weak as overly subjective.

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

#92

Earlier quoted context omitted.

I'm kinda curious, you mind sharing some of the things you thought you didn't like?

I took a good hard look at everywhere I may have stored it, but I believe I lost the original list after formatting. I remember believing these were important: - methods (turned out I mainly wanted working intellisense, which Odin does even without methods) - a package manager (still a gripe, but git submodules do the trick somewhat) - expressions (so I could assign the result from a `switch` statement to a variable…

Odin is public by default.

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

#93
post #92

Earlier quoted context omitted.

I took a good hard look at everywhere I may have stored it, but I believe I lost the original list after formatting. I remember believing these were important: - methods (turned out I mainly wanted working intellisense, which Odin does even without methods) - a package manager (still a gripe, but git submodules do the trick somewhat) - expressions (so I could assign the result from a `switch` statement to a variable…

Odin is public by default.

Reread it =b

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

#94

Can someone explain how Odin achieves memory safety? Eg how does it avoid use-after-free?

It's not. However it is safer than C by default due to things like bounds-checking on arrays, slices (ptr+len), tagged unions, distinct typing for many things, an actual enum type, numerous checks for things like missing switch cases, and my more. It's not trying to be memory safe, but rather try and catch many common mistakes that C does not catch easily. As for use-after-free, I'd argue that is more of a problem wi…

> And a change to something like an Arena like memory allocation strategy or something else reduces issues like that by a hell of a lot

So for example if I have a server, instead of allocating a Request object for each incoming request I should pre-allocate an arena of N request objects and just keep reusing them? Doesn't this blow up memory usage if I have a static pool of objects that may not be actually needed depending on traffic?

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

#95
post #11
post #9

I am currently limiting myself to 500 lines of (particle engine) code while listening to visual artists talking about their workflow in UE5 or Houdini, and Odin+Raylib are lovely to work in. GingerBill has shouted out Go, but Odin doesn't particularly feel like a Go flavo(u)r.

To point out something that is a fail: I don't want to hear about how you simulated 10M particles on the GPU without acceleration forces.

What is an acceleration force?

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

#96

Earlier quoted context omitted.

"go flavour" refers to the similarity in the design philosophy, and some of the features. That said, it's still not Go. For example, "errors as values" is a point that Odin makes, but it does make it in a slightly different light from Go. Whereas Go has an `error` type that encompasses all errors, Odin does not. Instead, it treats some types (booleans, enums, unions) as "special", in that they support things like `or…

I just don't see the surface syntax as mattering that much. When I see "Go", I think lightweight threads, channels, and GC. Stuff like the declaration syntax is way down the list. Thanks though.

Well, you are right, these are big features of Go, but I think the design philosophy is the other half of the language that makes it what it is.

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

#97

Earlier quoted context omitted.

I'm kinda curious, you mind sharing some of the things you thought you didn't like?

I took a good hard look at everywhere I may have stored it, but I believe I lost the original list after formatting. I remember believing these were important: - methods (turned out I mainly wanted working intellisense, which Odin does even without methods) - a package manager (still a gripe, but git submodules do the trick somewhat) - expressions (so I could assign the result from a `switch` statement to a variable…

I see yeah, a lot of people might prefer most of these (exclude maybe private by default and privating via underscoring).

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

#98
post #80

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

I haven't read the article yet, but this seems to conflate compile time evaluation with metaprogramming. Not all comptime evaluation is metaprogramming. I would argue the majority of comptime programming as it is used in Zig isn't even metaprogramming. Metaprogramming is a paradigm where there source or target data structure is primarily the language you're programming in. comptime evaluation of expressions that coul…

@alignOf is almost never metaprogramming, it's almost always just something you have to call to declare to the compiler, yes (eyeroll), i am aware that this type erased pointer is aligned correctly.

however, it's also a good signal "please review this code to make sure i didn't f it up"

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

#99
post #22

FWIW, another take on "C Alternative" is the D programming language: https://wiki.dlang.org/Tutorials Comparatively mature, there's even a freeware book which is quite good: http://www.ddili.org/ders/d.en/index.html

I always thought it was more akin to a C++ than a C alternative, and reading https://en.wikipedia.org/wiki/D_(programming_language) seems to rather confirm this notion: "originated as a re-engineering of C++" "influenced by Java, Python, Ruby, C#, and Eiffel" "design by contract, ranges, built-in container iteration concepts, and type inference" "array slicing, nested functions and lazy evaluation." "Java-style singl…

Yes, I understand the C++ aspect, but I was never a C++ coder, and D "fit in my hand" in a way which made me certain that its creator had coded extensively in C and understood the aspects which made it so perfect for its time. It really felt like D, not D++ to me.

(Oh, disclosure, I'm just a D user, no organizational or financial interests here.)

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

#100

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.

I would highly recommend https://learn.adacore.com/index.html for learning Ada / SPARK.
Post reply on HN