7 ms·

I would argue that Go's opinionated style is what makes it elegant. It's a programming language for people who are sick of programming languages. It makes clear

I would argue that Go's opinionated style is what makes it elegant. It's a programming language for people who are sick of programming languages. It makes clear promises and delivers on exactly those - it belongs in new code for that reason.

Milner08 7y ago
"a programming language for people who are sick of programming languages" is nonsense.
- neilalexander 7y ago
  Why?
  - gonzo41 7y ago
    Look at Java. Look at Spring and look at all the other junk out there. Every corner you go around you see smart people trying to outsmart each other rather than solve problems. Go makes that harder.
    - vips7L 7y ago
      Spring boot is fantastic if you havent checked it out.
      - sagichmal 7y ago
        Spring Boot is precisely the magical nonsense the GP was complaining about.
        gerbilly 7y ago
        I like Java and Spring, but I don't use Spring boot. Note that just because the recent tutorials out there mention Spring Boot, doesn't mean you can't wire together a Spring app either through config files or programatically.
        vips7L 7y ago
        In my opinion, its not any more magical than any other framework. What it is though is something that solves problems and has a great ecosystem, instead of reinventing the wheel.
    - gerbilly 7y ago
      Spring and Java aren't junk. I like Go for some things, but when using it I miss many things from Java: * I can connect to the running JVM and change log levels, and other parameters live. * I can debug a Java file that has compilation errors in it and fix them as I go in some cases. (In Go you can't even compile a file with an unused import) * Java libraries and frameworks are mature. Some have been around for decades with all the testing and refinement that implies. For some applications, like a REST server connecting to a database, why would I use Go and use all it's brand new, limited libraries when I could use dropwizard instead and get an easy to deploy JAR file? Sure Java has some esoteric features, but you don't have to use them. If you can't keep your team from being clever in Java, I doubt you'll be able to do so just because they use Go. I've seen many Go libraries attempt to use introspection and backtick 'annotations' to very confusing and buggy effect.
    - apta 7y ago
      I'll just leave this here: http://gorm.io/docs/many_to_many.html http://gorm.io/docs/many_to_many.html, http://gorm.io/docs/has_one.html#Association-ForeignKey http://gorm.io/docs/has_one.html#Association-ForeignKey
