9 ms·

Go and Rust are harder to pick up. With weird operators and syntax. Maybe I am getting old, losing my edge or python has spoilt me. Even C# is elegant compar

Go and Rust are harder to pick up. With weird operators and syntax. Maybe I am getting old, losing my edge or python has spoilt me. Even C# is elegant compared to those two. I tried to learn both of them, but they just didnt excite me as much as C# or Python.

dgellow 7y ago
What weird operators and syntax do you have in Go? I'm asking because I feel the exact opposite. Someone who already knows a bit of a language with C-like syntax can pick it up very quickly.
- kumarvvr 7y ago
  For Go: 1. Exports from packages are to be defined with a Capital letter. To me, that is very hard to read. An explicit export statement is way better, if verbose. 2. Type declarations after variable (x int, y int), to me personally, is hard to read. Now I know a lot of people are fine with it, so this is a personal thing for me. 3. Multiple return values syntax is terrible. func split(sum int) (x, y int) { x = sum * 4 / 9 y = sum - x return } In this function, the sum is the input and x & y are outputs. The syntax seems weird to be. This also is a personal gripe. 4. Variable declarations can be var i, j int = 1,2 AND k:= 3 with implicit typing. To me this is a bad design, with various programmers choosing different methods to declare and initialize. Leads to a lot of cognitive overhead to read code, especially on large open source projects. Why not make it explicit to declare types? Sure, it's a bit of more work for the programmer, but in the long run, that bit of more initial work will save a lot of downstream confusion and frustrations. 5. Constants cannot be declared using := syntax. I am sure there is a valid reason for it, but assignment in the language for now is = , := and those can and cannot be used in various places. That is confusing. 6. For loop has no parenthesis for the loop initialization but needs {} for the loop blocks. This is really stupid. Personally, for(i:=0,i<100;i++) {} is a concise syntax and looks pleasing and readable. 7. To complicate it further the initialization and post statements are optional // This is a valid for loop in Go sum := 1 for ; sum<1000; { sum = sum + 1 } Isn't that confusing in itself. Sure, we don't have to write a loop that way, but some junior developer is going to write it anyway, and it muddles up the code for sure. 8. From the official Go Docs "At that point you can drop the semicolons: C's while is spelled for in Go" // This is a ALSO valid for loop in Go sum := 1 for sum<1000 { sum = sum + 1 } yay. 9. And then there is this gem in the "if" statement. if v := math.Pow(x, n); v < lim { return v } Yes, you can write an optional initial statement before the if condition. All this for what? So you save one extra line in the code? Sorry, the beards got too long and too tangled up for whoever came up with this idea. 10. Also, the initial statement you saw just after the if statement, the variable "v" is available in the scope of else/if and else statement blocks. But not outside the if/else scope. Yay, another way to confuse code readers. 10. What is up with the defer keyword to defer function calls until the "surrounding function returns". There are many more, but I think I have made it clear why, personally, Go is off putting. edit : Changed format a bit.
  - tomp 7y ago
    Try prefixing code with two spaces instead of a ">" sum := 1 for sum < 1000 { sum = sum + 1 }
  - nemo1618 7y ago
    Uppercase exports are great once you get used to them. You can know whether an identifier is exported instantly without having to look up its declaration. Agree that the multiple declaration/assignment syntaxes are unfortunate. Another example of this is that := can't be used for top-level declarations. Once you learn the rules you stop having to think about it, but if the rules were more consistent, they'd be easier to learn. The other big issue with Go's variables is shadowing. Again, one of those things that you pick up fairly quickly, but will bite newbies a few times. If-declarations are nice because they restrict the scope of a variable. I like knowing that I can see instantly that a particular variable is only used in three lines. Defer is a great way to clean up resources without the complexity of destructors and exceptions. Defer is also ubiquitous in code that needs to wrap accessor functions in a mutex. It's been adopted by a few other languages, which shows that it has merit. My only gripe with defer is that it only works on function scope; it'd be nice to have a defer scoped to a for loop. The other stuff is your personal preference, which I disagree with, but can't argue against :) I'll add another personal gripe of mine, though: typecasting is indistinguishable from a function call, e.g. Foo(bar) might be calling Foo on bar, or casting bar to type Foo. Those should really have different syntax.
  - traes 7y ago
    Don't know Go but I'm going to give it a shot: 1. Casing is a personal preference, so that's fair, but not a valid criticism. 2. Type decls after the variable are much easier to parse, and allow for (easier) type inference. 3. Yeah? References exist... C/C#/C++ have them too. 4. This ones a fair criticism. 5. That's because constants have a completely different syntax from variable assignment. 6. The parenthesis are syntactically unnecessary and add nothing, the curly braces are required for an unambiguous parser (barring significant whitespace). 7. This is true in almost every language with for loops. Try it in the JavaScript console in your browser. 8. Yeah? So? 9. The scoping is a feature, not a bug. E.G. if v := getResult(); v == Success { Print("Success!") } else { Print("Failed with error code ", v) } // v doesn't pollute namespace out here 10. That one I'm not educated enough to make a reply to.
