6 ms·

Its a great programming language that is helpful to solve problems without wasting time. I really appreciate the simplicity, I think it totally makes sense at

Its a great programming language that is helpful to solve problems without wasting time. I really appreciate the simplicity, I think it totally makes sense at work where not everyone wants to deal with weird code. I think maintaining old golang code will not be a major problem in the future for example. The garbage collector make things a lot simpler too. The dependencies management is not great compared to npm/crates/rubygems/... but it's still better than the Java world and it exists and it's being used. I wish generics were already there, and I'm not a fan of the interface{} keyword. I'm also sick of the if err!=nil everywhere, I wish it could have a better error management like Haskell/Elm/Rust/... I use Rust in my latest personal projet and while I prefer Rust, it's a bit too complex quite often and I spend more time thinking about rust things than thinking about the problem I'm solving. This is not the case with Golang. It's not a fun programming language but it does most jobs very well.

ncmncm 6y ago
Go is carefully designed to be adequate for the large majority of problems that don't need much, meant for use by the large majority of programmers who don't know or need much, whose attention is elsewhere. It is hard to get too deep into the weeds by accident. It builds fast, so programmers who code by successive approximation, making more or less random changes until something works can get there quickly. It runs pretty fast, so programs usually don't need much optimization attention. It competes in the same niche as Java, but lacks Java's complications that, more often than not, are purely obstacles. Before Go, before Java, there was Visual Basic. Visual Basic coders didn't go anywhere. Go acknowledges and welcomes them.
- apta 6y ago
  golang is anemic in front of Java (the JVM, the language, and the ecosystem) and introduces its own set of gotchas. Once Java gets green threads (by means of Project Loom), golang will be an extremely difficult sell for anyone considering a new project.
  - pjmlp 6y ago
    Until Docker, Kubernetes and its ill fades into obscurity, even us on Java and .NET platforms now need to keep a passing knowledge of Go for tooling related on the eco-system.
    - apta 6y ago
      Sure, but I was referring about the state and design of the language in general, and its viability for new projects.
  - ncmncm 6y ago
    Java's place in data processing is as secure as COBOL's. Go's is not. But, as with COBOL, it is not because Java is good, or getting better. It is because--like COBOL, FORTRAN, C, C++, Javascript and Python, and unlike Pascal, Ada, PL/I and myriad others--Java got a miracle. Absent a miracle, languages fade away.
    - apta 6y ago
      Java is getting better. It's getting records, value types, and green threads, and pattern matching, and more.
      - ncmncm 6y ago
        Doesn't matter, just as it doesn't matter if it is good. Its secure place in the programming landscape does not depend on its improvements, or even on whether they really are improvements.
- pjmlp 6y ago
  Yes, what Go failed to acknowledge was how those decisions impacted Java and Visual Basic language evolution and actually learn from them.
  - ncmncm 6y ago
    Go's designers have very different goals from others. They did not set out to design a language they would, themselves, like to program in. They meant to make a language that very distracted programmers would still be able to get things done using, and other distracted programmers could read and maintain. Java also was not a language its designers wanted to use. They would rather code Lisp.
    - pjmlp 6y ago
      Still no excuse no to learn from the mistakes of others, Go has already so much "we don't do that here,...., ok we really should support that" that will eventually be just yet another Java, but hey it has cool designers.
      - ncmncm 6y ago
        If Go survives, it will end up as complicated as other languages. Rust, too, if it survives. You have to be arrogant to design a language and expect it to go anywhere, so you also tend to think you know better than everybody else, and that nobody has anything to teach you. It's an occupational hazard. Designing a language you don't mean to use yourself manufactures special failings. Rust's designers started with unusual humility, and have kept it. It saved them from many mistakes.
        efnx 6y ago
        People who enjoy Go will probably tell you that Rust is already one of those complicated languages. Personally I don’t agree, I think Rust is right in the middle, but that’s because to the left of Rust is Idris, Agda, Coq, Ada and Prolog. Most SEs don’t have those on their radar.
- heresie-dabord 6y ago
  Go has found a space in networking. What Java and Python offer is a single language with networking (sockets), familiar and/or easy syntax, portability, and GUI capability. Visual Basic was not in the same league (failed portability), but it too had these features.
- vram22 6y ago
  > so programmers who code by successive approximation, ... > making more or less random changes until something works can get there quickly. ??? First clause doesn't logically match second.
  - ncmncm 6y ago
    Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. A linear search is generally more efficient than a random walk, but depends on an accurate assessment of the direction and magnitude of each step. A binary search also depends on a global ordering criterion. All that would too much to ask of many users of Go.
    - vram22 6y ago
      >Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. Your first sentence (quoted above) is right. But IMO, the two sentences quoted above, together, are not right. Because, even if not optimal, successive approximation means getting closer at each step, which is unlikely or impossible with a random walk.
      - ncmncm 6y ago
        With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. You may laugh, but more code is written this way than not.
        vram22 6y ago
        >With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. Still think the logic is wrong or at least farfetched, but not going to argue it more. >You may laugh, but more code is written this way than not. I know that quite well, having been a dev for many years and a manager for some, so seen things from both "sides". In fact I can say I've seen it from a third and maybe even a fourth side (perspective, really), ha ha, since I've been an independent consultant and trainer for a while now.
