4 ms·

This is a bit silly but when i look at new languages coming up I always look at the syntax, which is usually horrible(Zig and Rust are good examples), and how m

by gethly 10mo ago

This is a bit silly but when i look at new languages coming up I always look at the syntax, which is usually horrible(Zig and Rust are good examples), and how much garbage there is. As someone that writes in Go, I can't stand semicolons and other crap that just pollutes the code and wastes time and space to write for absolutely no good reason whatsoever. And as this compares itself with Go, I just cannot but laugh when I see ";", "->" or ":" in the example. At least the semicolon seems optional. But still, it's an instant nope for me.

imbnwa 10mo ago
What would be better?
- christophilus 10mo ago
  I wish more languages would adopt Clojure’s approach to optional delimiters in collections. [2 45 78] It’s just a nicer thing to view and type in my experience. Regarding syntax soup, I think Odin is probably syntactically the cleanest of the lower level languages I’ve played with.
  - int_19h 10mo ago
    It's a Lisp thing, obviously, but also there's a benefit to explicit delimiters - it makes it possible to have an expression as an element without wrapping that in its own brackets, as S-exprs require.
  - gethly 10mo ago
    oh, yeah. that looks good. i always hated using ", " delimiter for lists and the amount of typos it always takes to make clean(well, not with Go fmt). Odin seems interesting but for me it has two deal-breakers: first one use the use of ^ for pointer de/reference. Not that it does not make sense, it's just that it is not an easy key to get to on my keyboard layout and i will not be changing that. The & and * are well known characters for this purpose and, at least for me, easily accessible on the keyboard. Second issue is the need to download many gigabytes of visual studio nonsense just so i am able to compile a program. Coming from Go, this is just a non-starter. Thirdly, and this is more about the type of work i do than the language, there are/were no db drivers, no http/s stack and other things i would need for my daily work. Other than that, Odin is interesting. Though I am not sure how I would fare without OOP after so many years with inheritance OOP and encapsulated OOP.
- gethly 10mo ago
  Remove all of that noise. Take this: fn fib(n: i32) -> i32 {} The (n: i32) can be just (n i32), because there is no benefit to adding the colon there. The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax. So you end up with simple and clean fn fib(n i32) i32 {} And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. We have modern lexers/tokenizers and compilers that can handle if you don't put a stupid ; at the end of every single effing line. Just go and count how many of these useless characters are in your codebase and imagine how many keystrokes, compilation errors and wasted time it cost you, whilst providing zero value in return.
  - exceptione 10mo ago
    In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here: fn fib(n i32) i32 {} But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them. Personally, I would like a language that pushes the programmer to write the types as part of a doc comment. Also think about returning lambda's. Should it look like this? fn foo(n i32) (i32 i32) {} Of course the IDE could help by showing the typographic arrows and other delineations, but as plaintext this is completely unreadable. > And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. You still have to think about stuff like currying. You either delimit the line, or you use significant white space.
    - gethly 10mo ago
      > Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {} It should be fn foo(n i32, m i32) (i32, i32) {} It will also allow future implementation of named returns, like in Go: fn foo(n i32) (a i32, b i32) {} As for semicolon, that is needed only if you have inline expression: for (;;;) {} Or inline block, like in Go: if foo := a + b; foo > c {}
      - exceptione 10mo ago
mrkeen 10mo ago
Weird, that's exactly how I feel reading Go: func (lst *List[T]) Push(v T) { if lst.tail == nil { lst.head = &element[T]{val: v} lst.tail = lst.head } else { lst.tail.next = &element[T]{val: v} lst.tail = lst.tail.next } } And this one doesn't even have the infamous error-checking.
- hu3 10mo ago
  You cherry picked a contrived example but that's one of the cleanest generics implementations. Now imagine if it had semicolons, ->, ! and '.
  - mrkeen 10mo ago
    > You cherry picked a contrived example List.add is contrived? What are you doing that's simpler the list.add? > but that's one of the cleanest generics implementations. You're saying it's typically worse than this?
    - gethly 10mo ago
      He is referring to &element[T]{val: v} the & is a pointer, which is common across most languages, but the [T] is a dynamic type T. Otherwise it would be just &element{val: v} He says that element[T] is a clean/simple implementation of generics.
steveklabnik 10mo ago
I respect your preferences! I like punctuation. Even though I have a Perl tattoo, it'll never get like that, though. (Semicolon rules, for now at least, will be the same as Rust)

