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

I like Odin

hasenjudy.wordpress.com

Post reply on HN
Print view View original

131–140 of 211 posts

Re: I like Odin

#131

Post by ObscureScience »

doliveira wrote: post #22
copx wrote: post #7

Earlier quoted context omitted.

AFAIK Go was and is primarily used to write back-end server software and this is commonly called "systems programming" (as opposed to application programming) too. It is kinda confusing that the term is used for that and for low-level embedded/firmware/kernel programming, despite both areas having little in common with each other.

> and this is commonly called "systems programming" Is it, though? My impression it only started with Go calling it that way

I don't think so. I think it's just the way Rob et al. used the term from their previous experience.

It's not meant to mean operating systems language, nor embedded systems language.

Rather for writing parts of a systems, such as servers. I would say that the definition is not that far away for Java or C#, but the expectation is simply that it would be "lower level" components of a system, including unix like utilities.

Re: I like Odin

#132

Post by xigoi »

eterps wrote: post #47

I like how newer languages with a C style syntax have more readable type declaration mechanisms than C (some even Pascal-like to an extent). But I am not sure what I would prefer in some cases when looking at these new languages. For example doing some alloc/pointer stuff in Odin is like: ptr := new(int) ptr^ = 123 x: int = ptr^ free(ptr) And in Hare: let ptr: *int = alloc(123); let x: int = *ptr; free(ptr); Which ap…

I prefer `^` for pointers because it's pointy, and having it after the value because it's less ambiguous when combined with subscripts and field accesses.

Re: I like Odin

#133

Post by culi »

bhedgeoser wrote: post #48
hsn915 wrote: post #10

Earlier quoted context omitted.

When Go was first announced ~2009, Rob Pike explicitly framed it as a systems language https://www.youtube.com/watch?v=rKnDgT73v8s I would not say it's the same as Java or C#. The crucial difference is that it compiles to a native executable binary file, not something that needs a virtual machine.

C programs are executed inside the C virtual machine.

You mean the C abstract machine?

Re: I like Odin

#134

Post by xigoi »

rawoke083600 wrote: post #88
jdrek1 wrote: post #8

Earlier quoted context omitted.

Just use uBO like everyone else, there's not a single ad on that page visible for me.

Was reading on mobile, probably need to use some adblocker for mobile as well.

Firefox supports uBlock Origin on mobile.

Re: I like Odin

#135

Post by zamadatix »

Reading through Odin (very neat overall!) I am a bit confused on the additional boolean types. "bool" seems to be your standard boolean but then there are b8, b16, b32, and b64. Bitfields seem to be their own thing still so are these just boolean types with a wider backing for something like a data format that stores them that way?

Re: I like Odin

#136

Post by avgcorrection »

gingerBill wrote: post #123
mplewis wrote: post #116

Earlier quoted context omitted.

But safe memory management is the biggest problem that needs solving. It’s empirically impossible for humans to write secure, complex programs while managing memory by hand. I agree with OP, that Odin doesn’t go far enough toward safety in this regard. We do all require and desire security.

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 usually means being able to do whatever you want (compilers always have to be a bit conservative).

Re: I like Odin

#137

Post by YuukiRey »

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

I guess they are referring to something like Rust which manages to "solve memory management" while still letting you write high performance code.

Re: I like Odin

#138

Post by gingerBill »

samatman wrote: post #125
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…

I don't think any feature should be a mandatory part of a programming language, provided its reasons for not including it make sense. I'm fuzzy on Odin, if you showed me some Odin and some Hare I bet I couldn't tell them apart, but it kinda looks like a nice C with syntax inspiration from Go and (hence) Pascal. A language like that, as long as the object code is correct, then hey, it's there for people who want it. I…

Regarding Odin and Hare, I'd argue most people would easily be able to tell them apart from the syntax alone because the declaration syntaxes are quite different. And most people judge a syntax pretty much solely by the declaration syntax itself.

Regarding RAII, I explain in another comment (https://news.ycombinator.com/item?id=32629951) the issues with RAII and what it requires to be useful. Odin has the similar rule of "no allocation without an allocator" but has the implicit `context` system which passes the current context's allocators around. Odin also has core library support for valgrind, callgrind, memcheck, and soon helgrind.

Odin has features (which this article does showcase) which are akin to RAII but are not attached to the type system. And as I explained in the previous comment, RAII wouldn't even make much sense in Odin (or Zig for that matter) and would probably never a good idea to add it later. There are better alternatives to RAII for languages such as Odin and Zig.

Re: I like Odin

#139

Post by renox »

I read some time ago Odin's documentation, I was quite impressed. But I wonder if it shouldn't copy some Zig features: for example unsigned not wrapping by default are a good idea IMHO: this may detect errors in debug mode and may create more efficient code in release mode.

I've been programming in C or C++ since 1993 and I can count on one of my hand the number of time I've used unsigned wrapping voluntary (for clock management)..

Re: I like Odin

#140

Post by gingerBill »

abainbridge wrote: post #59
sanderjd wrote: post #46

Earlier quoted context omitted.

Yeah this kind of framing always rubs me the wrong way. I don't "dread" manual memory management. Indeed, from a personal standpoint I really like thinking about stuff like that while I'm programming. It's part of the fun puzzle aspect that got me into all this. But as a professional , I know that there is heaps of evidence over many decades that it is unwise for me to indulge this fancy, when working on real systems…

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 built-in support for custom allocators which allows you do a lot more with extra safety features too beyond the default allocator. Use-after-free is usually also a symptom of an underlying value responsibility and lifetime problem rather than a problem in itself, of which is fundamentally an architectural issue. Ownership semantics in a language in Rust does deal with this issue BUT it does come at a huge cost in terms of architecting the code itself to accommodate this specific way of programming.

There is a common assumption amongst many of the comments that if you have manual memory management, you are defaulting to memory unsafety. This is untrue and memory management and memory safety are kind of unrelated in the grand scheme of things. You could have C with GC/ARC and still have all of its memory unsafety semantics.

Post reply on HN