4 ms·

Go is such a productive language. Well deserved cred to its authors and community. Please, please hold firm against the inherent pressure from language theoreti

by jahaja 7y ago

Go is such a productive language. Well deserved cred to its authors and community. Please, please hold firm against the inherent pressure from language theoreticians to add more features that increases complexity.

jeffdavis 7y ago
I think the tension is more between people writing executables and people writing libraries. If you want your language to be suitable for any purpose by using an intricate web of libraries depending on each other, you need those language features and deep theory. Think haskell, lisp, rust, etc. If you kind of know what people will use your language for, and you build in the most important functionality, you aren't nearly so dependent on libraries. You just make the language accessible and as productive as possible. Think Go, erlang, PHP, SQL, javascript, VB.
- gameswithgo 7y ago
  well said!
- jahaja 7y ago
  I honestly think that any language that enables too much cleverness will inevitably produce a mess given enough developers involved.
- icholy 7y ago
  Yet the Go standard library is one of the best around ...
  - jeffdavis 7y ago
    It seems that you are agreeing with me. A standard library for a language with a purpose (like Go) should include a lot of stuff related to that purpose. That avoids the need for an intricate web of dependencies and specialized third-oarty code, but ties the language to its purpose a bit more. A standard library for a use-for-anything-and-everything language (like rust) might be smaller because it relies more on third-party libraries for the specific purposes you have in mind.
- baby 7y ago
  I think you're on point, writing system stuff in Golang can be a bit of a pain due to the lack of expressiveness, but writing anything else is a freaking joy. Reading Golang on the other hand is always pure joy.
- nitwit005 7y ago
  I tend to think libraries work fine with Go. It's "frameworks" that are difficult.
- einpoklum 7y ago
  Any general-purpose programming language that wants to be more than a toy needs an "intricate web of libraries". The alternative are domain-specific languages - like SQL for example - which people simply do not and will not try to use in arbitrary new settings.
srparish 7y ago
By productive you mean having developers repeatedly manually create loops that are the poor and verbose equivalents of map(), filter(), and reduce()? Out of go, scala, c++, java, python, typescript; go is the least productive language I've used in the last decade.
- jahaja 7y ago
  100% Yes.
- nemo1618 7y ago
  I tried my hand at writing generic map/filter/reduce once, and it turned out to be more nuanced than I thought. Do you want to modify the array in-place, or return new memory? If your reduce operation is associative, do you want to do it parallel, and if so, with what granularity? If you're setting up a map->filter->reduce pipeline on a single array, the compiler needs to use some kind of stream fusion to avoid unnecessary allocations; how can the programmer be sure that it was optimized correctly? And so on. If you want to write code that's "closer to the metal," these things become increasingly important, and it's probably impossible to create a generic API that satisfies everyone. That said, I wouldn't mind having a stdlib package with map/filter/reduce implementations that are "good enough" for non-performance-critical code.
  - apta 7y ago
    > I tried my hand at writing generic map/filter/reduce once, and it turned out to be more nuanced than I thought. Rust and Java both have good APIs for this kind of work. Take a look at their approaches.
    - nitwit005 7y ago
      A lot of the clever helpers like that in Java unfortunately often trigger extra allocations, making them slower, as the above post implied.
      - cle 7y ago
tsimionescu 7y ago
It's not (just) about language theoreticians pushing their favorite features. It's mostly about regular programmers who have seen other languages and don't want to write the 30th new slice copy function, or the 10th get-slice-of-keys-from-map function. They might also not want to keep reading `if err != nil {return err}` over and over between pieces of logic in a function.
- deleted 7y ago
  [deleted]
- hu3 7y ago
  I'm a regular programmer who has seen other languages and don't mind writing the 30th new slice copy function, or the 10th get-slice-of-keys-from-map function. And I like `if err != nil {return err}` for its sheer simplicity. There's value in doing things in the most boring obvious verbose way. Quick onboarding is one, from experience. Homogeneous codebase is another. Having less ways to do the same thing. And so on. Go isn't the type of language for ego massaging. It's meant to be a productive language for large projects while adding resiliency to teams against dev churn.
