I like Odin • Hacker News Board

Re: I like Odin

#151

Post by gingerBill » Sun, Aug 28, 2022, 6:19 PM UTC

mananaysiempre wrote: post #85

flohofwoe wrote: post #19

A small but (IMHO) very neat detail is the Pascal-style syntax for defining variables (without requiring a separate 'var' or 'let' keyword): // inferred type: a := 23 // explicitly typed, the type is squeezed between the : and = a : u32 = 23 OTH constants now require special syntax: a :: 23 ...but at least this is consistent with other places in the language, like functions: my_func :: proc(...) ...and 'squeezing in…

This pun originates from Limbo, I think. Go inherits the colon-equals for the inferred-type definition, but not the colon for type ascription, yet another way in which it could have been beautiful but isn’t.

It's slightly older than Limbo, and comes from Newsqueak. The difference is that Newsqueak used keywords for the other non-variable declarations. `x: int = 123`, `const X: int = 123`, `type My_Int: int`, etc.

Re: I like Odin

#152

Post by kevinmgranger » Sun, Aug 28, 2022, 6:20 PM UTC

torginus wrote: post #2

> As someone who is interested in systems programming, and has experience working with Go I wonder how Go got it's reputation as a systems language. Imo, it occupies the same abstraction level as Java or C#.

I think the definition of "systems" changed over time. It used to mean building the foundations of operating systems, e.g. kernel and basic userland utilities.

Now it means building higher-level userland tools and internet oriented tools. I think the implicit consensus is the lower level stuff is a "solved problem".

Re: I like Odin

#153

Post by pjmlp » Sun, Aug 28, 2022, 6:23 PM UTC

coldtea wrote: post #87

pjmlp wrote: post #73

Earlier quoted context omitted.

Sure one can play word games all day long if that is your point.

Civilization is all about word games, is my larger point, and those games are important business and what drive characterization - they're not something incosequential that we can "set aside and get to the real work". Doubly so if what we're concerned about is labelling itself, like "what is and what isn't considered a systems language". Then we're in the word domain, not in the measurement domain.

Actions matter more than words, and in that field Go has already proven itself, regardless of what the priests of the holy church of system programming might preach at the pulpit.

In fact their holy C can only be used for the daily activities, when going outside the ISO C Bible, tainting itself with unholy compiler extensions.

Re: I like Odin

#154

Post by pjmlp » Sun, Aug 28, 2022, 6:26 PM UTC

coldtea wrote: post #86

sophacles wrote: post #79

Earlier quoted context omitted.

I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming. If you succeed at that, I further challenge you to: find me two concurring definitions of systems programming language that include enough detail to qualify and disqualify languages consistently. By "enough detail" and "clear bounds" i mean: a…

> I challenge you to find me two concurring definitions of systems programming that also include enough detail to set clear bounds between what is and isn't systems programming. There's no such thing - that was the whole point of my comment. A systems language is not such because of conforming to a definition, it's a delibarate classification ("this language is, that one isn't" as opposed to "this langauge is because…

Pity that even ISO C fails at it, and needs language extensions to play game.

Re: I like Odin

#155

Post by gautamcgoel » Sun, Aug 28, 2022, 6:30 PM UTC

B1FF_PSUVM wrote: post #100

Drats, not the Norse deity. In case you're also disappointed, I recommend Votan by John James https://books.google.com/books/about/Votan.html?id=y-OlAwAAQ... """ In the second century AD, a Greek nobleman is travelling and living abroad in Germany while carrying on an affair with a military man's wife. When discovered, he takes an emergency business trip to save his life and packs amongst his belongings certain items…

Sounds like The Road to El Dorado :)

Re: I like Odin

#156

Post by gingerBill » Sun, Aug 28, 2022, 6:31 PM UTC

avgcorrection wrote: post #136

gingerBill wrote: post #123

Earlier quoted context omitted.