- gonzo41 7y ago
  Flipped variable declaration. Duck typeing, And the idomatic use of := instead of explicit declaration. Also the use of _ and multiple return values (which i really like). Are all a little tricky to begin with. That use of := is my only very small hang up.
  - foldr 7y ago
    Whether variable declaration is 'flipped' or not depends on which languages you're used to. Duck typing has nothing to do with syntax or operators. ':=' is an explicit declaration (with simple type inference). The use of '_' to indicate an unused binding is common to many languages. Multiple return values in Go have about the simplest and most intuitive syntax imaginable. You separate the values with a comma both when returning them and when binding the returned values.
ahartmetz 7y ago
Rust has a similar "problem" as C++: it wants to be high level (for productivity) and close to the metal (for performance). Such languages are needed, but they are not going to be the easiest to learn. It is not their fault.
- m0xte 7y ago
  There has to be a simpler solution than Rust though. Rust seems to have started with some clear objectives but evolved into a nightmare. We should be putting the effort into the compilers and keeping the language free of cruft and any unsafe concerns. Much like Delphi did for example.
  - rwmj 7y ago
    For most, average userspace programs garbage collectors work very well. (Of course there are exceptional cases as I'm sure people will be quick to point out.) However if you deny garbage collection for all programs you have to replace it with something very complex to reason about, like RAII for C++ or borrow checking in Rust. Or you end up reimplementing GC inefficiently (C++ reference counting). Also certain algorithms -- persistent data structures with shared subgraphs and therefore cheap updates -- become very difficult to write because there's no local ownership of nodes, only something with a global program view (a GC) knows when an object is unreferenced and can be freed.
    - foldr 7y ago
      This. The Rust community seem to be pushing Rust as a more-or-less general purpose programming language. But giving up garbage collection never makes sense unless you have to. The applications where you really can't use GC are a tiny niche relative to the ones where you can.
      - StreamBright 7y ago
        >> The applications where you really can't use GC are a tiny niche relative to the ones where you can. And this is one space Rust is targeting explicitly. Why would people replace Go with Rust for performance reasons otherwise? https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...
m0xte 7y ago
Similar opinion. The only two things I consider worthy at this point are C and Python. Everything else seems to have lost the balance of compromise, stability, low API and language volatility, the ability to retain it and it's API in mind effectively and tool flexibility. On the Go front I have to say I like the language but not the rigidity which quite frankly gets in the way a lot of the time and turns minor experiments and refactoring into a time consuming nightmare. On the C# front, I've been writing C# since before the compile toolchain was even RTM and I dislike every moment now. It has become a bloated mess of a language and the supporting frameworks are impossible to keep track of and up to date. Edit: I prefer SBCL over everything really but that's another universe :)
- amedvednikov 7y ago
  > On the Go front I have to say I like the language but not the rigidity which quite frankly gets in the way a lot of the time and turns minor experiments and refactoring into a time consuming nightmare. Can you give an example of this?
fluffything 7y ago
Have you tried C++? Rust is an alternative to C++ or C, not to Go, C# or Python. Sure, you can write any program on any language, but if you try to write bare metal C code from C# or Python, your frustration will be quite large as well. Use the right tool for the job.
- kumarvvr 7y ago
  I have used C++. I understand about using the right tool for the job. But Rust and Go are not good tools solely due to their syntax.
- dragonsh 7y ago
  Just a minor correction, Rust is trying to be replacement of C++. It will be unlikely to replace C, at least for next 2-3 decades. C will serve as the low level language and Rust will be a higher level language. Today Rust needs LLVM (written in C++), to generate binaries and it may be 2-3 decades before Rust will be used to write anything like LLVM with supporting platforms. Today Rust library to do anything useful rely on unsafe integration with underlying C code. Rust is still on fringes and quite a complicated language compared to C. I still doubt it will be a replacement for either, may be it will go-exist with C/C++ on fringes and may be in next 30 years if it survives like Python might have significant code and can be useful in place of C++.
  - pjmlp 7y ago
    No language will replace C on its turf, FOSS UNIX clones and embedded POSIX RTOS. Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++. As for Rust, yes a co-existence is more likely.
    - jstimpfle 7y ago
      > Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++. You keep saying this, but I'd recommend you to look at a few random "C++" files in https://github.com/gcc-mirror/ https://github.com/gcc-mirror/ for example. For many of these projects, "moving to C++" often means to change the file extension. Or not even that, sometimes it's just changing the build setting to "Compile as C++". There's no reason for holy wars. Fact is that regular C code is still ruling the world. Maybe not in the financial industry. Maybe it's embedded in a few C++ syntactic constructs. Maybe some people even found a way to use RAII in a way that doesn't suck in a large project. But the vast majority of the stuff that does something is still dangerous, evil, ugly C. And now excuse me while I go watch another talk named "C++ Features to avoid" or "Taming build times in a large C++ codebase" or "Why we went back to plain C"
k__ 7y ago
Have you looked at Nim?

dgellow 7y ago

What weird operators and syntax do you have in Go? I'm asking because I feel the exact opposite. Someone who already knows a bit of a language with C-like syntax can pick it up very quickly.

kumarvvr 7y ago
For Go: 1. Exports from packages are to be defined with a Capital letter. To me, that is very hard to read. An explicit export statement is way better, if verbose. 2. Type declarations after variable (x int, y int), to me personally, is hard to read. Now I know a lot of people are fine with it, so this is a personal thing for me. 3. Multiple return values syntax is terrible. func split(sum int) (x, y int) { x = sum * 4 / 9 y = sum - x return } In this function, the sum is the input and x & y are outputs. The syntax seems weird to be. This also is a personal gripe. 4. Variable declarations can be var i, j int = 1,2 AND k:= 3 with implicit typing. To me this is a bad design, with various programmers choosing different methods to declare and initialize. Leads to a lot of cognitive overhead to read code, especially on large open source projects. Why not make it explicit to declare types? Sure, it's a bit of more work for the programmer, but in the long run, that bit of more initial work will save a lot of downstream confusion and frustrations. 5. Constants cannot be declared using := syntax. I am sure there is a valid reason for it, but assignment in the language for now is = , := and those can and cannot be used in various places. That is confusing. 6. For loop has no parenthesis for the loop initialization but needs {} for the loop blocks. This is really stupid. Personally, for(i:=0,i<100;i++) {} is a concise syntax and looks pleasing and readable. 7. To complicate it further the initialization and post statements are optional // This is a valid for loop in Go sum := 1 for ; sum<1000; { sum = sum + 1 } Isn't that confusing in itself. Sure, we don't have to write a loop that way, but some junior developer is going to write it anyway, and it muddles up the code for sure. 8. From the official Go Docs "At that point you can drop the semicolons: C's while is spelled for in Go" // This is a ALSO valid for loop in Go sum := 1 for sum<1000 { sum = sum + 1 } yay. 9. And then there is this gem in the "if" statement. if v := math.Pow(x, n); v < lim { return v } Yes, you can write an optional initial statement before the if condition. All this for what? So you save one extra line in the code? Sorry, the beards got too long and too tangled up for whoever came up with this idea. 10. Also, the initial statement you saw just after the if statement, the variable "v" is available in the scope of else/if and else statement blocks. But not outside the if/else scope. Yay, another way to confuse code readers. 10. What is up with the defer keyword to defer function calls until the "surrounding function returns". There are many more, but I think I have made it clear why, personally, Go is off putting. edit : Changed format a bit.
- tomp 7y ago
  Try prefixing code with two spaces instead of a ">" sum := 1 for sum < 1000 { sum = sum + 1 }
- nemo1618 7y ago
  Uppercase exports are great once you get used to them. You can know whether an identifier is exported instantly without having to look up its declaration. Agree that the multiple declaration/assignment syntaxes are unfortunate. Another example of this is that := can't be used for top-level declarations. Once you learn the rules you stop having to think about it, but if the rules were more consistent, they'd be easier to learn. The other big issue with Go's variables is shadowing. Again, one of those things that you pick up fairly quickly, but will bite newbies a few times. If-declarations are nice because they restrict the scope of a variable. I like knowing that I can see instantly that a particular variable is only used in three lines. Defer is a great way to clean up resources without the complexity of destructors and exceptions. Defer is also ubiquitous in code that needs to wrap accessor functions in a mutex. It's been adopted by a few other languages, which shows that it has merit. My only gripe with defer is that it only works on function scope; it'd be nice to have a defer scoped to a for loop. The other stuff is your personal preference, which I disagree with, but can't argue against :) I'll add another personal gripe of mine, though: typecasting is indistinguishable from a function call, e.g. Foo(bar) might be calling Foo on bar, or casting bar to type Foo. Those should really have different syntax.
