4 ms·

I haven't looked at Go yet, but all these "is so easy to learn" and "generics are bad because they're not easy to learn" articles on HN, I have to wonder if thi

I haven't looked at Go yet, but all these "is so easy to learn" and "generics are bad because they're not easy to learn" articles on HN, I have to wonder if this language is really so great or people push it because of the politics of people making it.

secure 9y ago
Only one way to find out… learn some Go? :) As author of this article, I can only say that I wrote about Go because I honestly like it, not because I have any agenda.
- weberc2 9y ago
  It will take all of 2 hours tops to go from zero to writing an interesting program.
weberc2 9y ago
While I do like that Go is ready to learn, I like that it is small enough to hold in my head. Pretty much everything works intuitively, save for a couple surprises. The same goes for its tooling. There is no complex project or package tooling to learn either. That said, it doesn't have a passable story for sum types or generics, which are important for the kind of programs I write these days. I'm convinced that summertime could build something as simple as Go, but with better abstraction facilities. Ideally this language would look like Rust and compile to Go.
- kuschku 9y ago
  > There is no complex project or package tooling to learn either. Question, how do you handle dependencies without them ending up checked in in your git? I’ve had no success yet with go and dependencies, there’s no simple way like in the Java world to just define a list of dependencies and have the built tool automatically fetch them in some dotfolder, and take care of the rest, is there?
  - hellcow 9y ago
    Use dep, which they're planning to add to the official tools like 'go get'. Then add your vendor directory to your gitignore, and you're done.
    - kuschku 9y ago
      I don’t want a vendor directory in the first place, how do I avoid that? I want it to just automatically do its stuff just like maven/gradle/sbt work, and not deal with any damn dependencies. I want it to automatically set the dependency path, and handle incremental compiles. If people claim it has so much better tooling than Java, then I expect at least it to work as well as Java’s tooling.
      - hellcow 9y ago
        I'm trying to understand your complaint. Obviously you'll need a vendor directory somewhere containing the source code of your dependencies. Maven places them outside the project's root dir (defaults to ~/.m2/repository), whereas Go puts them inside the project's root dir. Tomato-tomato. They have to exist on your system somewhere.
        kuschku 9y ago
        > They have to exist on your system somewhere. Yes, but they shouldn’t be something I’d have to ever care about. Whenever I type "build", the build tool should automatically manage the dependencies and invoke the build process.
      - weberc2 9y ago
        You're confused, Java's tooling is more complex/less intuitive. It doesn't matter where the dependency data lives on your system; it's completely transparent to you.
        kuschku 9y ago
        > It doesn't matter where the dependency data lives on your system; it's completely transparent to you. Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening. If I want to add a preprocessor, I import it the same way that I’d import a normal dependency, just with another directive – `compile 'com.jakewharton:butterknife:8.8.1'` vs `annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'`. This is something I really miss in the JS and Go and C and C++ world. It all just works.
geodel 9y ago
What politics?
dougbarrett 9y ago
To me, the language really is so great. I've discussed this with a friend, but in my 4.5 yrs of using it in production environments I've never found myself held back by the lack of generics. The apps I write need to be high availability, doing 1k req/sec on avg on one server, and go has never been the bottleneck. I come from originally a PHP background, and for me to do a fraction of what Go can do would require me to go in and mess with php config files and spin up more servers in order to get the performance I need, and with Go that's just not the case.

secure 9y ago

Only one way to find out… learn some Go? :) As author of this article, I can only say that I wrote about Go because I honestly like it, not because I have any agenda.

weberc2 9y ago
It will take all of 2 hours tops to go from zero to writing an interesting program.

weberc2 9y ago

While I do like that Go is ready to learn, I like that it is small enough to hold in my head. Pretty much everything works intuitively, save for a couple surprises. The same goes for its tooling. There is no complex project or package tooling to learn either. That said, it doesn't have a passable story for sum types or generics, which are important for the kind of programs I write these days. I'm convinced that summertime could build something as simple as Go, but with better abstraction facilities. Ideally this language would look like Rust and compile to Go.

kuschku 9y ago
> There is no complex project or package tooling to learn either. Question, how do you handle dependencies without them ending up checked in in your git? I’ve had no success yet with go and dependencies, there’s no simple way like in the Java world to just define a list of dependencies and have the built tool automatically fetch them in some dotfolder, and take care of the rest, is there?
- hellcow 9y ago
  Use dep, which they're planning to add to the official tools like 'go get'. Then add your vendor directory to your gitignore, and you're done.
  - kuschku 9y ago
    I don’t want a vendor directory in the first place, how do I avoid that? I want it to just automatically do its stuff just like maven/gradle/sbt work, and not deal with any damn dependencies. I want it to automatically set the dependency path, and handle incremental compiles. If people claim it has so much better tooling than Java, then I expect at least it to work as well as Java’s tooling.
    - hellcow 9y ago
      I'm trying to understand your complaint. Obviously you'll need a vendor directory somewhere containing the source code of your dependencies. Maven places them outside the project's root dir (defaults to ~/.m2/repository), whereas Go puts them inside the project's root dir. Tomato-tomato. They have to exist on your system somewhere.
      - kuschku 9y ago
        > They have to exist on your system somewhere. Yes, but they shouldn’t be something I’d have to ever care about. Whenever I type "build", the build tool should automatically manage the dependencies and invoke the build process.
    - weberc2 9y ago
      You're confused, Java's tooling is more complex/less intuitive. It doesn't matter where the dependency data lives on your system; it's completely transparent to you.
      - kuschku 9y ago
        > It doesn't matter where the dependency data lives on your system; it's completely transparent to you. Until some idiot checks it in on git despite the .gitignore (yes, this is possible, as I discovered after people accidentally did it). Java’s tooling is far more intuitive. I don’t have to configure a GOPATH, or deal with go get or deps or stuff, I simply define my build.gradle.kts, do gradle build, and I’m done. I don’t have to care where dependencies are, or what transpilation steps are happening. If I want to add a preprocessor, I import it the same way that I’d import a normal dependency, just with another directive – `compile 'com.jakewharton:butterknife:8.8.1'` vs `annotationProcessor 'com.jakewharton:butterknife-compiler:8.8.1'`. This is something I really miss in the JS and Go and C and C++ world. It all just works.

geodel 9y ago

What politics?

dougbarrett 9y ago

To me, the language really is so great. I've discussed this with a friend, but in my 4.5 yrs of using it in production environments I've never found myself held back by the lack of generics. The apps I write need to be high availability, doing 1k req/sec on avg on one server, and go has never been the bottleneck. I come from originally a PHP background, and for me to do a fraction of what Go can do would require me to go in and mess with php config files and spin up more servers in order to get the performance I need, and with Go that's just not the case.