4 ms·

> Although the design of most languages concentrates on innovations in syntax, semantics, or typing, Go is focused on the software development process itself.

> Although the design of most languages concentrates on innovations in syntax, semantics, or typing, Go is focused on the software development process itself. This important fact is often missed in flame wars. No, Go is not the most expressive, performant, or pure programming language. But it is darn pragmatic and has produced amazing results in just a decade of widespread availability. An example of that pragmatism: > The language provides strings, hash maps, and dynamically sized arrays as built-in, easily used data types. As noted earlier, these are sufficient for most Go programs. The result is greater interoperability between Go programs—for example, there are no competing implementations of strings or hash maps to fragment the package ecosystem. Some language enthusiasts argue that strings shouldn't exist in programming languages, because they don't actually exist -- after all, they are just byte arrays that can be decoded in a variety of ways. But in the real world, "strings" are everywhere (e.g. this comment), and it is a great benefit to having them easily available to the programmer with little to no ambiguity.

Mo3 5y ago
To add to your valid statements, Go has easily outperformed any other language we have compared it to in modern backend development. We are using it for our new API iteration and see consistent performance improvements of over 40-50x the performance of Python and at least 5x that of Node, not to mention the 2x reduced cold start times of cloud functions and much smaller binary sizes. We use it in a hexagonal architecture pattern which it is just perfectly suited for and couldn't be happier. I personally believe it is the best choice these days for business and backend logic. Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good.
- whoevercares 5y ago
  > Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good. With python binding? Or pure Go? It seems impossible for data scientists to all switch to Go
  - Mo3 5y ago
    I don’t expect them to switch at all, quite honestly, Python is still an excellent language and super suitable. I’d just love to see at least mature alternatives be present for the likeminded. I also have a lot of trouble with Pythons inconsistency now after spending all my time in Goworld quite honestly, and seeing how we have managed to move to Go completely yet we still run a queued Python environment exclusively to send data jobs to from the Go environment.. I can’t help but wish for at least mature dataframes
- pphysch 5y ago
  > Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good. I thought that Go might take more territory from Python, especially with generics, but now I'm settling on Python<->gRPC<->Go backends for the foreseeable future. Go will never be as expressive as Python -- for good reasons -- which is important for high-level data science (ORMs, DataFrames, viz, NNs, etc).
  - pjmlp 5y ago
    You mean the domains that make use of Fortran, C++, Chapel, Julia? Yep no place for Go there.
- Phrodo_00 5y ago
  I was expecting a comparison in development effort rather than performance, since that's the strength of Python. System performance is not necessarily a priority of Python, and no one would expect it to be comparable to a language that compiles to machine code without using something like pypy, and even then it'd be likely to lose. If we're comparing it for system performance I'd expect comparisons to other high level compiled languages like Rust, D or C++.
  - Mo3 5y ago
    Even that is highly questionable. Try implementing hexagonal patterns with Python.. the first thing you get to read is about how that is not the pythonistic way. Nothing against Python, it is favorable for beginners and engineers in different fields, but at the point where even Node starts outperforming Python by 10x and you actually want to implement bigger systems you might wish for something different. I don’t see the need to specifically compare Go to either high or low level languages. It sits comfortably right between them and is perfect like that. (This might be an opinionated comment, but I’d love to see anyone try implementing a public API with a dozen of adapters and ports in C++.)
    - pkaye 5y ago
      Never heard of hexagonal patterns (architecture?) but it look like a lot like what my go project architecture at work looks like. Time to learn more about it...
    - pjmlp 5y ago
      Well, that is how we used to do, when servless was known as CGI, Apache modules or ISAPI extensions, or microservices where known as SunRPC, CORBA or DCOM endpoints.
      - Mo3 5y ago
        Point taken, that was before my time. I can't imagine many of these being around any more though