- traes 7y ago
  Don't know Go but I'm going to give it a shot: 1. Casing is a personal preference, so that's fair, but not a valid criticism. 2. Type decls after the variable are much easier to parse, and allow for (easier) type inference. 3. Yeah? References exist... C/C#/C++ have them too. 4. This ones a fair criticism. 5. That's because constants have a completely different syntax from variable assignment. 6. The parenthesis are syntactically unnecessary and add nothing, the curly braces are required for an unambiguous parser (barring significant whitespace). 7. This is true in almost every language with for loops. Try it in the JavaScript console in your browser. 8. Yeah? So? 9. The scoping is a feature, not a bug. E.G. if v := getResult(); v == Success { Print("Success!") } else { Print("Failed with error code ", v) } // v doesn't pollute namespace out here 10. That one I'm not educated enough to make a reply to.
gonzo41 7y ago
Flipped variable declaration. Duck typeing, And the idomatic use of := instead of explicit declaration. Also the use of _ and multiple return values (which i really like). Are all a little tricky to begin with. That use of := is my only very small hang up.
- foldr 7y ago
  Whether variable declaration is 'flipped' or not depends on which languages you're used to. Duck typing has nothing to do with syntax or operators. ':=' is an explicit declaration (with simple type inference). The use of '_' to indicate an unused binding is common to many languages. Multiple return values in Go have about the simplest and most intuitive syntax imaginable. You separate the values with a comma both when returning them and when binding the returned values.