What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss. Memory safety and memory management are not equivalent concepts. As I state in another reply ( https://news.ycombinator.com/item?id=32629951 ), you have memory safety and manual memory management. And Odin offers numerous memory safety features as well as being designed aroun…

> What it is interesting is that the comment never mentions memory safety, only memory management; you just added memory safety into the discuss. Can’t speak for OP but I also assumed that you were alluding to being able to use unsafe memory management in this part > > And for you, you clearly don't need manual memory management nor high control over memory, memory layout, and memory access. Since high control usuall…

"usually" by whom? "High control over memory" doesn't necessarily mean doing anything "unsafe" with it either. That term could allow for "unsafeness" yes, but it is not solely restricted to that. High control could just mean adding extra annotations about the access, or not having padding in a struct, or specifying the alignment, or many other things, none of which may be classed as "unsafe".

Re: I like Odin

#157

Post by c-cube » Sun, Aug 28, 2022, 6:36 PM UTC

gingerBill wrote: post #140

abainbridge wrote: post #59

Earlier quoted context omitted.

You can have safe manual memory management. The main cases of bugs are: 1. Null pointer deref. Can be fixed by having optional types and requiring that possibly null pointers have to be wrapped in them. 2. Out of bounds references. Can be fixed by making the type system track how big all objects are, and having the compiler insert bounds checking. 3. Use after free. Can be fixed by the free function zero'ing heap obj…

You are correct and Odin supports all of this. `Maybe(^T)` exists in Odin. Bounds checking is on by default for all array-like access. Odin has fixed-length arrays, slices, dynamic arrays, maps, and #soa arrays, all of which support bounds checking. Odin does not have pointer arithmetic nor implicit array-to-pointer demotion which is pretty much removes most of the unsafety that languages like C have. Odin also has b…

Odin and Zig solve almost all the memory safety aspects, except for use after free. Having bound checks, union types, etc. is good and a real improvement over C, but I think that use after free is a memory unsafety issue. It's the one that's harder to tackle because it's more dynamic ("temporal memory safety"?).

Re: I like Odin

#158

Post by Tozen » Sun, Aug 28, 2022, 6:38 PM UTC

gingerBill wrote: post #149

Tozen wrote: post #109

Earlier quoted context omitted.

Well, such things can be subjective. Yes, Odin does not do concurrency and channels. This appears to be because Odin doesn't do automatic memory management, and has more limits on the language, in terms of focus. It can be argued that Odin adapted itself to being a strong Jai alternative and appealing to gaming, versus more general purpose. My understanding is that Odin does not plan to ever attempt to put concurrenc…

Odin has numerous concurrency primitives in the core library. And the synchronization primitives are based on a the modern construct of a `Futex`: https://github.com/odin-lang/Odin/tree/master/core/sync https://github.com/odin-lang/Odin/tree/master/core/thread We are planning on adding channels to the core library but we have not added them yet since there are quite a few different forms (SPSC, SPMC, MPSC, MPMC). One…

Thank you for the additional information and correction.

Re: I like Odin

#159

Post by dxuh » Sun, Aug 28, 2022, 6:49 PM UTC

Kukumber wrote: post #122

dxuh wrote: post #98

I think Odin just doesn't do enough. The improvements over C are there, but imho too small to justify/motivate a large-scale change. And personally I think (!) there is no reason to introduce a new programming language without RAII these days. If you don't solve memory management any more than C did (not), then you are ignoring the biggest problem that needs solving and every replacement that does address this proble…

How do you write your garbage collectors or RC without precise manual memory management? How do you render billions of vertices and maintain a gameplay loop under 8ms for AAA games without precise manual memory/layout management? Not everyone is writing websites in javascript

RAII is often optional automatic memory management, like in C++ or Rust. Both of these languages are used for AAA games and rarely used for websites. My point was that if you don't go as far as those two, there is just not much of a point to not using C instead.

Re: I like Odin

#160

Post by t-writescode » Sun, Aug 28, 2022, 6:50 PM UTC

Wow. The comments in a lot of these threads look to be full of a lot of snark and anger towards other programming languages and people. I wonder if we're approaching another one of those periods again where people need to be at [not their computer] again.