[HN Gopher] Small joys of programming in Odin
___________________________________________________________________
Small joys of programming in Odin
Author : lerno
Score : 118 points
Date : 2023-07-21 10:30 UTC (12 hours ago)
(HTM) web link (www.zannzen.com)
(TXT) w3m dump (www.zannzen.com)
| sarchertech wrote:
| I've been using odin on some side projects (mostly game dev). I
| narrowed down my choices to Odin and Zig. After building toy
| projects with both, I settled on Odin. I like that it feels
| fairly high level, but still gives you so much control over
| memory layout.
| Fraterkes wrote:
| Just out of curiosity, what framework have you been using
| inside Oding for gamedev? Raylib?
| sarchertech wrote:
| Yeah I've been using raylib essentially just as a pixel
| buffer because I'm working on a pixel sim.
| matthewfcarlson wrote:
| I'd love to read a write-up once you're done :)
| sarchertech wrote:
| This one is going to take a while, but I'll definitely
| put something out when it's done.
| TheAceOfHearts wrote:
| Shaving the yak: I find `$FNAME.test.odin` to be a bit nicer than
| `$FNAME_test.odin`.
|
| I'm confused about this caller_location thing in tests. It looks
| like you're just passing `loc = loc` a bunch of times for no good
| reason. Why can't the language automatically or implicitly
| implement that functionality? Having to write `loc = loc` at the
| end of every assertion just seems silly.
| skribanto wrote:
| Without it, it would pass the current location, that is the
| location inside that test function, rather than the original
| parent call.
| TheAceOfHearts wrote:
| Sure, I'm saying the language could aspire to implement full
| stack traces automatically for tests, rather than requiring
| passing it for all assertions. Having to keep writing the
| same thing over and over is just boilerplate and a
| distraction. There's no reason the language itself couldn't
| implement some built-in support for such functionality along
| with the testing module, given that they control the full
| ecosystem.
| pmarreck wrote:
| Is it just me or does it look a lot like Go?
| fredrikholm wrote:
| They both lack semi colons and parens around conditionals, but
| in terms of syntax its near identical to Jai.
| gingerBill wrote:
| https://github.com/odin-lang/Odin/wiki/Odin-vs-Jai
| fredrikholm wrote:
| Cheers Bill, really enjoy your blogs and videos.
| gingerBill wrote:
| Thank you for reading my articles and watching my videos!
| zote wrote:
| Yeah part of it gives the same vibes
| gingerBill wrote:
| https://odin-lang.org/docs/faq/#what-have-been-the-major-inf...
| crdavidson wrote:
| Ooh, hadn't seen @disable before, super useful to know! That'll
| be handy for doing toggleable build options for tracing /
| debugging.
|
| I've been using Odin for about a year now, many of the pain-
| points I've had have just been knowledge gaps. Odin's docs and
| debug info have slowly gotten better over time, and little
| discord-community tips here and there have made a huge difference
| for my quality of life.
| munificent wrote:
| @disabled is neat. C# has long had the same feature: the
| [Conditional] attribute.
| memco wrote:
| I was curious after reading: can the @disable behavior be
| modified at runtime? For long running programs I find it
| helpful to be able to set a certain log level up front but have
| a way to update it without rebuilding or restarting the
| program. There may be other operations that can't immediately
| be shut down and restarted so requiring a rebuild or restart to
| get debug logs is not an option in those cases.
| zannzen wrote:
| It cannot, it's purely a build-time feature. The disabled
| proc isn't even in the binary if you disassemble it.
|
| Also for the record I just noticed I wrote @disable
| everywhere instead of @disabled. That's been fixed now
| eikenberry wrote:
| Interesting language... Any word on what they plan for
| concurrency?
| CrampusDestrus wrote:
| Warning: this is not a blog post about all the enjoyable
| activities you can partake in the company of a norse deity
| totetsu wrote:
| Gota keep an eye out for that kind of thing
| hutzlibu wrote:
| Acording to this series, it is a mixed experience.
|
| https://de.wikipedia.org/wiki/American_Gods
| sigzero wrote:
| Season 1 was good. Season 2...not so much.
| hutzlibu wrote:
| And season 3 was better and season 4 will never come ...
|
| I do recommend the book.
| chrsig wrote:
| I have a hard time recommending the book. The main
| character had no agency for most of it, and the plot was
| very unclear. It made for a good unveiling at the end,
| but given the size of the book...it's a lot to read for
| that payoff.
|
| I won't say _don 't_ read it -- it did manage to keep my
| interest, after all -- I just have a hard time
| recommending it due to the time-investment:reward ratio.
| hutzlibu wrote:
| Well, you have to be into the topic, or not. Mythology
| has the trait of unclear plots and dealing with
| mysterious forces quite often ..
|
| (Some stories don't even have a reveal at the ending at
| all)
| [deleted]
| kjs3 wrote:
| Bummer. Those are the _best_ parties, even if you have to die
| in battle to get there.
| fuzztester wrote:
| How many names (or substrings of names) of programming languages
| (other than Odin) can people see in the title of this current HN
| post? :)
| dang wrote:
| Related:
|
| _A Review of the Odin Programming Language_ -
| https://news.ycombinator.com/item?id=32799499 - Sept 2022 (140
| comments)
|
| _I like Odin_ - https://news.ycombinator.com/item?id=32626543 -
| Aug 2022 (204 comments)
|
| _Odin Programming Language_ -
| https://news.ycombinator.com/item?id=30394000 - Feb 2022 (42
| comments)
|
| _Looking into Odin and Zig_ -
| https://news.ycombinator.com/item?id=28440579 - Sept 2021 (27
| comments)
|
| _The Odin Programming Language_ -
| https://news.ycombinator.com/item?id=22199942 - Jan 2020 (141
| comments)
|
| _The Odin Programming Language_ -
| https://news.ycombinator.com/item?id=20075638 - June 2019 (3
| comments)
| rwbt wrote:
| Of all the "Better C" programming languages I've tried so far,
| Odin is my favorite. Somehow it feels very ergonomic and familiar
| to a C programmer. Zig has many cool things, but I'm always
| second guessing myself and trying to figure out the "right" way
| to do things. But writing Odin is really nice and feels fun.
|
| I have high expectations from Odin going forward, but there are
| some pain points hopefully will get resolved in the future. - The
| toolchain is alright at best (I know this is being worked on
| right now). - Discord only communication with the community.
| They're all very nice but sometimes I wish a lot of these
| discussions should be indexed by a search engine.
| WhereIsTheTruth wrote:
| I started using Odin just recently, I'm very happy with it so
| far, it's exactly what I needed, a mix between Go (no garbage
| collector) and C, context system, bunch of allocators available,
| a sane module system (folder based) and tagged union.. very good
| stuff
|
| And they have a very polished language server
| https://github.com/DanielGavin/ols That helped me learn Odin in
| few hours only
|
| Give it a try, you might like it!
| jiehong wrote:
| > Go (no garbage collector)
|
| Well, that's incorrect:
| https://www.sobyte.net/post/2021-12/golang-garbage-collector...
| WhereIsTheTruth wrote:
| I should have perhaps wrote "without", as an argument why I
| enjoy odin, my english isn't great, my bad
|
| Or maybe I misunderstand your comment?
| pphysch wrote:
| Odin looks extremely appealing to me, but I am quite sad about
| the lack of methods, or more specifically, lack of guarantees
| about "dot-autocomplete" support in mainstream code editors. But
| I do think methods make code more concise and readable too (
| object_verb(obj) vs. obj.verb() ). They are syntactic sugar worth
| having.
|
| In 2023, tooling is at the point where RTFM is secondary for
| mainstream lang libraries (TFM being embedded into the editor in
| intelligent ways). I will not go back.
| PHTest wrote:
| IIRC, the odin language server now has method "dot-
| autocomplete" support that will reformat it into the function
| call with the variable as the first parameter.
| https://github.com/DanielGavin/ols
| galaxyLogic wrote:
| Method-syntax is more than syntactic sugar.
|
| It is not just about getting a function from an object and then
| executing that function.
|
| It is executing that function in the context of the object from
| which you get it, by utilizing the pseudo-variable "this" (or
| 'self' in Smalltalk) which refers to that object from which you
| got that function (a.k.a "method" in this case).
|
| But definitely the ability to have editor-support for lookup of
| argument-types etc. is a great benefit too.
| munificent wrote:
| _> It is executing that function in the context of the object
| from which you get it, by utilizing the pseudo-variable
| "this" (or 'self' in Smalltalk) which refers to that object
| from which you got that function (a.k.a "method" in this
| case)._
|
| Ignoring runtime polymorphism for the moment, there's nothing
| special about "this" or "self". It's just another function
| parameter. Consider how in Python it is actually explicitly
| declared as a parameter in the method declaration.
| masklinn wrote:
| That is not necessarily the case though, for instance in
| Self (the language) `self` is the parent slot of the method
| activation object which contains the instance to which the
| message resolved. Then again there's no to functions as I
| don't think Self _has_ free functions.
|
| Also lots of languages have syntactic sugar around the
| corresponding object e.g. implicitly dereference it for
| attribute access and method calls, or even give it
| exclusive(ish) properties like @ in Ruby (or straight up
| instance variable access in smalltalk).
|
| Even Python treats it specially, given a method `foo`,
| `obj.foo` actually returns a proxy object which partially
| applies `foo` to `obj`. This only works on functions
| defined on the class object, mere callables set on the
| instance don't get that treatment.
| wtetzner wrote:
| > Method-syntax is more than syntactic sugar.
|
| No, method syntax is just syntax. In some languages methods
| are more than just syntax sugar, but there's nothing special
| about the syntax itself.
| nrabulinski wrote:
| Editor suggestions are good enough when you know what you're
| looking for or can guess where the method you're looking for
| will be and what it will be called. You very much still need to
| RTFM if you don't have neither
| pphysch wrote:
| So let's say I'm using some new SDK. I run a method that
| returns a Service object. In my current Go/Python world, I
| can dot-autocomplete to quickly get an idea of what
| procedures I can perform with this object. 90% of the time,
| this is sufficient to proceed. 10% of the time I need to
| RTFM/SO.
___________________________________________________________________
(page generated 2023-07-21 23:01 UTC)