C-Odin. The future of the Odin programming language.

Addressing long standing issues with the Odin programming language by leveraging the Lingua Franca of programming languages and it's more mature tooling ecosystem for a brighter Odin future.
For more information check out the Codin project on GitHub
github.com/graphitemaster/codin
Copy of this presentations slides can be found at.
slides.com/graphitemaster/codin

[@peezieforestem5078]

We're entering that HPHPc stage. I'm eagerly anticipating this story arc.

[@SimGunther]

Yay for transpilers that write C code!

[@FastFSharp]

I’m really rooting for Odin!

[@PhilSchurz]

Cool! This looks exciting!

[@KingButcher]

If LLVM breaks Odin code, doesn't that Odin just needs to implement LLVM lowering correctly? Other languages like Rust/Zig also support Saniziters and Valgrind while using LLVM. Wouldn't this be an Odin issue rather than an LLVM issue?

[@ruroruro]

I am not an expert on the issue, but I believe that this is actually quite a common problem with LLVM. For example, Rust also had a lot of issues with LLVM breakages. The problem is that C/C++ semantics often end up leaking down into the LLVM backend implementation. For example, if C or C++ says that something is UB, then LLVM often also assumes that the equivalent IR expression is UB with no real way to opt out. I remember, there was a bug, where LLVM "optimized out" provably infinite loops, because in C++ they are UB. So instead of looping forever, the execution would just skip over the loop and continue executing unreachable code. Needless to say, the Rust folks weren't very happy with this and the only way to fix it at the time was to basically disable function inlining or something stupid like that.

[@KingButcher]

@@ruroruro Re: infinite loops, it can be "disabled" by emitting a side effect the backend cannot optimize away (i.e. asm volatile("" ::: "memory") or a volatile load/store). Rust still enables function inlining optimizations, but that's still a good point w.r.t having to align their semantics. What was described in the video though was basically doing just that except via C syntax as opposed to via LLVM's IR builder API.

[@ruroruro]

@@KingButcher the problem IIRC wasn't actually with "explicit" empty loops in particular. The problem was that LLVM and Rust had different opinions about what should be allowed/disallowed/UB in terms of execution and side effects and stuff. You could start with reasonably benign looking code, feed it to LLVM, LLVM would "optimize" it down to an empty infinite loop and then skip that loop, because such loops are UB in C++. And while you could "fix" this by inserting a volatile operation inside the loop, this would only work if you know in advance, which pieces of code would end up optimized down to empty loops.

[@notuxnobux]

Zig also has to tons of issues with llvm and they intend to drop llvm in the future if possible

[@KingButcher]

@@notuxnobux Zig isnt dropping LLVM, they plan to still emit LLVM bitcode. The packaging and installation of it will be left to something else.

[@danieleccleston7928]

Sounds good

[@CallousCoder]

If seems everybody has issues with LLVM Rust and Zig both have issues with compile speeds. And Zig actually filed for divorce 😉 But this is great stuff! Well done!

[@anselmschueler]

but isn’t using underscore prefixed capitalized names undefined behavior?

[@MagnusNemo-xc5nx]

What's the status of this project? I notice your github repo hasn't been updated in about three months as of the date of this post.

[@janosszabo98]

Maybe they came to the realization that "this is stupid, the world doesn't need yet another programming language"?

[@maskisland2]

How will this help with debug info?

[@HairyPixels]

Two questions. Once the source language is in C how does it map back to the original odin source in the debugger? Second, why does it take 15 seconds to compile anyways? Odin should be doing some kind of incremental building of files so you're usually compiling only a single file. Maybe that's more of an Odin problem than LLVM.

[@FicoosBangaly]

I don't see how this helps with debugging, won't the debug symbols just point to the unreadable C0 representation?

[@10bokaj]

Why not write odin in odin?

[@asddsa10001]

I wanted to try odin once and when i saw that it relies on LLVM, it was just a no go for me and i stick to C11 and C99.

[@_slier]

use c3 then

[@therselman]

@@_slier Read the C3 feature list: "LLVM backend"

[@BryanChance]

Coden sounds good! _:/

[@AbuAl7sn1]

see odin

[@michaelzomsuv3631]

All of these reasons pretty much sum up why I just stick with C. Then I don't need to make my way back to C to get the benefits of C, cause I'm already in C.

[@drygordspellweaver8761]

I C what you did there

[@cemgecgel4284]

:) Odin has quality of life improvements, I guess.

[@godDIEmanLIVE]

There are zero benefits to C, that are not purely artifacts of history, like tooling availability as discussed here. Other than that, there are only things that C either does worse or at most as good as languages like Zig or Odin. Features, safety, speed, anything.

[@drygordspellweaver8761]

@@godDIEmanLIVE Sounds like you have an unnatural bias against C. Have you even programmed in it before?

[@godDIEmanLIVE]

@@drygordspellweaver8761 not really, just C++ in a more or less C-style. Read a lot of it though. What do you think is better in C, than in Zig or Odin for example?

[@simontupy9706]

Based

[@kamertonaudiophileplayer847]

Why do you need to do a frequent compilation? As for me, it is 1-2 compilations a day.

[@guckstift1081]

Also: why compiling the whole codebase 240 times a day and not just single modules? Or ist it the linking that takes 15 seconds?

[@lucy-pero]

​@@guckstift1081Odin doesn't have incremental compilation

[@edemkumah5248]

This video might as well be called "why not just code in C" 😅

[@godDIEmanLIVE]

Because it's a shittier version of a lot of better languages.

[@SaidMetiche-qy9hb]

exactly 😂😂