- pjmlp 5y ago
  Go wins in performance against languages whose runtime was never about performance, and are usually interpreted, what a surprise.
  - Mo3 5y ago
    Go's runtime was never specifically about performance either. The runtime scheduler main intentions were - Parallel execution / multiple threads. - Handling of blocking system call and network I/O. - Handling of blocking user level (on channel) calls. - Scalability.
    - pjmlp 5y ago
      You're still comparing apples to oranges, doesn't matter what Go's runtime goals were, when it is AOT compiled and the others aren't.
      - Mo3 5y ago
        I'm not trying to argue with you about that point, of course its AOT compiled.
        pjmlp 5y ago
        Which naturally makes it faster than Python or nodejs, what a wonder!
        Mo3 5y ago
        That was not the point that I am trying to make. Of course it's faster. It's also much closer to Python or nodejs in its use-cases than C++, while still being faster. It's not meant as a replacement for other compiled languages, it is intended for backends.
        gsuphosdown 5y ago
        Yeah Go is basically a scripting language. Most users are coming from Python, Ruby, etc. The original idea that people at Google would migrate to Go from C++ never happened. It’s used as a logs analysis tool that non-CS data scientists can write, with no fancy features at all, to prevent them from crashing batch dataflow pipelines that are running offline, seamlessly scale horizontally, and have no direct production impact if they miss deadlines. The application code for real time serving is all in C++ because Go is too slow and unpredictable at runtime, and the teams are staffed by people with strong software backgrounds. The whole “Go as a systems language” or “Go as a cloud services language” is kind of laughable. It’s like those Tik Toks that say No One: and then it’s Go fans claiming the language has a strong suit other than keeping people who haven’t passed CS 101 from crashing the batch job, productivity speed and control for concurrent real time services be damned.
