5 ms·

It's certainly possible for individuals to swim against the current. I am not a Go programmer but all the Go open source code I have read has been brutally simp

• valyala 6y ago
  I'm a Go programmer and I can confirm that Go code (both written by me and by anybody else) is easy to read, debug and refactor. This is thanks to simple yet powerful Go syntax, which doesn't allow constructing implicitly executed code. I.e. it doesn't support the following "features" from other programming languages, which instantly increase code complexity because it becomes impossible to understand the code by just reading it top down: * Operator overloading * Function overloading * Constructors and destructors * Implicit type conversion * Implicit types (classes) Go also doesn't support type templates and function templates yet (aka generics or contracts). This also plays significant role in easy-to-read Go code. P.S. I wrote many packages and apps in Go during the last 10 years [1] and I absolutely love Go! Check out my last project in Go - VictoriaMetrics - fast time series database and monitoring solution [2]. [1] https://github.com/valyala/ https://github.com/valyala/ [2] https://github.com/valyala/VictoriaMetrics https://github.com/valyala/VictoriaMetrics
  • somebodynew 6y ago
    As a C++ developer, highlighting the lack of destructors made me curious how resource closure is typically handled in Go. A brief review suggests that it is often handled using a "defer statement", which accumulates a stack of statements to be executed when the function returns, to execute a 'close()' method. While I can see some benefit to the explicit appearance of "defer" in the source code, I think it is outweighed by the risk someone forgets to write it (or tries to close something without defer but misses a path). The execution of a destructor is inevitable and automatic.
    • valyala 6y ago
      The main issue with destructors is that it is impossible to determine by reading the code which destructors in which order at which lines may be called. Actually, destructors can be called on every line of C++ code because of exceptions. This complicates understanding code flow and makes almost impossible to write exception-safe C++ code, which properly releases resources at any exception. While Go supports exception-like panics, they are mostly used for really exceptional cases, when the program cannot proceed further, such as out-of-range slice accces or nil pointer dereference. Almost all these cases are triggered by programming errors, which must be fixed after the panic occurs. Traditional error handling is performed explicitly in Go instead of relying on panics - the error is checked explicitly after function call. This simplifies code reading and makes easy to spot cases with missing or incorrect error handling. These tasks are almost impossible with try/catch error handling.
      • jcelerier 6y ago
        > The main issue with destructors is that it is impossible to determine by reading the code which destructors in which order at which lines may be called. huh ? the destructors are just in reverse order than the declaration order