Live data from Hacker News

I like Odin

hasenjudy.wordpress.com

141–150 of 211 posts

Re: I like Odin

#141

Earlier quoted context omitted.

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 r…

Hi Bill, wasn't intended as a criticism of either, or as an observation about the syntax choices, but rather as a way of saying how familiar I am with both: I could say some things about them which are accurate, but not tell code samples apart.

RAII isn't something I happen to be looking for in a language, it kind of falls between Rust and your work in a way that I don't have a use for.

It's an interesting domain, isn't it? You'll always have people reacting from the hip to the problems C has given us, but they'll be back a couple hours later to talk about the wonders of SQLite.

SQLite got there by being careful and building tools to keep them out of trouble. I see an important role for languages which build those tools in, but don't try to replace a manual transmission with an automatic.

Re: I like Odin

#142

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?

There are a few reasons as to why there are different sized booleans in Odin.

One is dealing with foreign code. A lot of old C code used their own boolean type before it was standardized. And many people defaulted to typedeffing `int`. A good example of this is Win32's `BOOL` which is `int` sized, which would be backed by `b32` in Odin.

Another reason is that file formats may use different width booleans to a single byte.

Another reason is that things that are closer to the register-width are faster than byte-wide operations. So `b32` or `b64` even though it takes more memory up can be faster to deal with than `bool`/`b8`.

As for `bit_set`s in Odin, they are backed by integers and a brilliant solution to the problem of flags. They usually become a lot of people's favourite (but small) feature because of their ease of use and clarify of what they express.

Re: I like Odin

#143

Odin sounds like a nice improvement over C, however this caught my attention: > If your “dread” of C comes from fear of memory management, then Odin is probably not for you, and dare I say, maybe systems programming is not for you. I have to say that my dread of C definitely comes manual memory management. The awkward syntax and compilation model I can tolerate. But having your program expose critical security vulner…

Rust sounds like what you want, though be prepared to deal with near C++ levels of complexity at times (lots of Rust code is too macro happy for my tastes). That said, the way to deal with memory management in C is to... not do much of it. I know that sounds like a cop-out but the patterns you're supposed to use in languages like Zig and Odin are the same ones you'd use in C to keep your mind sane. Do not do Referenc…

I’ll admit, the fact that Hello World requires a macro, dissuaded me from learning Rust for years.

Re: I like Odin

#144

Earlier quoted context omitted.

Seems like you need Go then? You mention you want memory management, type safety and proper abstractions, hence the suggestion. Of course, you also mentioned C's syntax as awkward for you, so you might feel the same with Go's syntax.

Go is not a fast language compared to C/C++/Rust. It’s more in line with Java as it’s also garbage collected.

You state that as a blank and white fact, but there's nuance.

https://github.com/lotabout/skim/issues/317#issuecomment-652...

Re: I like Odin

#145
post #81

Earlier quoted context omitted.

A typo of "compiler", I'm fairly certain.

Surely a compoper makes a new pope. Exit code of white smoke signals success. Be sure to run decompope first though.

Why call it the Great Schism when we can call it the decompoposition?

Re: I like Odin

#146
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 agree RAII at a minimum should be available, but why not just use c++ at that point? I'll just go to something like zig or rust that is established and has thousands of libraries available.

Re: I like Odin

#147
post #106

Earlier quoted context omitted.

kebab-case conflicts with binary expressions, specifically subtraction? Some parser jujitsu would be required to fix this.

Generally, kebab-case means that operators must be separated by spaces. Languages like FORTH or LISP might not even treat operators as separate from ordinary functions.

Not with a parsing expression grammar! They make it easy to say that operators must be separated by spaces only when the alternative would be a valid identifier, and if you disallow trailing hyphens this matches most cases:

   a-variable; a-1, a-(expr()), 1-a-variable (don't do this)
I think the last one illustrates why this will never be popular.

Re: I like Odin

#148
post #10
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#.

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.

I think Rob Pike has changed his idea. I remember watching Youtube video featuring language designers(golang, d and rust), where Rob Pike, Andrei Alexandrescu and Steve Klabnik talked about the stories behind three languages. Rob Pike said something like, "Golang was mistakenly called system language, it should be called server programming language instead".

I tried to find the video on youtube, but to no avail.

Re: I like Odin

#149
post #109
post #65

Earlier quoted context omitted.

I wouldn't say that it has a very strong Go fondation because it seems that Odin doesn't have an equivalent to God's channels..

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 thing that I would like to bring up is that Odin differs from Go in that it does not have `go`routines (green threads). These require automatic memory management and a huge runtime to make them possible. And you cannot easily add them after the fact to a language either without huge issues. Channels are very basic things but the thing that makes Go's concurrency powerful are the `go`routines, not the channels.

Re: I like Odin

#150

Earlier quoted context omitted.

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 r…

Hi Bill, wasn't intended as a criticism of either, or as an observation about the syntax choices, but rather as a way of saying how familiar I am with both: I could say some things about them which are accurate, but not tell code samples apart. RAII isn't something I happen to be looking for in a language, it kind of falls between Rust and your work in a way that I don't have a use for. It's an interesting domain, is…

I never took it as a criticism, rather a clarification for others and to explain how Odin does things.

And it is indeed an interesting domain. Something to be very careful before making rash opinions on too. It is such an unexplored field so much potential!

Post reply on HN