4 ms·

I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then

by _ph_ 5y ago

I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then by not being able to do things, because a language feature is missing. That is, why I like Go so much. It strikes a great balance between important high-level features (GC, first class functions and closures) and still being a simple language (like Scheme is, in a sense they are very comparable in my eyes). The interface concept is great for covering a lot of cases. That is, why so far, I have not missed generics much and was rather reluctant to the constant wishes to add them to the language. On the other side, there are cases, even if they are not very frequent, where generics do help a lot. Just the new slices package allone almost justifies the addition of generics. Furthermore, the proposal looks very much Go-like. As a consequence, I am quite looking forward to try them out and used responsibly[1], they can be a great addition to the Go universe. 1: I think the situation is somewhat similar to Lisp macros. Normally, a codebase rarely requires macros and readability is better, if you avoid creating too many macros. But occasionally there are situations, where using a macro tremendeously increases code quality. Both implementation and readability-wise. There macros should be used and it is great to have them available.

zarzavat 5y ago
I used to really hate Go's attitude to generics and type system features in general. I still do, but I appreciate that it's a matter of taste, and that different people have different tolerances for language complexity. People who like simplicity can use Go and people who like type systems can use Rust.
- pharmakom 5y ago
  Weird to think of Rust as an alternative to Go imo. C# and Java are more similar to Go (mostly due to GC), but with generics etc
papito 5y ago
I roll my eyes when someone claims "I learned Go over the weekend". It's one thing to learn basic syntax, and completely another to learn the customs of your new environment so most can understand what you are doing. Go is one of the hardest languages to learn. First of all, some concepts in it are very different from "mainstream" languages, and it takes a while to get used to them. Simple things that exist in almost every other ecosystem can be absent in Go. Want to run setup code before your test suite? You on your own, buddy. And, oh yeah, 2/3 of your code will be `if err` statements, because exceptions are passé. I learned it by seeking out good Go codebases, which are incredibly rare. Hashi's Terraform comes to mind. Infamously, the early Kubernetes code was a nightmare because it lifted and shifted Java idioms and that was at the company that invented the Language. Or at Uber, where they passed on Go's native goroutines and channels in favor of homegrown concurrency, for SOME reason: https://eng.uber.com/go-geofence-highest-query-per-second-service/ https://eng.uber.com/go-geofence-highest-query-per-second-se... All this to show that Go is not a simple language to do well, so let's dispense with that myth. It has its uses, but having done it, I would never recommend Go for a greenfield project in my place of work - there are very few rules that come with it, and it requires tons of coordination and discipline among a team. And if you have to work with 2 or 3 other people who have strong opinions on how to do things in Go, watch out.
- _ph_ 5y ago
  I have not claimed you can "learn Go over the weekend". Not in a deeper sense where you could expect to design large projects and take the right decisions. But you can get a pretty good basic Go intro in a few days and be pretty productive after that. It isn't that different from most languages and has a rather small core. Of course, it helps if you have Scheme experience, to understand all the power of high order functions etc.
- Someone 5y ago
  IMO, “learning the language” and “getting used to it” are different things. The first is a purely theoretical exercise, the second a applied one that involves not only the language but also its ecosystem (implementation(s), library of functions and tooling)
  - papito 5y ago
    I am not sure if we are agreeing or not, but I feel like we are. I think when people refer to "learning" a language, they mean they actually know how to use it properly. Learning the syntax does not count - that is just trivia any one of us can do.
    - Someone 5y ago
      (Nitpick: I assume you mean learning both the syntax and the semantics. That isn’t always trivial, as some languages have features one may not have seen before) I think we mostly agree, too. However, I distinguish between learning a programming language and learning to use it. I learn many programming languages without ever writing any line of code in them. Once you’ve seen enough languages, if you combine that with reading about other people’s experience with working with the language, that can give you a decent idea about how the latter is without having to spend the effort (without being as good as doing it yourself, of course. Apart from “which one is the brake pedal”, I think I know how to drive a car, but I also know I can’t drive a car) That’s why I posted my first comment: the poster you replied to may share my opinion between “learning” and “learning to use”.

by _ph_ 5y ago

zarzavat 5y ago

I used to really hate Go's attitude to generics and type system features in general. I still do, but I appreciate that it's a matter of taste, and that different people have different tolerances for language complexity. People who like simplicity can use Go and people who like type systems can use Rust.

pharmakom 5y ago
Weird to think of Rust as an alternative to Go imo. C# and Java are more similar to Go (mostly due to GC), but with generics etc

papito 5y ago

I roll my eyes when someone claims "I learned Go over the weekend". It's one thing to learn basic syntax, and completely another to learn the customs of your new environment so most can understand what you are doing. Go is one of the hardest languages to learn. First of all, some concepts in it are very different from "mainstream" languages, and it takes a while to get used to them. Simple things that exist in almost every other ecosystem can be absent in Go. Want to run setup code before your test suite? You on your own, buddy. And, oh yeah, 2/3 of your code will be `if err` statements, because exceptions are passé. I learned it by seeking out good Go codebases, which are incredibly rare. Hashi's Terraform comes to mind. Infamously, the early Kubernetes code was a nightmare because it lifted and shifted Java idioms and that was at the company that invented the Language. Or at Uber, where they passed on Go's native goroutines and channels in favor of homegrown concurrency, for SOME reason: https://eng.uber.com/go-geofence-highest-query-per-second-service/ https://eng.uber.com/go-geofence-highest-query-per-second-se... All this to show that Go is not a simple language to do well, so let's dispense with that myth. It has its uses, but having done it, I would never recommend Go for a greenfield project in my place of work - there are very few rules that come with it, and it requires tons of coordination and discipline among a team. And if you have to work with 2 or 3 other people who have strong opinions on how to do things in Go, watch out.

_ph_ 5y ago
I have not claimed you can "learn Go over the weekend". Not in a deeper sense where you could expect to design large projects and take the right decisions. But you can get a pretty good basic Go intro in a few days and be pretty productive after that. It isn't that different from most languages and has a rather small core. Of course, it helps if you have Scheme experience, to understand all the power of high order functions etc.
Someone 5y ago
IMO, “learning the language” and “getting used to it” are different things. The first is a purely theoretical exercise, the second a applied one that involves not only the language but also its ecosystem (implementation(s), library of functions and tooling)
- papito 5y ago
  I am not sure if we are agreeing or not, but I feel like we are. I think when people refer to "learning" a language, they mean they actually know how to use it properly. Learning the syntax does not count - that is just trivia any one of us can do.
  - Someone 5y ago
    (Nitpick: I assume you mean learning both the syntax and the semantics. That isn’t always trivial, as some languages have features one may not have seen before) I think we mostly agree, too. However, I distinguish between learning a programming language and learning to use it. I learn many programming languages without ever writing any line of code in them. Once you’ve seen enough languages, if you combine that with reading about other people’s experience with working with the language, that can give you a decent idea about how the latter is without having to spend the effort (without being as good as doing it yourself, of course. Apart from “which one is the brake pedal”, I think I know how to drive a car, but I also know I can’t drive a car) That’s why I posted my first comment: the poster you replied to may share my opinion between “learning” and “learning to use”.