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

61–70 of 131 posts

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

#61

Post by gingerBill »

mcbrit wrote: post #11
mcbrit wrote: 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.

Well at JangaFX, we can simulate a heck more than that on the GPU and you can apply as many complex forces applied to them as you'd like.

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

#62

Post by gingerBill »

deadwanderer wrote: post #38
ultrarunner wrote: post #12

As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being ca…

That's a method from Raylib, a C library which has Odin bindings. For all libraries, Odin follows the original library's style. The Odin convention is Pascal case (lower_case_procedures, Capitalized_Enums_And_Structs).

It's technically `Ada_Case` that we use, because I like reading it.

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

#63

Post by gingerBill »

ultrarunner wrote: post #12

As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being ca…

Odin itself does not care what naming conventions you use. Use whatever you prefer.

For Odin native libraries, we usually for the convention of `snake_case` for variables and procedures and `Ada_Case` for types. However for anything that is third-party/foreign, we try to keep to the same convention as the original library to make it easier to people reference the original documentation, as well as not have any of the problems that certain naming conventions cannot be translated to another. So the raylib code uses the original raylib naming conventions because of the reasons I described.

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

#64

Post by gingerBill »

yawaramin wrote: post #44

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 with the memory allocation strategy in a language like C or Odin. 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. `malloc`/`free` like approaches to memory allocation make use-after-free a lot more common because it making you micromanage allocations on a per-value level rather than on a per-shared-lifetime level. It's rare a single value has a unique lifetime, and I'd argue never in many projects.

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

#65

Post by bvrmn »

gingerBill wrote: post #63
ultrarunner wrote: post #12

As a completely incidental observation (and maybe related to the article from a few days ago considering the importance of language skills compared to math skills for software development), I'm interested in what people choose to capitalize when developing languages. With c, lowercase seems to be the default, signifying variables or function calls. Adding inheritance in c++ leads to Proper Nouns like classes being ca…

Odin itself does not care what naming conventions you use. Use whatever you prefer. For Odin native libraries, we usually for the convention of `snake_case` for variables and procedures and `Ada_Case` for types. However for anything that is third-party/foreign, we try to keep to the same convention as the original library to make it easier to people reference the original documentation, as well as not have any of the…

Sticking to an library style is a way to go. It's so much friction to use python library wrappers which try to hammer original style into a snake_case.

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

#66

Post by gingerBill »

teo_zero wrote: post #46
bsrkf wrote: post #34

Earlier quoted context omitted.

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?

I wouldn't like RAII, and why I didn't add it to Odin. It's not a feature C programmers want. And you've just agreed that C don't want ctors/dtors, which is necessary for RAII to work... ctors/dtors are bad for their own reasons (mainly because you cannot handle error cases except through exceptions, which many people disable too).

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

#67

Post by gingerBill »

teleforce wrote: post #37
lerno wrote: post #36

Earlier quoted context omitted.

Yes, I am quite aware. But it doesn’t make D any less a C++ alternative.

Safe to say that D is both C and C++ alternative, never say never.

If you aim to be both a C alternative and C++ alternative, in reality you are just a C++ alternative because you haven't understood why people prefer C over C++. Therefore D is a C++ alternative and that's what it was always trying to be, even with "BetterC".

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

#68

Post by beagle3 »

yawaramin wrote: post #43
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.

I think Nim is much more of a pascal successor than Go ; It retains some of the syntax and feel, although it uses Python style indentation instead of begin/end.

It is by no means pascal-simple - although the subset used by 95% of programs is.

It does have everything you need including macros, unsafe access, minimal OO but these are almost exclusively used by library developers.

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

#70

Post by pjmlp »

gingerBill wrote: post #67
teleforce wrote: post #37

Earlier quoted context omitted.

Safe to say that D is both C and C++ alternative, never say never.

If you aim to be both a C alternative and C++ alternative, in reality you are just a C++ alternative because you haven't understood why people prefer C over C++. Therefore D is a C++ alternative and that's what it was always trying to be, even with "BetterC".

Only if they aren't using anything beyond C99, because after that C is basically turning into C++ without Classes.
Post reply on HN