ahartmetz 7y ago

Rust has a similar "problem" as C++: it wants to be high level (for productivity) and close to the metal (for performance). Such languages are needed, but they are not going to be the easiest to learn. It is not their fault.

m0xte 7y ago
There has to be a simpler solution than Rust though. Rust seems to have started with some clear objectives but evolved into a nightmare. We should be putting the effort into the compilers and keeping the language free of cruft and any unsafe concerns. Much like Delphi did for example.
- rwmj 7y ago
  For most, average userspace programs garbage collectors work very well. (Of course there are exceptional cases as I'm sure people will be quick to point out.) However if you deny garbage collection for all programs you have to replace it with something very complex to reason about, like RAII for C++ or borrow checking in Rust. Or you end up reimplementing GC inefficiently (C++ reference counting). Also certain algorithms -- persistent data structures with shared subgraphs and therefore cheap updates -- become very difficult to write because there's no local ownership of nodes, only something with a global program view (a GC) knows when an object is unreferenced and can be freed.
  - foldr 7y ago
    This. The Rust community seem to be pushing Rust as a more-or-less general purpose programming language. But giving up garbage collection never makes sense unless you have to. The applications where you really can't use GC are a tiny niche relative to the ones where you can.
    - StreamBright 7y ago
      >> The applications where you really can't use GC are a tiny niche relative to the ones where you can. And this is one space Rust is targeting explicitly. Why would people replace Go with Rust for performance reasons otherwise? https://blog.discord.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f https://blog.discord.com/why-discord-is-switching-from-go-to...

m0xte 7y ago

Similar opinion. The only two things I consider worthy at this point are C and Python. Everything else seems to have lost the balance of compromise, stability, low API and language volatility, the ability to retain it and it's API in mind effectively and tool flexibility. On the Go front I have to say I like the language but not the rigidity which quite frankly gets in the way a lot of the time and turns minor experiments and refactoring into a time consuming nightmare. On the C# front, I've been writing C# since before the compile toolchain was even RTM and I dislike every moment now. It has become a bloated mess of a language and the supporting frameworks are impossible to keep track of and up to date. Edit: I prefer SBCL over everything really but that's another universe :)

amedvednikov 7y ago
> On the Go front I have to say I like the language but not the rigidity which quite frankly gets in the way a lot of the time and turns minor experiments and refactoring into a time consuming nightmare. Can you give an example of this?

fluffything 7y ago

Have you tried C++? Rust is an alternative to C++ or C, not to Go, C# or Python. Sure, you can write any program on any language, but if you try to write bare metal C code from C# or Python, your frustration will be quite large as well. Use the right tool for the job.

kumarvvr 7y ago
I have used C++. I understand about using the right tool for the job. But Rust and Go are not good tools solely due to their syntax.
dragonsh 7y ago
Just a minor correction, Rust is trying to be replacement of C++. It will be unlikely to replace C, at least for next 2-3 decades. C will serve as the low level language and Rust will be a higher level language. Today Rust needs LLVM (written in C++), to generate binaries and it may be 2-3 decades before Rust will be used to write anything like LLVM with supporting platforms. Today Rust library to do anything useful rely on unsafe integration with underlying C code. Rust is still on fringes and quite a complicated language compared to C. I still doubt it will be a replacement for either, may be it will go-exist with C/C++ on fringes and may be in next 30 years if it survives like Python might have significant code and can be useful in place of C++.
- pjmlp 7y ago
  No language will replace C on its turf, FOSS UNIX clones and embedded POSIX RTOS. Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++. As for Rust, yes a co-existence is more likely.
  - jstimpfle 7y ago
    > Everywhere else C has been being replaced a good part of the last two decades, even all major C compilers are written in C++. You keep saying this, but I'd recommend you to look at a few random "C++" files in https://github.com/gcc-mirror/ https://github.com/gcc-mirror/ for example. For many of these projects, "moving to C++" often means to change the file extension. Or not even that, sometimes it's just changing the build setting to "Compile as C++". There's no reason for holy wars. Fact is that regular C code is still ruling the world. Maybe not in the financial industry. Maybe it's embedded in a few C++ syntactic constructs. Maybe some people even found a way to use RAII in a way that doesn't suck in a large project. But the vast majority of the stuff that does something is still dangerous, evil, ugly C. And now excuse me while I go watch another talk named "C++ Features to avoid" or "Taming build times in a large C++ codebase" or "Why we went back to plain C"

k__ 7y ago

Have you looked at Nim?