- intricatedetail 6y ago
  This is on point. I would add that successive approximation here is quicker than finding solution on SO.

ncmncm 6y ago

Go is carefully designed to be adequate for the large majority of problems that don't need much, meant for use by the large majority of programmers who don't know or need much, whose attention is elsewhere. It is hard to get too deep into the weeds by accident. It builds fast, so programmers who code by successive approximation, making more or less random changes until something works can get there quickly. It runs pretty fast, so programs usually don't need much optimization attention. It competes in the same niche as Java, but lacks Java's complications that, more often than not, are purely obstacles. Before Go, before Java, there was Visual Basic. Visual Basic coders didn't go anywhere. Go acknowledges and welcomes them.

apta 6y ago
golang is anemic in front of Java (the JVM, the language, and the ecosystem) and introduces its own set of gotchas. Once Java gets green threads (by means of Project Loom), golang will be an extremely difficult sell for anyone considering a new project.
- pjmlp 6y ago
  Until Docker, Kubernetes and its ill fades into obscurity, even us on Java and .NET platforms now need to keep a passing knowledge of Go for tooling related on the eco-system.
  - apta 6y ago
    Sure, but I was referring about the state and design of the language in general, and its viability for new projects.
- ncmncm 6y ago
  Java's place in data processing is as secure as COBOL's. Go's is not. But, as with COBOL, it is not because Java is good, or getting better. It is because--like COBOL, FORTRAN, C, C++, Javascript and Python, and unlike Pascal, Ada, PL/I and myriad others--Java got a miracle. Absent a miracle, languages fade away.
  - apta 6y ago
    Java is getting better. It's getting records, value types, and green threads, and pattern matching, and more.
    - ncmncm 6y ago
      Doesn't matter, just as it doesn't matter if it is good. Its secure place in the programming landscape does not depend on its improvements, or even on whether they really are improvements.
pjmlp 6y ago
Yes, what Go failed to acknowledge was how those decisions impacted Java and Visual Basic language evolution and actually learn from them.
- ncmncm 6y ago
  Go's designers have very different goals from others. They did not set out to design a language they would, themselves, like to program in. They meant to make a language that very distracted programmers would still be able to get things done using, and other distracted programmers could read and maintain. Java also was not a language its designers wanted to use. They would rather code Lisp.
  - pjmlp 6y ago
    Still no excuse no to learn from the mistakes of others, Go has already so much "we don't do that here,...., ok we really should support that" that will eventually be just yet another Java, but hey it has cool designers.
    - ncmncm 6y ago
      If Go survives, it will end up as complicated as other languages. Rust, too, if it survives. You have to be arrogant to design a language and expect it to go anywhere, so you also tend to think you know better than everybody else, and that nobody has anything to teach you. It's an occupational hazard. Designing a language you don't mean to use yourself manufactures special failings. Rust's designers started with unusual humility, and have kept it. It saved them from many mistakes.
      - efnx 6y ago
        People who enjoy Go will probably tell you that Rust is already one of those complicated languages. Personally I don’t agree, I think Rust is right in the middle, but that’s because to the left of Rust is Idris, Agda, Coq, Ada and Prolog. Most SEs don’t have those on their radar.
heresie-dabord 6y ago
Go has found a space in networking. What Java and Python offer is a single language with networking (sockets), familiar and/or easy syntax, portability, and GUI capability. Visual Basic was not in the same league (failed portability), but it too had these features.
vram22 6y ago
> so programmers who code by successive approximation, ... > making more or less random changes until something works can get there quickly. ??? First clause doesn't logically match second.
- ncmncm 6y ago
  Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. A linear search is generally more efficient than a random walk, but depends on an accurate assessment of the direction and magnitude of each step. A binary search also depends on a global ordering criterion. All that would too much to ask of many users of Go.
  - vram22 6y ago
    >Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. Your first sentence (quoted above) is right. But IMO, the two sentences quoted above, together, are not right. Because, even if not optimal, successive approximation means getting closer at each step, which is unlikely or impossible with a random walk.
    - ncmncm 6y ago
      With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. You may laugh, but more code is written this way than not.
      - vram22 6y ago
        >With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one. Still think the logic is wrong or at least farfetched, but not going to argue it more. >You may laugh, but more code is written this way than not. I know that quite well, having been a dev for many years and a manager for some, so seen things from both "sides". In fact I can say I've seen it from a third and maybe even a fourth side (perspective, really), ha ha, since I've been an independent consultant and trainer for a while now.
intricatedetail 6y ago
This is on point. I would add that successive approximation here is quicker than finding solution on SO.