- pdpi 7y ago
  Is it nonsense? Makes perfect sense to me. There are programmers who don't get excited about languages as a topic and would rather just get on with it. "People who are sick of programming languages" seems like an apt description for that crowd. I personally dislike Go, precisely for many of the reasons why those "people who are sick of programming languages" would like it!
  - oddthink 7y ago
    I like the phrase, too. I'm on the "sick of programming languages" side, and I like go, for the things I'm using it for: CLIs, simple debug web-servers, calling out to RPC services. (Read a CSV file, run everything through translate / grammar parsing / etc.) I'm in that age of folks that did pascal in high school, C and Scheme in college, C++ and python in grad school while futzing around with ocaml and common lisp and sather and other fun things. Programming languages are fun. But, oh, I have so much other stuff to pay attention to. I write C++ a few days a week, which is barely enough to keep move semantics in my head. I also write SQL and analysis docs and internal DSLs and configuration files and python. At this point, C++ is barely earning its keep, in terms of mental complexity for reward. Go feels a lot nicer, since I can just get in, do my thing, get out, and it'll at least work and give me a compile error if one of the APIs change when I don't look at it for a year. I'm not about to jump into rust. So, at least for me, go hits a pretty good sweet spot. [Edit: I'm not trying to point fingers at rust in particular. It looks fun. If I weren't still working on getting my hobbyist-Haskell better, I'd probably be playing with it. But that would be at home, for fun, not where I have to have the thing in my head for production issues. It reminds me a bit of the old statement about perl, that it was a fantastic language if you used it every day, but not if you don't. And I don't get to use these things every day any more.]
- nl 7y ago
  Please give me this nonsense. I'm sick of programming languages.
  - 0815test 7y ago
    Protip: You can write FORTRAN in any language!
    - TheRealKing 7y ago
      Of course, you can (re)write code in any Turing-complete language in any other Turing-complete language.
randomvectors 7y ago
No, being opinionated by itself isn't a good enough reason to belong in new code.
- neilalexander 7y ago
  If you don't believe that making clear promises and delivering on them is, then what would you suggest is a better reason?
  - randomvectors 7y ago
    You're arguing with a point that I'm not making at all.
    - neilalexander 7y ago
      What is your point then? You're being obtuse.
  - vageli 7y ago
    > If you don't believe that making clear promises and delivering on them is, then what would you suggest is a better reason? How is "being opinionated" and "making clear promises and delivering on them" equivalent?
    - neilalexander 7y ago
      I didn't say they were. They weren't even in the same sentence in my original comment.
  - simiones 7y ago
    If the promises you are making are not appealing, even if they are clear and you deliver on them, you can't count that as a reason to use a language in new code.
lmm 7y ago
Go has been carefully designed to solve the problems of today. But relying on solving those problems at the language level means I have very low confidence that the language can adapt to solve the problems of tomorrow. They have built-in language-level support for concurrency, great - that's always going to be slightly more user friendly than a library-based solution. But what about when the next wave comes along? Are they going to be able to rework the whole language to incorporate whatever 2020's equivalent to the concurrency revolution is? While retaining compatibility with existing code? I would not want to use Go for any codebase that's expected to last more than a couple of years. I'd put a lot more faith in languages that were able to adapt elegantly to the challenges of concurrency at the library level, without requiring language changes - that suggests those languages will be able to adapt similarly to the next revolution. And my impression is that languages that started with a solid theoretical underpinning, and/or a small core language with as much as possible pushed out into libraries, handled the transition a lot better than languages with the more ad-hoc, practical-problem-first approach to design that Go has.
- dis-sys 7y ago
  The codebase of Go itself (which is in Go of course) has been there for multiple "couple of years" already.
- apta 7y ago
  I'm with you in general that golang code is very unmaintainable in the long term. > Go has been carefully designed to solve the problems of today. I'd even argue it was "carefully designed" to be in the 70's. Other than "goroutines", the language is stuck in that decade. No generics, no expression based syntax, exposing system-dependent "int" type and encouraging its use, badly designed interfaces that can't be used for tagging, badly designed time package, the list is too long to mention here.
  - jerf 7y ago
    And yet, people are solving problems in it, often quite well. I say this as one who has basically mastered Haskell, so it's not like I'm not aware of all these things: Fans of all these complicated abstractions really need to take some time and grapple with that fact. It will improve your programming in the more complicated languages as well. No, seriously. Stop for a moment and think about that. Consider the advanced features as a scientific prediction: "If you do not use these features, you can't have a good program come out the other end." This prediction is falsified by the concrete existence of a lot of good Go programs. This matters. It is something that should be grappled with intellectually, if you are a language fan. It will bring you to a deeper understanding of all the fancy features. By a deeper understanding, I mean that quite directly, with no attempt to be subtly saying something like "Oh, you'll find they're all useless in the end." That would not be true. They are not even remotely useless. They are incredibly useful. I would even go so far as to say that the development of these complicated sorts of features is legitimately among some of the most simultaneously interesting and useful intellectual work being done in our time, and greatly contributing to our ability to hold our software world together. It's just that the shape of that usefulness is more complicated than a lot of people realize, and a deeper understanding of that complication is very useful for developers. One of the things that I think really comes out of it is a yet deeper understanding of matching tools to problems. I use a lot of Go, because I write a lot of things that are at a size and complexity where those other language features just aren't that helpful. Yet, there are tasks I could be assigned where I wouldn't dream of using Go, because I know I would need all that fancy stuff to hold the program together. I can easily imagine ways in which my career trajectory would change in the next couple of years and I'd go primarily Rust; I can equally easily imagine ways in which I will stay primarily Go. I can imagine ways in which I'd need to go with some other language. I think a lot of programmers who find these fancy features and fall in love with them end up overestimating the scope of the set of programs where they can be helpful. To give a degenerate example, my six line shell script does not need to be written in the Rust type system. It is not only not helpful, it would be actively harmful. The scope of programs that don't really need those features and where they quite easily become actively harmful is larger than a lot of people think. Especially if you consider them in the context of a heterogeneous team of developers who may not all be in the 5+ years of experience range, or when you may not be able to guarantee that the project is going to stay in those hands.
coldtea 7y ago
>I would argue that Go's opinionated style is what makes it elegant I'd say Go is opinionatedly inelegant. It is minimal, I'll give you that, but has several non-orthogonal design decisions, smells, etc.
- tsavola 7y ago
  Please elaborate.
  - snarfy 7y ago
    This article [1] explains why I'm not a fan. [1] - https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html https://www.teamten.com/lawrence/writings/why-i-dont-like-go...
  - dnautics 7y ago
    If err != nil everywhere is definitely a code smell and poor language design.
  - coldtea 7y ago
    Not compile-time checked repetitive error handling (if null != err), duality of panic and error codes, specially blessed constructs (maps, slices, etc being "generic"), lack of expressivity, specially typed map libs, interface{} type safety escape hatch, etc...

Milner08 7y ago

"a programming language for people who are sick of programming languages" is nonsense.

neilalexander 7y ago
Why?
- gonzo41 7y ago
  Look at Java. Look at Spring and look at all the other junk out there. Every corner you go around you see smart people trying to outsmart each other rather than solve problems. Go makes that harder.
  - vips7L 7y ago
    Spring boot is fantastic if you havent checked it out.
    - sagichmal 7y ago
      Spring Boot is precisely the magical nonsense the GP was complaining about.
      - gerbilly 7y ago
        I like Java and Spring, but I don't use Spring boot. Note that just because the recent tutorials out there mention Spring Boot, doesn't mean you can't wire together a Spring app either through config files or programatically.
      - vips7L 7y ago
        In my opinion, its not any more magical than any other framework. What it is though is something that solves problems and has a great ecosystem, instead of reinventing the wheel.
  - gerbilly 7y ago
    Spring and Java aren't junk. I like Go for some things, but when using it I miss many things from Java: * I can connect to the running JVM and change log levels, and other parameters live. * I can debug a Java file that has compilation errors in it and fix them as I go in some cases. (In Go you can't even compile a file with an unused import) * Java libraries and frameworks are mature. Some have been around for decades with all the testing and refinement that implies. For some applications, like a REST server connecting to a database, why would I use Go and use all it's brand new, limited libraries when I could use dropwizard instead and get an easy to deploy JAR file? Sure Java has some esoteric features, but you don't have to use them. If you can't keep your team from being clever in Java, I doubt you'll be able to do so just because they use Go. I've seen many Go libraries attempt to use introspection and backtick 'annotations' to very confusing and buggy effect.
  - apta 7y ago
    I'll just leave this here: http://gorm.io/docs/many_to_many.html http://gorm.io/docs/many_to_many.html, http://gorm.io/docs/has_one.html#Association-ForeignKey http://gorm.io/docs/has_one.html#Association-ForeignKey
