5 ms·

Is Odin just a more boring C?

57 points by birdculture 1y ago

lifthrasiir 1y ago
I believe Odin's `^` syntax is a direct nod to Pascal. I for example had a prior experience with Delphi so it wasn't not too obscure.
- vram22 1y ago
  !!
- hmry 1y ago
  That's true, but the keyboard issue is real. ` ^ ~ are dead keys on many keyboard layouts, requiring two keypresses to type. I think they should be avoided for common operations in newly designed programming languages.
  - Scaevolus 1y ago
    () are dead keys by that definition on almost every keyboard layout.
    - casparvitch 1y ago
      LISP in shambles
    - pcfwik 1y ago
      FWIW --- programmer dvorak lets you type () without "shift" but both ~ and ^ require shift. https://www.kaufmann.no/roland/dvorak/ https://www.kaufmann.no/roland/dvorak/
    - 1-more 1y ago
      highly recommend every programmer set up hold/tap for their modifiers, including space cadet style parentheses.
    - pdpi 1y ago
      Parentheses are inserted by pressing two keys simultaneously. Diacritics on layouts that use dead keys are inserted by pressing two keys in sequence. Or, often, two keys simultaneously and then a third key in sequence (E.g. Shift-6 then Space for ^) I'm Portuguese but live in the UK. The Portuguese layout (especially on macs) is dreadful for programming (because a bunch of important characters like brackets require Alt Gr to type), the UK layout sucks for writing Portuguese (because of the diacritics), so I ended up having to get used to US International as the compromise layout. I've gotten kind of used to it over the years, but the exact behaviour for dead keys varies a fair bit by platform, and especially on Linux can get quite aggravating.
      - skydhash 1y ago
        I think on Linux, I took one of the key I never use (insert) and put it as the compose key. That resolved most of my issues with writing French.
  - dismalaf 1y ago
    If you're a programmer you should know how to change keyboard layouts. I speak a couple languages that use accents, all my dead keys need to be combined with a compose key first.
  - JoshTriplett 1y ago
    So is ' for some keyboard layouts, but ' is still useful and evocative in many contexts. There are not enough good symbols trivially typed on a keyboard to sacrifice half of them to dead keys. Either the dead key or the programming symbol can be mapped to a key combination.
  - teo_zero 1y ago
    > [dead keys] should be avoided for common operations in newly designed programming languages. If that's the rationale for choosing which symbols should be allowed, then let's ban {} as they require AltGr+Shift in many layouts. And let's avoid <> (used as parentheses, e.g. for templates or XML tags, not as less-than/greater-than) because in ISO keyboards they loose all their symmetry. And what about shells, with /, one of the most used characters, relegated above 7 in many layouts? Jokes apart, I like the choice of ^ or any other characters distinct from * for pointer dereference. To be more precise, I despise the use of the same symbol with different meaning. In C the same * is used for multiplication, pointer dereference and takes part in commments, too. You need full context to parse some cases, or you have to play with spaces: (a)*(b) // multiplication or casted deref? x/ *y // multiplication x/*y // comment start Same with & m&&n // logical and m& &n // masked address
throwaway81523 1y ago
And is that such a bad thing? C's biggest drawback is its many surprises, I thought. Some boredom would do it good.
- Hasnep 1y ago
  That's literally the point of the article: > Odin kinda feels like a modernized somehow even more boring C but in the best way possible.
- scuff3d 1y ago
  He says the end "I'm using the word boring affectionately"
- jibal 1y ago
  It helps to read the article before commenting.
msla 1y ago
> In the code above, make([]proc(msg: string), len(arr)+1) generates a slice of procedure pointers with a length of len(arr)+1. Essentially, it allocates memory on the heap and returns a slice header, which includes a pointer to the allocated memory, along with the length and capacity of the slice. I guess things get exciting when that allocation fails, given that such a failure is nowhere checked for and the possibility of such failure is nowhere mentioned.
- rwbt 1y ago
  Odin supports multiple returns and the `make` proc returns an error value that can be optionally checked.
  - klardotsh 1y ago
    Optional error checking based on a second return value is just asking for footgunnery, Go made this same (IMO) mistake.
    - rwbt 1y ago
      One can use `@(require_results)` to force the user to check for error. That paired with `or_return` or `or_else` in Odin mostly take away all foot guns.
billforsternz 1y ago
I can't decide whether the double spaced code samples in this blog post are intended or a mistake. I kind of hope it's a mistake.
- zabzonk 1y ago
  seems to be single-spaced to me, and it is my own favourite code spacing
  - billforsternz 1y ago
    Do you still like it now that the author has fixed it?
- jibal 1y ago
  The whole article is like that ... it's not in fact double spaced, it's the line height.
- dayvster 1y ago
  good catch, appreciate it! it was indeed a mistake on my part, line-height got applied to code blocks as well as the paragraphs I fixed it now so that codeblocks do not have a very loose line height.
  - billforsternz 1y ago
    Thanks for fixing the issue, appreciated.
