3 ms·

Go is more verbose than Java, which you may very well consider overly verbose. The only reason it is between Python and Rust is that the two languages are two

by kaba0 3y ago

Go is more verbose than Java, which you may very well consider overly verbose. The only reason it is between Python and Rust is that the two languages are two extremes of low-high level languages. Go is as expressive as C, which is a negative.

threeseed 3y ago
> Go is more verbose than Java In real world use ridiculously so. The lack of exceptions, Option type or ability to chain or manipulate errors means every line ends up wrapped in a 90s style "if error" check. Which ends up making code less robust than languages with more modern approaches like Rust, Scala, Swift etc.
- xyproto 3y ago
  You can look at "if err == nil" and tell what is going on, but who knows which layer of exception handling will catch that "throws".
  - threeseed 3y ago
    In JVM languages it is easy to know what is catching what. The method type signatures clearly specify what exceptions will be thrown. And the compiler requires you to deliberately handle those exceptions. But I wouldn't consider Java to be the best approach for error handling anyway.
  - kaba0 3y ago
    Which is the only sane thing in most cases. What can you do inside the helper function of a helper function with an incorrect user data? The only sane place to handle it is n levels up, so bubbling up is the correct default. At least rust has a handy macro for it, but go’s error handling is catastrophic, not a proper sum type, nor some form of propagation… it is literally the bad errno from C burned into the language.
    - Aditya_Garg 3y ago
      In go, you should manually propagate the errors up by returning them. At the n levels up, you handle the error. It's a bit cumbersome during write time but a life saver during read/debug time.
      - kaba0 3y ago
        So manually obscuring the control flow/business logic with boilerplate bubbling up is more readable at debug/read time than it being implicitly, trivially there?