pdpi 7y ago
Is it nonsense? Makes perfect sense to me. There are programmers who don't get excited about languages as a topic and would rather just get on with it. "People who are sick of programming languages" seems like an apt description for that crowd. I personally dislike Go, precisely for many of the reasons why those "people who are sick of programming languages" would like it!
- oddthink 7y ago
  I like the phrase, too. I'm on the "sick of programming languages" side, and I like go, for the things I'm using it for: CLIs, simple debug web-servers, calling out to RPC services. (Read a CSV file, run everything through translate / grammar parsing / etc.) I'm in that age of folks that did pascal in high school, C and Scheme in college, C++ and python in grad school while futzing around with ocaml and common lisp and sather and other fun things. Programming languages are fun. But, oh, I have so much other stuff to pay attention to. I write C++ a few days a week, which is barely enough to keep move semantics in my head. I also write SQL and analysis docs and internal DSLs and configuration files and python. At this point, C++ is barely earning its keep, in terms of mental complexity for reward. Go feels a lot nicer, since I can just get in, do my thing, get out, and it'll at least work and give me a compile error if one of the APIs change when I don't look at it for a year. I'm not about to jump into rust. So, at least for me, go hits a pretty good sweet spot. [Edit: I'm not trying to point fingers at rust in particular. It looks fun. If I weren't still working on getting my hobbyist-Haskell better, I'd probably be playing with it. But that would be at home, for fun, not where I have to have the thing in my head for production issues. It reminds me a bit of the old statement about perl, that it was a fantastic language if you used it every day, but not if you don't. And I don't get to use these things every day any more.]
nl 7y ago
Please give me this nonsense. I'm sick of programming languages.
- 0815test 7y ago
  Protip: You can write FORTRAN in any language!
  - TheRealKing 7y ago
    Of course, you can (re)write code in any Turing-complete language in any other Turing-complete language.

randomvectors 7y ago

No, being opinionated by itself isn't a good enough reason to belong in new code.

neilalexander 7y ago
If you don't believe that making clear promises and delivering on them is, then what would you suggest is a better reason?
- randomvectors 7y ago
  You're arguing with a point that I'm not making at all.
  - neilalexander 7y ago
    What is your point then? You're being obtuse.
- vageli 7y ago
  > If you don't believe that making clear promises and delivering on them is, then what would you suggest is a better reason? How is "being opinionated" and "making clear promises and delivering on them" equivalent?
  - neilalexander 7y ago
    I didn't say they were. They weren't even in the same sentence in my original comment.
- simiones 7y ago
  If the promises you are making are not appealing, even if they are clear and you deliver on them, you can't count that as a reason to use a language in new code.

lmm 7y ago

Go has been carefully designed to solve the problems of today. But relying on solving those problems at the language level means I have very low confidence that the language can adapt to solve the problems of tomorrow. They have built-in language-level support for concurrency, great - that's always going to be slightly more user friendly than a library-based solution. But what about when the next wave comes along? Are they going to be able to rework the whole language to incorporate whatever 2020's equivalent to the concurrency revolution is? While retaining compatibility with existing code? I would not want to use Go for any codebase that's expected to last more than a couple of years. I'd put a lot more faith in languages that were able to adapt elegantly to the challenges of concurrency at the library level, without requiring language changes - that suggests those languages will be able to adapt similarly to the next revolution. And my impression is that languages that started with a solid theoretical underpinning, and/or a small core language with as much as possible pushed out into libraries, handled the transition a lot better than languages with the more ad-hoc, practical-problem-first approach to design that Go has.

dis-sys 7y ago
The codebase of Go itself (which is in Go of course) has been there for multiple "couple of years" already.
apta 7y ago
I'm with you in general that golang code is very unmaintainable in the long term. > Go has been carefully designed to solve the problems of today. I'd even argue it was "carefully designed" to be in the 70's. Other than "goroutines", the language is stuck in that decade. No generics, no expression based syntax, exposing system-dependent "int" type and encouraging its use, badly designed interfaces that can't be used for tagging, badly designed time package, the list is too long to mention here.
- jerf 7y ago
  And yet, people are solving problems in it, often quite well. I say this as one who has basically mastered Haskell, so it's not like I'm not aware of all these things: Fans of all these complicated abstractions really need to take some time and grapple with that fact. It will improve your programming in the more complicated languages as well. No, seriously. Stop for a moment and think about that. Consider the advanced features as a scientific prediction: "If you do not use these features, you can't have a good program come out the other end." This prediction is falsified by the concrete existence of a lot of good Go programs. This matters. It is something that should be grappled with intellectually, if you are a language fan. It will bring you to a deeper understanding of all the fancy features. By a deeper understanding, I mean that quite directly, with no attempt to be subtly saying something like "Oh, you'll find they're all useless in the end." That would not be true. They are not even remotely useless. They are incredibly useful. I would even go so far as to say that the development of these complicated sorts of features is legitimately among some of the most simultaneously interesting and useful intellectual work being done in our time, and greatly contributing to our ability to hold our software world together. It's just that the shape of that usefulness is more complicated than a lot of people realize, and a deeper understanding of that complication is very useful for developers. One of the things that I think really comes out of it is a yet deeper understanding of matching tools to problems. I use a lot of Go, because I write a lot of things that are at a size and complexity where those other language features just aren't that helpful. Yet, there are tasks I could be assigned where I wouldn't dream of using Go, because I know I would need all that fancy stuff to hold the program together. I can easily imagine ways in which my career trajectory would change in the next couple of years and I'd go primarily Rust; I can equally easily imagine ways in which I will stay primarily Go. I can imagine ways in which I'd need to go with some other language. I think a lot of programmers who find these fancy features and fall in love with them end up overestimating the scope of the set of programs where they can be helpful. To give a degenerate example, my six line shell script does not need to be written in the Rust type system. It is not only not helpful, it would be actively harmful. The scope of programs that don't really need those features and where they quite easily become actively harmful is larger than a lot of people think. Especially if you consider them in the context of a heterogeneous team of developers who may not all be in the 5+ years of experience range, or when you may not be able to guarantee that the project is going to stay in those hands.

coldtea 7y ago

>I would argue that Go's opinionated style is what makes it elegant I'd say Go is opinionatedly inelegant. It is minimal, I'll give you that, but has several non-orthogonal design decisions, smells, etc.

tsavola 7y ago
Please elaborate.
- snarfy 7y ago
  This article [1] explains why I'm not a fan. [1] - https://www.teamten.com/lawrence/writings/why-i-dont-like-go.html https://www.teamten.com/lawrence/writings/why-i-dont-like-go...
- dnautics 7y ago
  If err != nil everywhere is definitely a code smell and poor language design.
- coldtea 7y ago
  Not compile-time checked repetitive error handling (if null != err), duality of panic and error codes, specially blessed constructs (maps, slices, etc being "generic"), lack of expressivity, specially typed map libs, interface{} type safety escape hatch, etc...