5 ms·

Out of curiosity, would you share those flaws you have found?

• apta 7y ago
  I will hopefully later today, not able to type much now.
• apta 7y ago
  This is by no means a comprehensive list: * no generics * null pointers * no compile time checked enums or sum types * The golang time package is garbage * golang interfaces are garbage, can't tag types with an interface without implementing a dummy method and hope that no other type implements it. Can't find what interfaces a type implements without an IDE * profiling and debugging tools are nothing in front of JVM and .NET tools * no const/immutablility * no ternary operator, need to write 6 lines instead of a single line if it existed * error handling is error prone and verbose * no default method implementation in interfaces * unit testing frameworks are sucky and rely on code gen, can't mock arbitrary types, but only by defining an interface * that unnused variables and imports are compile time errors, makes it very annoying and time consuming to prototype or when debugging * no private/public/etc modifier. if you want to change the visibility of a type, you need to rename it in all files it's listed in * no incremental compilation (yes Java compiles faster in large projects where I only modify a handful of files, or even more) * pervasive use of single letter identifiers in golang code bases * pervasive use of int, which has a platform dependent size * pervasive instantiation of structs by calling them structFoo { Field1: field1, Field2: field2, ... FieldN: fieldN }, which makes it easy to miss when a new field gets added. Rust and Zig solve this by making it required to specify all fields and values. * defer works on the function scope, not the current scope * defer doesn't handle functions that return errors, meaning many errors are missed * no struct or file private, only package private * the global scope is polluted with special functions like len, copy, delete, make, new, append, for no good reason * golang imports don't support cyclic imports * golang doesn't allow you to import a a specific function or struct from a package. You have you always qualify anything with the package name, which makes things verbose and awkward.
  • loicd 7y ago
    Thanks for the writing. I had noticed some of the things you wrote but not all (I am not a Go programmer though I keep track of what is happening there). Your post made me look a bit more into 'defer'. I did not expect it to be a source of errors.
    • apta 7y ago
      No problem. As a side note, the Zig language does a much better job here, especially with defer. It works at the scope level (how it's supposed to be), and they have an `errdefer` construct used to call functions that return errors.
  • sagichmal 7y ago
    > no incremental compilation Not true, unless you're using an esoteric definition of "incremental". > imports don't support cyclic imports Why on earth would you consider this bad?
    • qtplatypus 7y ago
      The problem that I've ran into with the lack of cyclic imports is that I like to arrange the contents of packages logically. However sometimes in order to do this it would result in a circular dependency between two packages. So rather then getting a logical arrangement we have to refactor it into an artificial package to resolve this depenancy.
      • sagichmal 7y ago
        Circular imports are always a design error, no "logical" to it.