- memefrog 3y ago
  >90s style "if error" check What makes it '90s style' other than you don't like it? Calling something "90s style" and its alternative "modern" is a thought-terminating cliche.
  - deleted 3y ago
    [deleted]
  - kaba0 3y ago
    There have been many discussions on the topic of go’s error handling, the main gripes of people can be summarized as: - it returns both a return value and the error value, not xor. The convention is to use the error value only if returned, but sometimes the other “slot” is also used. If you squint a bit, this is exactly what errno does in C. The better, ML-y or exception-y way gives you a sum type instead, which can’t be mishandled. - you have to handle it in-place with no convenient shorthand allowing for handling it at another layer (and usually that’s the only meaningful way forward). Also, error handling is a cross-cutting concern, squeezing it inside your business logic is (in my opinion) a bad thing.
    - memefrog 3y ago
      It's not what errno does in C. errno in C is a thread-local variable which means accessing it is inefficient (it uses thread-local storage, which is much more expensive than a local variable) and you have to do awful things like save errno at the beginning of signal handlers if you call a function in the signal handler that can set errno (basically: any library function). Whether or not it's better to have a sum type (IMO it isn't), what Go has isn't anything like errno. errno is an ugly wart on the POSIX interface, which is otherwise quite nice. For example, Linux system calls directly return negative error codes, which is a much better way of handling errors, and then the libc has to set errno and return -1. Awful. >- you have to handle it in-place with no convenient shorthand allowing for handling it at another layer (and usually that’s the only meaningful way forward). Also, error handling is a cross-cutting concern, squeezing it inside your business logic is (in my opinion) a bad thing. That you say this and then advocate for optional<T>/result<t,e> is insane. That's exactly what a sum type does: it squeezes error handling into your business logic. And no, papering over that with ugly ? operators everywhere is not a solution, it is syntactic sugar. Error handling is part of the logic of your program. It is not just some 'ah we'll return it' thing. Many operations can fail and many errors are recoverable.
ssokolow 3y ago
> Go is more verbose than Java This. It's Rust, not Go, that has replaced Python for me in any use-case more than a few lines long where the ecosystem is ready (i.e. when I don't need a GUI (PyQt/PySide), SQL (SQLAlchemy+Alembic and Django ORM autogenerate draft migrations by diffing the schema against the DB), or complex web stuff (Django's giant ecosystem of reusable components)), because... 1. Boilerplate like `if err == nil` is demotivating 2. "If it compiles, it works" is very motivating and, aside from having `#[test]`, a type system constraint is worth a thousand unit tests. Heck, as efforts continue toward things like making LLD the default linker (40-50% reduction in link times) and making an official/stock interpretation of the rust-script utility (https://rust-script.org/ https://rust-script.org/), and as I work toward replacing my dual-core AMD CPU from 2011, Rust is going to push even further into being what I use to write "shell scripts" because "It works. Don't ** with it" is the number one psychological effect I have to push back against in other languages.

by kaba0 3y ago

threeseed 3y ago

> Go is more verbose than Java In real world use ridiculously so. The lack of exceptions, Option type or ability to chain or manipulate errors means every line ends up wrapped in a 90s style "if error" check. Which ends up making code less robust than languages with more modern approaches like Rust, Scala, Swift etc.

xyproto 3y ago
You can look at "if err == nil" and tell what is going on, but who knows which layer of exception handling will catch that "throws".
- threeseed 3y ago
  In JVM languages it is easy to know what is catching what. The method type signatures clearly specify what exceptions will be thrown. And the compiler requires you to deliberately handle those exceptions. But I wouldn't consider Java to be the best approach for error handling anyway.
- kaba0 3y ago
  Which is the only sane thing in most cases. What can you do inside the helper function of a helper function with an incorrect user data? The only sane place to handle it is n levels up, so bubbling up is the correct default. At least rust has a handy macro for it, but go’s error handling is catastrophic, not a proper sum type, nor some form of propagation… it is literally the bad errno from C burned into the language.
  - Aditya_Garg 3y ago
    In go, you should manually propagate the errors up by returning them. At the n levels up, you handle the error. It's a bit cumbersome during write time but a life saver during read/debug time.
    - kaba0 3y ago
      So manually obscuring the control flow/business logic with boilerplate bubbling up is more readable at debug/read time than it being implicitly, trivially there?
memefrog 3y ago
>90s style "if error" check What makes it '90s style' other than you don't like it? Calling something "90s style" and its alternative "modern" is a thought-terminating cliche.
- deleted 3y ago
  [deleted]
- kaba0 3y ago
  There have been many discussions on the topic of go’s error handling, the main gripes of people can be summarized as: - it returns both a return value and the error value, not xor. The convention is to use the error value only if returned, but sometimes the other “slot” is also used. If you squint a bit, this is exactly what errno does in C. The better, ML-y or exception-y way gives you a sum type instead, which can’t be mishandled. - you have to handle it in-place with no convenient shorthand allowing for handling it at another layer (and usually that’s the only meaningful way forward). Also, error handling is a cross-cutting concern, squeezing it inside your business logic is (in my opinion) a bad thing.
  - memefrog 3y ago
    It's not what errno does in C. errno in C is a thread-local variable which means accessing it is inefficient (it uses thread-local storage, which is much more expensive than a local variable) and you have to do awful things like save errno at the beginning of signal handlers if you call a function in the signal handler that can set errno (basically: any library function). Whether or not it's better to have a sum type (IMO it isn't), what Go has isn't anything like errno. errno is an ugly wart on the POSIX interface, which is otherwise quite nice. For example, Linux system calls directly return negative error codes, which is a much better way of handling errors, and then the libc has to set errno and return -1. Awful. >- you have to handle it in-place with no convenient shorthand allowing for handling it at another layer (and usually that’s the only meaningful way forward). Also, error handling is a cross-cutting concern, squeezing it inside your business logic is (in my opinion) a bad thing. That you say this and then advocate for optional<T>/result<t,e> is insane. That's exactly what a sum type does: it squeezes error handling into your business logic. And no, papering over that with ugly ? operators everywhere is not a solution, it is syntactic sugar. Error handling is part of the logic of your program. It is not just some 'ah we'll return it' thing. Many operations can fail and many errors are recoverable.

ssokolow 3y ago

> Go is more verbose than Java This. It's Rust, not Go, that has replaced Python for me in any use-case more than a few lines long where the ecosystem is ready (i.e. when I don't need a GUI (PyQt/PySide), SQL (SQLAlchemy+Alembic and Django ORM autogenerate draft migrations by diffing the schema against the DB), or complex web stuff (Django's giant ecosystem of reusable components)), because... 1. Boilerplate like `if err == nil` is demotivating 2. "If it compiles, it works" is very motivating and, aside from having `#[test]`, a type system constraint is worth a thousand unit tests. Heck, as efforts continue toward things like making LLD the default linker (40-50% reduction in link times) and making an official/stock interpretation of the rust-script utility (https://rust-script.org/ https://rust-script.org/), and as I work toward replacing my dual-core AMD CPU from 2011, Rust is going to push even further into being what I use to write "shell scripts" because "It works. Don't ** with it" is the number one psychological effect I have to push back against in other languages.