earthboundkid 7y ago
I find it telling that the criticisms on this article are the exact same ones on articles about Go being released ten years ago. It's like spending a decade yelling at a bee to tell it that it's not aerodynamic enough to fly.

by jahaja 7y ago

jeffdavis 7y ago

I think the tension is more between people writing executables and people writing libraries. If you want your language to be suitable for any purpose by using an intricate web of libraries depending on each other, you need those language features and deep theory. Think haskell, lisp, rust, etc. If you kind of know what people will use your language for, and you build in the most important functionality, you aren't nearly so dependent on libraries. You just make the language accessible and as productive as possible. Think Go, erlang, PHP, SQL, javascript, VB.

gameswithgo 7y ago
well said!
jahaja 7y ago
I honestly think that any language that enables too much cleverness will inevitably produce a mess given enough developers involved.
icholy 7y ago
Yet the Go standard library is one of the best around ...
- jeffdavis 7y ago
  It seems that you are agreeing with me. A standard library for a language with a purpose (like Go) should include a lot of stuff related to that purpose. That avoids the need for an intricate web of dependencies and specialized third-oarty code, but ties the language to its purpose a bit more. A standard library for a use-for-anything-and-everything language (like rust) might be smaller because it relies more on third-party libraries for the specific purposes you have in mind.
baby 7y ago
I think you're on point, writing system stuff in Golang can be a bit of a pain due to the lack of expressiveness, but writing anything else is a freaking joy. Reading Golang on the other hand is always pure joy.
nitwit005 7y ago
I tend to think libraries work fine with Go. It's "frameworks" that are difficult.
einpoklum 7y ago
Any general-purpose programming language that wants to be more than a toy needs an "intricate web of libraries". The alternative are domain-specific languages - like SQL for example - which people simply do not and will not try to use in arbitrary new settings.

srparish 7y ago

By productive you mean having developers repeatedly manually create loops that are the poor and verbose equivalents of map(), filter(), and reduce()? Out of go, scala, c++, java, python, typescript; go is the least productive language I've used in the last decade.

jahaja 7y ago
100% Yes.
nemo1618 7y ago
I tried my hand at writing generic map/filter/reduce once, and it turned out to be more nuanced than I thought. Do you want to modify the array in-place, or return new memory? If your reduce operation is associative, do you want to do it parallel, and if so, with what granularity? If you're setting up a map->filter->reduce pipeline on a single array, the compiler needs to use some kind of stream fusion to avoid unnecessary allocations; how can the programmer be sure that it was optimized correctly? And so on. If you want to write code that's "closer to the metal," these things become increasingly important, and it's probably impossible to create a generic API that satisfies everyone. That said, I wouldn't mind having a stdlib package with map/filter/reduce implementations that are "good enough" for non-performance-critical code.
- apta 7y ago
  > I tried my hand at writing generic map/filter/reduce once, and it turned out to be more nuanced than I thought. Rust and Java both have good APIs for this kind of work. Take a look at their approaches.
  - nitwit005 7y ago
    A lot of the clever helpers like that in Java unfortunately often trigger extra allocations, making them slower, as the above post implied.
    - cle 7y ago

tsimionescu 7y ago

It's not (just) about language theoreticians pushing their favorite features. It's mostly about regular programmers who have seen other languages and don't want to write the 30th new slice copy function, or the 10th get-slice-of-keys-from-map function. They might also not want to keep reading `if err != nil {return err}` over and over between pieces of logic in a function.

deleted 7y ago
[deleted]
hu3 7y ago
I'm a regular programmer who has seen other languages and don't mind writing the 30th new slice copy function, or the 10th get-slice-of-keys-from-map function. And I like `if err != nil {return err}` for its sheer simplicity. There's value in doing things in the most boring obvious verbose way. Quick onboarding is one, from experience. Homogeneous codebase is another. Having less ways to do the same thing. And so on. Go isn't the type of language for ego massaging. It's meant to be a productive language for large projects while adding resiliency to teams against dev churn.

earthboundkid 7y ago

I find it telling that the criticisms on this article are the exact same ones on articles about Go being released ten years ago. It's like spending a decade yelling at a bee to tell it that it's not aerodynamic enough to fly.