lifthrasiir 5y ago
Go is a great language and every other language has a thing or two to learn from Go, but this reply sounds like a strawman argument. The article says Go is focused on the software development process, but the means to that goal is mostly nothing to do with the language proper. There are tons of programming languages with strings, hash maps and dynamically sized arrays built-in and the pragmatism doesn't well align with Go team's conservative approach towards new language features (which is great by the way, but shows that Go does not always highly value the pragmatism). The point of Go is being highly opinionated and not being ashamed about that. Many languages start out of necessity with some degrees of opinion, but they are or will be consequently affected by external opinions in order to survive or to accomodate other needs. Many aspects of Go, either the language proper or other "results" that the article wants to pitch, are not and never unique to Go for that reason. But Go is unique in that such opinion is highly guarded and the Go team has more than enough energy to do so thanks to the main supporter, Google.
yakubin 5y ago
(Immutable) strings being built-in is hardly unique. As for hash maps and dynamically sized arrays being built-in, instead of provided by the standard library: there is no benefit adoption-wise. The real reason is that Go didn't use to have generics, so in order to provide generic containers, Go creators bolted selected containers into the language, instead of providing the features facilitating their implementation in the standard library. It actual signals that Go creators reached the limits of practicality of the language and reached for a solution not available to the users of the language (implementing things in the compiler instead). I'm all for large standard libraries. Implementing things in the language instead of stdlib on the other hand usually smells bad.
- rsc 5y ago
  Do types like 'int' and built-in operators like integer division smell bad too?
  - yakubin 5y ago
    Your question sounds provocative, nonetheless I'm going to give an honest answer. First, let me preface that with a disclaimer that those opinions are reserved for general purpose languages. Domain-specific languages should be judged differently. Built-in types like int don't bother me. Built-in string also doesn't bother me, because it is immutable. strings.Builder is part of the standard library on the other hand. I think this division is perfect, because I feel that anything that's denotable as a literal should be built-in. Algorithms on the other hand belong in the library. When it comes to integer division, it's an operation which has a pair of inputs and one output. In other words, it behaves like a function. On the other hand, its most reasonable implementation is a single machine code instruction and compilers usually have a bunch of optimizations for it, which turn it into something else. In other words, I think the best option here is for it to be an intrinsic, a bit similar to how it is in Standard ML[1] or Scheme[2]. The reason for those opinions is that I think implementing things in the compiler instead of the library signal that an instance of a legitimate general problem occurred which lacked a solution in the language, and instead of changing the language to solve the problem for all users, only the specific problem with, in this case, map and dynamic array was solved, and only those specific implementations of those concepts. As you obviously know, Go gained generics, so this is in large part irrelevant now. Also let me state that overall I think Go is a pretty good language. I like it (with generics and without). My comment just comes from the disagreement with the quoted argument. [1]: Tangentially, one thing I don't like in Standard ML is polymorphism of built-in operators. It's another example of a feature which language designers reserved for themselves, and did not give it to users. [2]: I'm basing this on my understanding of the Chez Scheme implementation, which implements the division operator in the library, in Scheme itself, but this implementation relies on an intrinsic. (Assuming it's implemented the same way as other operators I've checked. I haven't checked this one specifically.)

Mo3 5y ago

To add to your valid statements, Go has easily outperformed any other language we have compared it to in modern backend development. We are using it for our new API iteration and see consistent performance improvements of over 40-50x the performance of Python and at least 5x that of Node, not to mention the 2x reduced cold start times of cloud functions and much smaller binary sizes. We use it in a hexagonal architecture pattern which it is just perfectly suited for and couldn't be happier. I personally believe it is the best choice these days for business and backend logic. Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good.

whoevercares 5y ago
> Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good. With python binding? Or pure Go? It seems impossible for data scientists to all switch to Go
- Mo3 5y ago
  I don’t expect them to switch at all, quite honestly, Python is still an excellent language and super suitable. I’d just love to see at least mature alternatives be present for the likeminded. I also have a lot of trouble with Pythons inconsistency now after spending all my time in Goworld quite honestly, and seeing how we have managed to move to Go completely yet we still run a queued Python environment exclusively to send data jobs to from the Go environment.. I can’t help but wish for at least mature dataframes
pphysch 5y ago
> Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good. I thought that Go might take more territory from Python, especially with generics, but now I'm settling on Python<->gRPC<->Go backends for the foreseeable future. Go will never be as expressive as Python -- for good reasons -- which is important for high-level data science (ORMs, DataFrames, viz, NNs, etc).
- pjmlp 5y ago
  You mean the domains that make use of Fortran, C++, Chapel, Julia? Yep no place for Go there.
Phrodo_00 5y ago
I was expecting a comparison in development effort rather than performance, since that's the strength of Python. System performance is not necessarily a priority of Python, and no one would expect it to be comparable to a language that compiles to machine code without using something like pypy, and even then it'd be likely to lose. If we're comparing it for system performance I'd expect comparisons to other high level compiled languages like Rust, D or C++.
- Mo3 5y ago
  Even that is highly questionable. Try implementing hexagonal patterns with Python.. the first thing you get to read is about how that is not the pythonistic way. Nothing against Python, it is favorable for beginners and engineers in different fields, but at the point where even Node starts outperforming Python by 10x and you actually want to implement bigger systems you might wish for something different. I don’t see the need to specifically compare Go to either high or low level languages. It sits comfortably right between them and is perfect like that. (This might be an opinionated comment, but I’d love to see anyone try implementing a public API with a dozen of adapters and ports in C++.)
  - pkaye 5y ago
    Never heard of hexagonal patterns (architecture?) but it look like a lot like what my go project architecture at work looks like. Time to learn more about it...
  - pjmlp 5y ago
    Well, that is how we used to do, when servless was known as CGI, Apache modules or ISAPI extensions, or microservices where known as SunRPC, CORBA or DCOM endpoints.
    - Mo3 5y ago
      Point taken, that was before my time. I can't imagine many of these being around any more though
pjmlp 5y ago
Go wins in performance against languages whose runtime was never about performance, and are usually interpreted, what a surprise.
- Mo3 5y ago
  Go's runtime was never specifically about performance either. The runtime scheduler main intentions were - Parallel execution / multiple threads. - Handling of blocking system call and network I/O. - Handling of blocking user level (on channel) calls. - Scalability.
  - pjmlp 5y ago
    You're still comparing apples to oranges, doesn't matter what Go's runtime goals were, when it is AOT compiled and the others aren't.
    - Mo3 5y ago
      I'm not trying to argue with you about that point, of course its AOT compiled.
      - pjmlp 5y ago
        Which naturally makes it faster than Python or nodejs, what a wonder!
        Mo3 5y ago
        That was not the point that I am trying to make. Of course it's faster. It's also much closer to Python or nodejs in its use-cases than C++, while still being faster. It's not meant as a replacement for other compiled languages, it is intended for backends.
        gsuphosdown 5y ago
        Yeah Go is basically a scripting language. Most users are coming from Python, Ruby, etc. The original idea that people at Google would migrate to Go from C++ never happened. It’s used as a logs analysis tool that non-CS data scientists can write, with no fancy features at all, to prevent them from crashing batch dataflow pipelines that are running offline, seamlessly scale horizontally, and have no direct production impact if they miss deadlines. The application code for real time serving is all in C++ because Go is too slow and unpredictable at runtime, and the teams are staffed by people with strong software backgrounds. The whole “Go as a systems language” or “Go as a cloud services language” is kind of laughable. It’s like those Tik Toks that say No One: and then it’s Go fans claiming the language has a strong suit other than keeping people who haven’t passed CS 101 from crashing the batch job, productivity speed and control for concurrent real time services be damned.

lifthrasiir 5y ago

Go is a great language and every other language has a thing or two to learn from Go, but this reply sounds like a strawman argument. The article says Go is focused on the software development process, but the means to that goal is mostly nothing to do with the language proper. There are tons of programming languages with strings, hash maps and dynamically sized arrays built-in and the pragmatism doesn't well align with Go team's conservative approach towards new language features (which is great by the way, but shows that Go does not always highly value the pragmatism). The point of Go is being highly opinionated and not being ashamed about that. Many languages start out of necessity with some degrees of opinion, but they are or will be consequently affected by external opinions in order to survive or to accomodate other needs. Many aspects of Go, either the language proper or other "results" that the article wants to pitch, are not and never unique to Go for that reason. But Go is unique in that such opinion is highly guarded and the Go team has more than enough energy to do so thanks to the main supporter, Google.

yakubin 5y ago

(Immutable) strings being built-in is hardly unique. As for hash maps and dynamically sized arrays being built-in, instead of provided by the standard library: there is no benefit adoption-wise. The real reason is that Go didn't use to have generics, so in order to provide generic containers, Go creators bolted selected containers into the language, instead of providing the features facilitating their implementation in the standard library. It actual signals that Go creators reached the limits of practicality of the language and reached for a solution not available to the users of the language (implementing things in the compiler instead). I'm all for large standard libraries. Implementing things in the language instead of stdlib on the other hand usually smells bad.

rsc 5y ago
Do types like 'int' and built-in operators like integer division smell bad too?
- yakubin 5y ago
  Your question sounds provocative, nonetheless I'm going to give an honest answer. First, let me preface that with a disclaimer that those opinions are reserved for general purpose languages. Domain-specific languages should be judged differently. Built-in types like int don't bother me. Built-in string also doesn't bother me, because it is immutable. strings.Builder is part of the standard library on the other hand. I think this division is perfect, because I feel that anything that's denotable as a literal should be built-in. Algorithms on the other hand belong in the library. When it comes to integer division, it's an operation which has a pair of inputs and one output. In other words, it behaves like a function. On the other hand, its most reasonable implementation is a single machine code instruction and compilers usually have a bunch of optimizations for it, which turn it into something else. In other words, I think the best option here is for it to be an intrinsic, a bit similar to how it is in Standard ML[1] or Scheme[2]. The reason for those opinions is that I think implementing things in the compiler instead of the library signal that an instance of a legitimate general problem occurred which lacked a solution in the language, and instead of changing the language to solve the problem for all users, only the specific problem with, in this case, map and dynamic array was solved, and only those specific implementations of those concepts. As you obviously know, Go gained generics, so this is in large part irrelevant now. Also let me state that overall I think Go is a pretty good language. I like it (with generics and without). My comment just comes from the disagreement with the quoted argument. [1]: Tangentially, one thing I don't like in Standard ML is polymorphism of built-in operators. It's another example of a feature which language designers reserved for themselves, and did not give it to users. [2]: I'm basing this on my understanding of the Chez Scheme implementation, which implements the division operator in the library, in Scheme itself, but this implementation relies on an intrinsic. (Assuming it's implemented the same way as other operators I've checked. I haven't checked this one specifically.)