4 ms·

I'm a sysadmin type, so take this with a grain of salt. Like: - Compiled and can be run as a scripting language. - Easy to learn, quite simple to use (even c

by dijit 4y ago

I'm a sysadmin type, so take this with a grain of salt. Like: - Compiled and can be run as a scripting language. - Easy to learn, quite simple to use (even concurrency!) - Cross compilation is an environment variable setting. - Fast compilation, though apparently this gets worse with reflection and generics (and it's not that important to me honestly) Dislike: - The opinionated build/dependency system, which sort of doesn't work with monorepos unless you do things that "are not recommended" like `insteadOf` - When deserialising things (JSON for example), an omitted key becomes an empty value. As many will tell you, there is a difference between 0 and Null/None. - Case based visibility. That feels like the opposite of clear. - Slice semantics, easy to accidentally override values if you're not careful. (slices are references to arrays, you can reference a subset of a slice which looks like a new slice, but appending to it will overwrite a value in original array, because when you do `var slice_new := slice_old[0:30]`; it's really just a reference to slice_old, not a new slice with the contents from 0-30.

liampulles 4y ago
nit: One can use pointer values for marking JSON fields as optional, and thus distinguish between the 0 and nil case. I felt similar to you initially about the difference between 0 and Null/None - I have to say that once I started modelling my APIs so that these two cases could be treated equivalently, I think the quality of my APIs improved.
- michele 4y ago
  Not really: it still can't tell the difference between a null value and a missing field which is different when working with APIs as a missing field usually means "don't touch it" while null means "nullify it"
cratermoon 4y ago
I love case-based visibility. I don't have to look at any declaration beyond the name to know if I can use the identifier outside of the package it's declared in. In most other languages case is just convention and visibility is determined by another keyword. Yes, I know programmers who came from a Java or C# background who continue to use naming conventions from those languages, to their detriment. I don't blame Go for their problems, though.
- dijit 4y ago
  To each their own, it doesn’t sit well with me and I got used to `grep -rE ‘^pub’ <module>` to lazily get an idea of what is available to me. Glad it works for you though, it’s not likely to change with my little whinge. :)
- joshuak 4y ago
  I really hated this feature at first, but it's one of my absolute favorite things about Go now. In general Go communicates more information than other programming languages without nearly as much visual clutter. When reading code one rarely needs to check elsewhere to fully understand what is intended.
- sidlls 4y ago
  I don't even like the concept of visibility--at least as implemented in C++, go, Rust, and a host of others. The whole notion of "getters and setters" just seems like so much pointless boilerplate. Explicitly requiring mutability, as Rust does, is much better for data encapsulation and protection.

by dijit 4y ago

liampulles 4y ago

nit: One can use pointer values for marking JSON fields as optional, and thus distinguish between the 0 and nil case. I felt similar to you initially about the difference between 0 and Null/None - I have to say that once I started modelling my APIs so that these two cases could be treated equivalently, I think the quality of my APIs improved.

michele 4y ago
Not really: it still can't tell the difference between a null value and a missing field which is different when working with APIs as a missing field usually means "don't touch it" while null means "nullify it"

cratermoon 4y ago

I love case-based visibility. I don't have to look at any declaration beyond the name to know if I can use the identifier outside of the package it's declared in. In most other languages case is just convention and visibility is determined by another keyword. Yes, I know programmers who came from a Java or C# background who continue to use naming conventions from those languages, to their detriment. I don't blame Go for their problems, though.

dijit 4y ago
To each their own, it doesn’t sit well with me and I got used to `grep -rE ‘^pub’ <module>` to lazily get an idea of what is available to me. Glad it works for you though, it’s not likely to change with my little whinge. :)
joshuak 4y ago
I really hated this feature at first, but it's one of my absolute favorite things about Go now. In general Go communicates more information than other programming languages without nearly as much visual clutter. When reading code one rarely needs to check elsewhere to fully understand what is intended.
sidlls 4y ago
I don't even like the concept of visibility--at least as implemented in C++, go, Rust, and a host of others. The whole notion of "getters and setters" just seems like so much pointless boilerplate. Explicitly requiring mutability, as Rust does, is much better for data encapsulation and protection.