scuff3d 1y ago
> No package manager Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different language.
- Ygg2 1y ago
  Not that it stopped people in the past from adding their own. See JS.
  - scuff3d 1y ago
    Yeah. If it gets popular enough someone will build one, or get it working with an existing manager.
- bxparks 1y ago
  Do you happen to know why? A package manager system seems essential for sharing and reusing code with other people. For example, I don't particularly like Python as a language, but I will use it because it has 677,633 packages in PyPI.
  - badsectoracula 1y ago
    > 677,633 packages in PyPI. Chances are 677,634 of those will be broken next week though :-P The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees. I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast. [0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python
    - bxparks 1y ago
rwbt 1y ago
I'll add another point i.e. Odin is effectively done from a language point of view unlike Zig or others. The project is currently working on improving the std library and toolchain but the language itself is finished according to it's BDFL. From my experience so far, Odin is a delightful modern alternative to C.
- pyrolistical 1y ago
  What do you mean “unlike zig”?
  - cfiggers 1y ago
    Zig is still pre-1.0, and the creators have been VERY clear that they're not done breaking stuff on the way to getting things right. It's a fair contrast to draw.
    - throwawaymaths 1y ago
      to be fair at this point it seems like outside of reenabling async control flow, and eliminating cImport, the remaining major shifts are in the stdlib and not as much the language. they have cancelled the "forcing const f = fn..." plan. i think the interesting thing that andrew hinted at was keeping the "annoying errors that should be warnjngs" (like not using consts and vars) but not letting them prevent the creation of the executable/lib.
      - jibal 1y ago
        https://github.com/ziglang/zig/issues?q=state%3Aopen%20label%3Aproposal%20label%3Aaccepted https://github.com/ziglang/zig/issues?q=state%3Aopen%20label...
        throwawaymaths 1y ago
        note: not all of these are language changes (affects substantially how you write zig) -- many are features and optimizations, true they could affect how you think about zig (inlining monomorphic function pointers), but most people will not notice. Of the ones that are language changes (requiring parens for ambiguous operator precedence, e.g.) many will be automatable and bundled with zig fmt.
teo_zero 1y ago
Doesn't this code leak memory? I mean, even after adding the deinit procs. The point is that when a new_arr is created, the old one is not deleted. Besides, the duo make-delete is easy to understand, but I find disturbing that one has to call delete on objects allocated with X=map[string][]proc(...){} I think it breakes the symmetry.

57 points by birdculture 1y ago

I believe Odin's `^` syntax is a direct nod to Pascal. I for example had a prior experience with Delphi so it wasn't not too obscure.

vram22 1y ago
!!
hmry 1y ago
That's true, but the keyboard issue is real. ` ^ ~ are dead keys on many keyboard layouts, requiring two keypresses to type. I think they should be avoided for common operations in newly designed programming languages.
- Scaevolus 1y ago
  () are dead keys by that definition on almost every keyboard layout.
  - casparvitch 1y ago
    LISP in shambles
  - pcfwik 1y ago
    FWIW --- programmer dvorak lets you type () without "shift" but both ~ and ^ require shift. https://www.kaufmann.no/roland/dvorak/ https://www.kaufmann.no/roland/dvorak/
  - 1-more 1y ago
    highly recommend every programmer set up hold/tap for their modifiers, including space cadet style parentheses.
  - pdpi 1y ago
    Parentheses are inserted by pressing two keys simultaneously. Diacritics on layouts that use dead keys are inserted by pressing two keys in sequence. Or, often, two keys simultaneously and then a third key in sequence (E.g. Shift-6 then Space for ^) I'm Portuguese but live in the UK. The Portuguese layout (especially on macs) is dreadful for programming (because a bunch of important characters like brackets require Alt Gr to type), the UK layout sucks for writing Portuguese (because of the diacritics), so I ended up having to get used to US International as the compromise layout. I've gotten kind of used to it over the years, but the exact behaviour for dead keys varies a fair bit by platform, and especially on Linux can get quite aggravating.
    - skydhash 1y ago
      I think on Linux, I took one of the key I never use (insert) and put it as the compose key. That resolved most of my issues with writing French.
- dismalaf 1y ago
  If you're a programmer you should know how to change keyboard layouts. I speak a couple languages that use accents, all my dead keys need to be combined with a compose key first.
- JoshTriplett 1y ago
  So is ' for some keyboard layouts, but ' is still useful and evocative in many contexts. There are not enough good symbols trivially typed on a keyboard to sacrifice half of them to dead keys. Either the dead key or the programming symbol can be mapped to a key combination.
- teo_zero 1y ago
  > [dead keys] should be avoided for common operations in newly designed programming languages. If that's the rationale for choosing which symbols should be allowed, then let's ban {} as they require AltGr+Shift in many layouts. And let's avoid <> (used as parentheses, e.g. for templates or XML tags, not as less-than/greater-than) because in ISO keyboards they loose all their symmetry. And what about shells, with /, one of the most used characters, relegated above 7 in many layouts? Jokes apart, I like the choice of ^ or any other characters distinct from * for pointer dereference. To be more precise, I despise the use of the same symbol with different meaning. In C the same * is used for multiplication, pointer dereference and takes part in commments, too. You need full context to parse some cases, or you have to play with spaces: (a)*(b) // multiplication or casted deref? x/ *y // multiplication x/*y // comment start Same with & m&&n // logical and m& &n // masked address

throwaway81523 1y ago

And is that such a bad thing? C's biggest drawback is its many surprises, I thought. Some boredom would do it good.

Hasnep 1y ago
That's literally the point of the article: > Odin kinda feels like a modernized somehow even more boring C but in the best way possible.
scuff3d 1y ago
He says the end "I'm using the word boring affectionately"
jibal 1y ago
It helps to read the article before commenting.

msla 1y ago

> In the code above, make([]proc(msg: string), len(arr)+1) generates a slice of procedure pointers with a length of len(arr)+1. Essentially, it allocates memory on the heap and returns a slice header, which includes a pointer to the allocated memory, along with the length and capacity of the slice. I guess things get exciting when that allocation fails, given that such a failure is nowhere checked for and the possibility of such failure is nowhere mentioned.

rwbt 1y ago
Odin supports multiple returns and the `make` proc returns an error value that can be optionally checked.
- klardotsh 1y ago
  Optional error checking based on a second return value is just asking for footgunnery, Go made this same (IMO) mistake.
  - rwbt 1y ago
    One can use `@(require_results)` to force the user to check for error. That paired with `or_return` or `or_else` in Odin mostly take away all foot guns.

billforsternz 1y ago

I can't decide whether the double spaced code samples in this blog post are intended or a mistake. I kind of hope it's a mistake.

zabzonk 1y ago
seems to be single-spaced to me, and it is my own favourite code spacing
- billforsternz 1y ago
  Do you still like it now that the author has fixed it?
jibal 1y ago
The whole article is like that ... it's not in fact double spaced, it's the line height.
dayvster 1y ago
good catch, appreciate it! it was indeed a mistake on my part, line-height got applied to code blocks as well as the paragraphs I fixed it now so that codeblocks do not have a very loose line height.
- billforsternz 1y ago
  Thanks for fixing the issue, appreciated.

scuff3d 1y ago

> No package manager Ginger Bill famously hates package managers, so if the lack of one is a deal breaker for someone they might as well look for a different language.

Ygg2 1y ago
Not that it stopped people in the past from adding their own. See JS.
- scuff3d 1y ago
  Yeah. If it gets popular enough someone will build one, or get it working with an existing manager.
bxparks 1y ago
Do you happen to know why? A package manager system seems essential for sharing and reusing code with other people. For example, I don't particularly like Python as a language, but I will use it because it has 677,633 packages in PyPI.
- badsectoracula 1y ago
  > 677,633 packages in PyPI. Chances are 677,634 of those will be broken next week though :-P The problem with package managers is that they encourage piling on dependencies and creating deep (and thus fragile and often hard to reason about) dependency trees. I loathe having to install anything more complicated than simple scripts[0] based on Python because unless the developer constantly chases after all their dependencies to keep them in working order, i'll be the one who will have to do that when something inevitably breaks (assuming it wasn't already broken the time i decided to try it - which is sadly something i encountered more than a few times). And once the developer moves on, the bitrot spreads alarmingly fast. [0] and even that isn't reliable if the scripts rely on more than whatever comes preinstalled with Python
  - bxparks 1y ago