by gethly 10mo ago

imbnwa 10mo ago

What would be better?

christophilus 10mo ago
I wish more languages would adopt Clojure’s approach to optional delimiters in collections. [2 45 78] It’s just a nicer thing to view and type in my experience. Regarding syntax soup, I think Odin is probably syntactically the cleanest of the lower level languages I’ve played with.
- int_19h 10mo ago
  It's a Lisp thing, obviously, but also there's a benefit to explicit delimiters - it makes it possible to have an expression as an element without wrapping that in its own brackets, as S-exprs require.
- gethly 10mo ago
  oh, yeah. that looks good. i always hated using ", " delimiter for lists and the amount of typos it always takes to make clean(well, not with Go fmt). Odin seems interesting but for me it has two deal-breakers: first one use the use of ^ for pointer de/reference. Not that it does not make sense, it's just that it is not an easy key to get to on my keyboard layout and i will not be changing that. The & and * are well known characters for this purpose and, at least for me, easily accessible on the keyboard. Second issue is the need to download many gigabytes of visual studio nonsense just so i am able to compile a program. Coming from Go, this is just a non-starter. Thirdly, and this is more about the type of work i do than the language, there are/were no db drivers, no http/s stack and other things i would need for my daily work. Other than that, Odin is interesting. Though I am not sure how I would fare without OOP after so many years with inheritance OOP and encapsulated OOP.
gethly 10mo ago
Remove all of that noise. Take this: fn fib(n: i32) -> i32 {} The (n: i32) can be just (n i32), because there is no benefit to adding the colon there. The -> i32 can also be just i32 because, again, the -> serves no purpose in function/method definition syntax. So you end up with simple and clean fn fib(n i32) i32 {} And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. We have modern lexers/tokenizers and compilers that can handle if you don't put a stupid ; at the end of every single effing line. Just go and count how many of these useless characters are in your codebase and imagine how many keystrokes, compilation errors and wasted time it cost you, whilst providing zero value in return.
- exceptione 10mo ago
  In a Hindley-Milner (or deriative) type system, types doesn't have to be explicit, making the number of arguments ambiguous here: fn fib(n i32) i32 {} But even if they need to be written explicitly, type applications like `List a` would require syntax to disambiguate them. Personally, I would like a language that pushes the programmer to write the types as part of a doc comment. Also think about returning lambda's. Should it look like this? fn foo(n i32) (i32 i32) {} Of course the IDE could help by showing the typographic arrows and other delineations, but as plaintext this is completely unreadable. > And semicolons are an ancient relic that has been passed on to new languages for 80 fucking years without any good reason. You still have to think about stuff like currying. You either delimit the line, or you use significant white space.
  - gethly 10mo ago
    > Also think about returning lambda's. Should it look like this? > > fn foo(n i32) (i32 i32) {} It should be fn foo(n i32, m i32) (i32, i32) {} It will also allow future implementation of named returns, like in Go: fn foo(n i32) (a i32, b i32) {} As for semicolon, that is needed only if you have inline expression: for (;;;) {} Or inline block, like in Go: if foo := a + b; foo > c {}
    - exceptione 10mo ago

mrkeen 10mo ago

Weird, that's exactly how I feel reading Go: func (lst *List[T]) Push(v T) { if lst.tail == nil { lst.head = &element[T]{val: v} lst.tail = lst.head } else { lst.tail.next = &element[T]{val: v} lst.tail = lst.tail.next } } And this one doesn't even have the infamous error-checking.

hu3 10mo ago
You cherry picked a contrived example but that's one of the cleanest generics implementations. Now imagine if it had semicolons, ->, ! and '.
- mrkeen 10mo ago
  > You cherry picked a contrived example List.add is contrived? What are you doing that's simpler the list.add? > but that's one of the cleanest generics implementations. You're saying it's typically worse than this?
  - gethly 10mo ago
    He is referring to &element[T]{val: v} the & is a pointer, which is common across most languages, but the [T] is a dynamic type T. Otherwise it would be just &element{val: v} He says that element[T] is a clean/simple implementation of generics.

steveklabnik 10mo ago

I respect your preferences! I like punctuation. Even though I have a Perl tattoo, it'll never get like that, though. (Semicolon rules, for now at least, will be the same as Rust)