rwbt 1y ago

I'll add another point i.e. Odin is effectively done from a language point of view unlike Zig or others. The project is currently working on improving the std library and toolchain but the language itself is finished according to it's BDFL. From my experience so far, Odin is a delightful modern alternative to C.

pyrolistical 1y ago
What do you mean “unlike zig”?
- cfiggers 1y ago
  Zig is still pre-1.0, and the creators have been VERY clear that they're not done breaking stuff on the way to getting things right. It's a fair contrast to draw.
  - throwawaymaths 1y ago
    to be fair at this point it seems like outside of reenabling async control flow, and eliminating cImport, the remaining major shifts are in the stdlib and not as much the language. they have cancelled the "forcing const f = fn..." plan. i think the interesting thing that andrew hinted at was keeping the "annoying errors that should be warnjngs" (like not using consts and vars) but not letting them prevent the creation of the executable/lib.
    - jibal 1y ago
      https://github.com/ziglang/zig/issues?q=state%3Aopen%20label%3Aproposal%20label%3Aaccepted https://github.com/ziglang/zig/issues?q=state%3Aopen%20label...
      - throwawaymaths 1y ago
        note: not all of these are language changes (affects substantially how you write zig) -- many are features and optimizations, true they could affect how you think about zig (inlining monomorphic function pointers), but most people will not notice. Of the ones that are language changes (requiring parens for ambiguous operator precedence, e.g.) many will be automatable and bundled with zig fmt.

teo_zero 1y ago

Doesn't this code leak memory? I mean, even after adding the deinit procs. The point is that when a new_arr is created, the old one is not deleted. Besides, the duo make-delete is easy to understand, but I find disturbing that one has to call delete on objects allocated with X=map[string][]proc(...){} I think it breakes the symmetry.