17 ms·

Opinions on programming languages are like arseholes in that everyone has one. So I'm far less interested in hearing people intellectualise over what they perce

Opinions on programming languages are like arseholes in that everyone has one. So I'm far less interested in hearing people intellectualise over what they perceive to be good or bad qualities of a particular language (otherwise known as arguing personal opinion as irrefutable fact) and far more interested in seeing what what cool projects people can make. After all, many of us managed to write some pretty awesome stuff in BASIC back in the 70s and 80s so there's really no excuse these days given the tooling and hardware we now have available.

Cyph0n 9y ago
So the fact that Go provides no solid dependency management solution is "personal opinion"? If everyone followed this approach, we would never have ended up with amazing languages like Rust. Why try to improve C++ if you can build cool stuff with it, right?
- czbond 9y ago
  What do you mean by "no solid dependency management"? Do you mean out of the box? This used to be true, but with glide and dep (https://github.com/golang/dep https://github.com/golang/dep) it seems to. It is not npm or bundler - but progressing.
  - chisleu 9y ago
    Yes, go decided to wait to let the various competing systems duke it out in much the same way that node.js left it out for a while. I use git as my dependency management. I pull a specific version of a golang dependency and put it into my private git repository. Then i don't have to worry about someone's github getting hacked, repositories getting deleted, etc... Those problems have all happened with npm and github in the node ecosystem. Go solves these problems by allowing you to decide on how to manage your dependencies.
    - iends 9y ago
      This is no longer true. The core team proposed vgo a few weeks ago, after the majority of the community solidified around godep.
    - Keats 9y ago
      Do you also fork all their dependencies and subdependencies and fix the path in all of them? Otherwise you are still at the mercy of account/repo renames or deletions
  - andreygrehov 9y ago
    They are going to be deprecated. See https://research.swtch.com/vgo https://research.swtch.com/vgo
    - jerf 9y ago
      But in a nominally reverse compatible way, and nobody can really force you to stop using dep if that's what you do.
  - kbenson 9y ago
    > It is not npm or bundler - but progressing. I assume NPM has gotten a lot better in the last few years if it's being used as example of something to strive towards. Every time I have to mess with the Node ecosystem, it really makes me question the direction I'm heading with the research or project I'm working on, just by the haphazard way modules seem to be used and dealt with on both the dependency level and at the repository/packager level. The last time was a couple months back with Reasonml. Reason seemed (and still seems) really cool, but ultimately I wasn't willing to put up with the umpteen layers of indirection just to compile to JS.[1] 1: I know there's an Ocaml compiler as well, but it didn't easily support some of the use cases I was looking at.
    - bbatha 9y ago
      > I assume NPM has gotten a lot better in the last few years if it's being used as example of something to strive towards. Make sure that you are evaluating the tool not how the community uses the tool or npmjs.com runs the registry.
      - tonyarkles 9y ago
        They're pretty inseparable. If npm is great, and the community and default registry are terrible, I'm still not going to want to use the tool if I don't absolutely have to.
  - Cyph0n 9y ago
    I was using one of the points raised in the linked article to refute OP's point about "personal opinions" in the context of critiquing programming languages in general.
    - czbond 9y ago
      You did. My mistake, I guess the point you were making didn't register.
- dcu 9y ago
  I've been using `glide` for a few years now, no issues at all. It's the same as cargo(rust), bundler(ruby), npm(js). Thanks to Go it's probably better since deploying dependencies in those languages is really painful. And not mentioning the security issues associated with having a central repository for packages.
  - reificator 9y ago
    > It's the same as cargo(rust) > deploying dependencies in those languages is really painful. Can you please elaborate here? What's painful about Rust dependencies?
  - sakuronto 9y ago
    Ruby and Rust both let you have your own repository for packages, so that doesn't make much sense, and AFAICT Rust literally needs two lines of code to pull in a new package, so I can't exactly agree that it's painful. I don't know much about Glide but if it uses Git for packages then that's pretty much centralized thanks to GitHub, too. At least the properly centralized solutions help assure you that, unless you're running a server yourself, the package is guaranteed to exist online, and even the developer can't remove it. On GitHub there's far too many things that could go wrong, and I have much less confidence that repos will continue to exist.
- mswift42 9y ago
  > If everyone followed this approach, we would never have ended up with amazing languages like Rust. What approach would that be? > Why try to improve C++ if you can build cool stuff with it, right? Go improves on C++ in at least one regard, compile time. And there they succeeded spectacularly. While I like Rust, imagine how great it would be with Go's compile speed..
  - Cyph0n 9y ago
    > What approach would that be? Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. > Go improves on C++ in at least one regard Go is a GCed language, so you can't really compare it to C++.
    - mswift42 9y ago
      > Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. > Go is a GCed language, so you can't really compare it to C++. That's a very strange thing to say.
      - Cyph0n 9y ago
        > GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. And I don't, so let's just agree to disagree on that. > That's a very strange thing to say. Does this (or any other) advantage of Go help people who are writing software that cannot have a GC in the loop? No, it does not, so it's really not a valid comparison imo. Could Rust and C++ have better compile times? Maybe. I'll defer judgement to the actual compiler experts though.
        mswift42 9y ago
        it is my understanding that the bad C++ compilation speed is one of the reasons behind Go's inception. Go has a GC because its creators thought they needed one to support concurrency.
- laumars 9y ago
  > So the fact that Go provides no solid dependency management solution is "personal opinion"? The fact this is argued as a bad thing is personal opinion. He might have a valid point on that specific arguement but it's still an opinion piece as there have been others who have voiced how they like vendoring in Go. > If everyone followed this approach, we would never have ended up with amazing languages like Rust. Why try to improve C++ if you can build cool stuff with it, right? The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. I see language bashing really as more of a tribal ritrial rather than a productive contribution. Like the KDE Vs GNOME wars or the vi Vs emacs debates before that. For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars.
  - Cyph0n 9y ago
    > The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. So how do you think new language development starts? Why do we have languages like Rust, D, Nim, and Crystal?
    - laumars 9y ago
      > So how do you think new language development starts? By people writing code rather than pontificating > Why do we have languages like Rust, D, Nim, and Crystal? Because people wrote them rather than wasted hours on end arging why other popular solutions are garbage. As I said in my previous post: "For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars." Or to put things another way, you don't see the developer of Nim endlessly slagging off other languages. He just quietly gets on and creates something awesome.
      - wuliwong 9y ago
        >By people writing code rather than pontificating Or maybe a both things are important?
- strkek 9y ago
  Well, one thing that Cargo got wrong is forcing you to clone a full git repository when only the latest commit is relevant. IMHO it should allow me to either use a shallow clone or use crates.io's API directly.
  - tomjakubowski 9y ago
    There's a Cargo bug tracking this. https://github.com/rust-lang/cargo/issues/1171 https://github.com/rust-lang/cargo/issues/1171
  - __sr__ 9y ago
    It’s not a design flaw that can’t be fixed down the line with coming up with a backwards incompatible v2.0 of the langauage.
- AnIdiotOnTheNet 9y ago
  I might argue that it's a bad thing, because it encourages dependency bloat if nothing else.
- saturn_vk 9y ago
  There are at least two solid, though not as mature as maven, dependency managers for go, so it seems even yours is a personal opinion.
- endorphone 9y ago
  Some of us have some fatigue about this topic as it has been retrodden literally hundreds of times on here, an army of people stomping their feet and screaming "OMG WHY ARE PEOPLE STILL USING GO!?" If everyone followed this approach, we would never have ended up with amazing languages like Rust. This comment reminds me of the top comment in a prior anti-Go spiel (which of course did well on here). https://news.ycombinator.com/item?id=7660924 https://news.ycombinator.com/item?id=7660924 Is it interesting how little of consequence is written in Rust, or in that example Haskell, and how much is written in Go, C, and even derelict dregs like PHP. The formal perfection of a language does seem to have a great deviance from the likelihood that it serves as a basis for important work.
  - weberc2 9y ago
    > Is it interesting how little of consequence is written in Rust, or in that example Haskell, and how much is written in Go, C, and even derelict dregs like PHP. Exactly this. It always amazes me when people respond with "You can't judge a language by the things that are built with it because you can build anything in any Turing complete language". They're pretty much arguing that haskell/rust etc are better than go because all languages are equal.
  - __sr__ 9y ago
    > Is it interesting how little of consequence is written in Rust, or in that example Haskell, and how much is written in Go, C, and even derelict dregs like PHP. The formal perfection of a language does seem to have a great deviance from the likelihood that it serves as a basis for important work. That is pretty simple to explain. Well designed languages have a learning curve. They require an initial investment in terms of learning — something that a lot of self styled hackers are not willing to put in. I am sure a ton of stuff is written as shell scripts. And there is also the matter of how long the language has existed.
  - Cyph0n 9y ago
    I agree with your point, but I'm not sure how it ties in to the comment I was replying to. Edit: You seem to be overlooking the less tangible contributions languages like Rust or Haskell have made to PLs in general. One example that comes to mind is how Scala has affected the development of Java, even though, in the real world, Scala use is relatively non-existent.
SomeHacker44 9y ago
I am not interested in what people CAN make in a language. Anything that can be made can be hypothetically made in any (Turing-complete) language. That is an, IMO, silly criteria. People made awesome things (for the time) flipping switches and entering opcodes directly at one point. I am interested in a language that makes things easy, clear and elegant. I agree with the original article in that I do not find Go to be any of these for many things I would use it for. Hence, I do not use it. I think the author’s comment that Go ignored a lot of modern programming language theory especially hits it on the head for me.
- laumars 9y ago
  > I am interested in a language that makes things easy, clear and elegant. Isn't the easiest way to establish that by writing code yourself rather than reading an opinion piece written by someone else who likely has a different coding style to yourself?
  - SomeHacker44 9y ago
    Been there, done that. We built a heavily asynchronous back-end communications service in Go a year or two ago. It was a great learning experience. I learned that I don't like Go and its limitations and design choices first hand, wrote a bunch of notes about what I did and didn't like (mostly didn't like), and moved on. We had chosen Go to use for the reasons others here have commented about (especially the part about enabling relatively inexperienced software engineers to be productive quickly), but in the end I felt it sacrificed too much on that altar and I would rather spend more time mentoring and training our software engineers to use tools I felt were better. It's mostly a matter of opinion, like I said - with sufficient dedication you can pretty much do anything with any language. But I'm not investing any more time into Go when I have other tools out there (like Clojure, Rust, Haskell, Common Lisp, C#, various BEAM languages, Ruby/Python, etc.) that I find to be uniformly more pleasant to use.
    - lilbobbytables 9y ago
      Curious what you preferred over Go for the task mentioned.
JetSetWilly 9y ago
If you don't like articles on this topic, then don't read them. Why bother to tell us all about how you don't like this kind of article and you would much rather read about X instead? Plenty of people do, so leave them in peace to get on with it.
ebiester 9y ago
I try to read one of these on the major paths I'm not on. It's answering the question, "should I build my next project in what I know, or checking something new out?" Seeing these for Go, Rust, Elixir, Elm, and others let me narrow it down before spending the 4-8 hours to figure out if it works for my brain and use case. (For example, seeing this tells me that Go is bad for the things I want to build because my brain works in types and good error checking.) I'd prefer more of these, frankly.
rwj 9y ago
Why would a professional evaluate their tools?
coldtea 9y ago
>So I'm far less interested in hearing people intellectualise over what they perceive to be good or bad qualities of a particular language (otherwise known as arguing personal opinion as irrefutable fact) and far more interested in seeing what what cool projects people can make. People can (and have for decades) MCGyvered "cool projects" with all kinds of primitive and shitty languages and tools. Progress doesn't come from projects, it comes from better tools. As a caveman, you could build all kinds of heating projects, but you wouldn't get far if your only invention is the fire...
- brandur 9y ago
  Spot on. Some programming languages can be, and are, better than other programming languages. They've all been evolving along a single historical timeline, and many mistakes were made in the past that we acknowledge and wouldn't make again. To take a well-known example: eminently abusable Turing complete templates in C++ versus the more modern generics as seen in C#, Java, Rust, etc. We should all have a shared goal of building of tooling that maximizes our leverage by providing powerful primitives, and minimizes the number of mistakes we make by providing dependable safety rails. Some more recent programming languages are really doing an exceptional job of this. This critique of Go quite correct. It's a pretty good language with a lot of pretty good ideas, but it's also not without a healthy dose of very sizable flaws as well (which the author has enumerated nicely), and they're made more concerning because most of the Go team refuses to acknowledge many of them. Without even going near the third rails of package management or generics, other niceties like real enums, ways to build typed non-slice non-map data structures, safety measures to protect against Goroutine leaks, or explicit interfaces would all be big improvements. I personally find that once it comes to large projects, Go feels obviously less brittle than Ruby/Python/JS, but much closer to their end of the spectrum compared to languages that offer stronger guarantees (e.g. Rust, Haskell, but also even languages like C#). I don't think that's what its creators were going for.
  - edflsafoiewq 9y ago
    Interesting example of PL progress. I would have said that free-style templates were part of the "C++ way", in fact fairly close to its essence. One feature which seems to lie along the axis of forward progress is lambdas (even Java got them) and one that appears to lie in its past is unstructured control flow (IMO this is somewhat regrettable). One thing I wish languages would all evolve is an expression-language syntax but there was and is a surprising amount of kvetching about Rust's "implicit returns" so perhaps I'll be waiting a while longer for that. OTOH, the idea of forward evolution is also deceptive. The imperative world had tagged unions many decades ago, but they were abandoned in the OOP craze in favor of forms of subtyping (the Modula-3 designers at least gave this justification as a form of pure progress) and it's only fairly recently that they have percolated back over from the functional world and OOP-style subtyping has fallen from grace.

Cyph0n 9y ago

So the fact that Go provides no solid dependency management solution is "personal opinion"? If everyone followed this approach, we would never have ended up with amazing languages like Rust. Why try to improve C++ if you can build cool stuff with it, right?

czbond 9y ago
What do you mean by "no solid dependency management"? Do you mean out of the box? This used to be true, but with glide and dep (https://github.com/golang/dep https://github.com/golang/dep) it seems to. It is not npm or bundler - but progressing.
- chisleu 9y ago
  Yes, go decided to wait to let the various competing systems duke it out in much the same way that node.js left it out for a while. I use git as my dependency management. I pull a specific version of a golang dependency and put it into my private git repository. Then i don't have to worry about someone's github getting hacked, repositories getting deleted, etc... Those problems have all happened with npm and github in the node ecosystem. Go solves these problems by allowing you to decide on how to manage your dependencies.
  - iends 9y ago
    This is no longer true. The core team proposed vgo a few weeks ago, after the majority of the community solidified around godep.
  - Keats 9y ago
    Do you also fork all their dependencies and subdependencies and fix the path in all of them? Otherwise you are still at the mercy of account/repo renames or deletions
- andreygrehov 9y ago
  They are going to be deprecated. See https://research.swtch.com/vgo https://research.swtch.com/vgo
  - jerf 9y ago
    But in a nominally reverse compatible way, and nobody can really force you to stop using dep if that's what you do.
- kbenson 9y ago
  > It is not npm or bundler - but progressing. I assume NPM has gotten a lot better in the last few years if it's being used as example of something to strive towards. Every time I have to mess with the Node ecosystem, it really makes me question the direction I'm heading with the research or project I'm working on, just by the haphazard way modules seem to be used and dealt with on both the dependency level and at the repository/packager level. The last time was a couple months back with Reasonml. Reason seemed (and still seems) really cool, but ultimately I wasn't willing to put up with the umpteen layers of indirection just to compile to JS.[1] 1: I know there's an Ocaml compiler as well, but it didn't easily support some of the use cases I was looking at.
  - bbatha 9y ago
    > I assume NPM has gotten a lot better in the last few years if it's being used as example of something to strive towards. Make sure that you are evaluating the tool not how the community uses the tool or npmjs.com runs the registry.
    - tonyarkles 9y ago
      They're pretty inseparable. If npm is great, and the community and default registry are terrible, I'm still not going to want to use the tool if I don't absolutely have to.
- Cyph0n 9y ago
  I was using one of the points raised in the linked article to refute OP's point about "personal opinions" in the context of critiquing programming languages in general.
  - czbond 9y ago
    You did. My mistake, I guess the point you were making didn't register.
dcu 9y ago
I've been using `glide` for a few years now, no issues at all. It's the same as cargo(rust), bundler(ruby), npm(js). Thanks to Go it's probably better since deploying dependencies in those languages is really painful. And not mentioning the security issues associated with having a central repository for packages.
- reificator 9y ago
  > It's the same as cargo(rust) > deploying dependencies in those languages is really painful. Can you please elaborate here? What's painful about Rust dependencies?
- sakuronto 9y ago
  Ruby and Rust both let you have your own repository for packages, so that doesn't make much sense, and AFAICT Rust literally needs two lines of code to pull in a new package, so I can't exactly agree that it's painful. I don't know much about Glide but if it uses Git for packages then that's pretty much centralized thanks to GitHub, too. At least the properly centralized solutions help assure you that, unless you're running a server yourself, the package is guaranteed to exist online, and even the developer can't remove it. On GitHub there's far too many things that could go wrong, and I have much less confidence that repos will continue to exist.
mswift42 9y ago
> If everyone followed this approach, we would never have ended up with amazing languages like Rust. What approach would that be? > Why try to improve C++ if you can build cool stuff with it, right? Go improves on C++ in at least one regard, compile time. And there they succeeded spectacularly. While I like Rust, imagine how great it would be with Go's compile speed..
- Cyph0n 9y ago
  > What approach would that be? Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. > Go improves on C++ in at least one regard Go is a GCed language, so you can't really compare it to C++.
  - mswift42 9y ago
    > Disregarding all critique of a language as "personal opinion" as long as you can "build cool stuff" with it. GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. > Go is a GCed language, so you can't really compare it to C++. That's a very strange thing to say.
    - Cyph0n 9y ago
      > GP said it's more valuable to evaluate a programming language by the projects people make with it, than by reading the 417th piece of perceived strengths and weaknesses of it. I think GP has a point. And I don't, so let's just agree to disagree on that. > That's a very strange thing to say. Does this (or any other) advantage of Go help people who are writing software that cannot have a GC in the loop? No, it does not, so it's really not a valid comparison imo. Could Rust and C++ have better compile times? Maybe. I'll defer judgement to the actual compiler experts though.
      - mswift42 9y ago
        it is my understanding that the bad C++ compilation speed is one of the reasons behind Go's inception. Go has a GC because its creators thought they needed one to support concurrency.
laumars 9y ago
> So the fact that Go provides no solid dependency management solution is "personal opinion"? The fact this is argued as a bad thing is personal opinion. He might have a valid point on that specific arguement but it's still an opinion piece as there have been others who have voiced how they like vendoring in Go. > If everyone followed this approach, we would never have ended up with amazing languages like Rust. Why try to improve C++ if you can build cool stuff with it, right? The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. I see language bashing really as more of a tribal ritrial rather than a productive contribution. Like the KDE Vs GNOME wars or the vi Vs emacs debates before that. For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars.
- Cyph0n 9y ago
  > The guy isn't designing a new language or trying to improve upon an existing language. He's just airing his opinion. So how do you think new language development starts? Why do we have languages like Rust, D, Nim, and Crystal?
  - laumars 9y ago
    > So how do you think new language development starts? By people writing code rather than pontificating > Why do we have languages like Rust, D, Nim, and Crystal? Because people wrote them rather than wasted hours on end arging why other popular solutions are garbage. As I said in my previous post: "For what it's worth, when I haven't liked a particular language which I've depended on, I've written my own parsers to add features. I'm not suggesting everyone should do this but it's a great deal more useful than starting flamewars." Or to put things another way, you don't see the developer of Nim endlessly slagging off other languages. He just quietly gets on and creates something awesome.
    - wuliwong 9y ago
      >By people writing code rather than pontificating Or maybe a both things are important?
strkek 9y ago
Well, one thing that Cargo got wrong is forcing you to clone a full git repository when only the latest commit is relevant. IMHO it should allow me to either use a shallow clone or use crates.io's API directly.
- tomjakubowski 9y ago
  There's a Cargo bug tracking this. https://github.com/rust-lang/cargo/issues/1171 https://github.com/rust-lang/cargo/issues/1171
- __sr__ 9y ago
  It’s not a design flaw that can’t be fixed down the line with coming up with a backwards incompatible v2.0 of the langauage.
AnIdiotOnTheNet 9y ago
I might argue that it's a bad thing, because it encourages dependency bloat if nothing else.
saturn_vk 9y ago
There are at least two solid, though not as mature as maven, dependency managers for go, so it seems even yours is a personal opinion.
endorphone 9y ago
Some of us have some fatigue about this topic as it has been retrodden literally hundreds of times on here, an army of people stomping their feet and screaming "OMG WHY ARE PEOPLE STILL USING GO!?" If everyone followed this approach, we would never have ended up with amazing languages like Rust. This comment reminds me of the top comment in a prior anti-Go spiel (which of course did well on here). https://news.ycombinator.com/item?id=7660924 https://news.ycombinator.com/item?id=7660924 Is it interesting how little of consequence is written in Rust, or in that example Haskell, and how much is written in Go, C, and even derelict dregs like PHP. The formal perfection of a language does seem to have a great deviance from the likelihood that it serves as a basis for important work.
- weberc2 9y ago
  > Is it interesting how little of consequence is written in Rust, or in that example Haskell, and how much is written in Go, C, and even derelict dregs like PHP. Exactly this. It always amazes me when people respond with "You can't judge a language by the things that are built with it because you can build anything in any Turing complete language". They're pretty much arguing that haskell/rust etc are better than go because all languages are equal.
- __sr__ 9y ago
  > Is it interesting how little of consequence is written in Rust, or in that example Haskell, and how much is written in Go, C, and even derelict dregs like PHP. The formal perfection of a language does seem to have a great deviance from the likelihood that it serves as a basis for important work. That is pretty simple to explain. Well designed languages have a learning curve. They require an initial investment in terms of learning — something that a lot of self styled hackers are not willing to put in. I am sure a ton of stuff is written as shell scripts. And there is also the matter of how long the language has existed.
- Cyph0n 9y ago
  I agree with your point, but I'm not sure how it ties in to the comment I was replying to. Edit: You seem to be overlooking the less tangible contributions languages like Rust or Haskell have made to PLs in general. One example that comes to mind is how Scala has affected the development of Java, even though, in the real world, Scala use is relatively non-existent.

SomeHacker44 9y ago

I am not interested in what people CAN make in a language. Anything that can be made can be hypothetically made in any (Turing-complete) language. That is an, IMO, silly criteria. People made awesome things (for the time) flipping switches and entering opcodes directly at one point. I am interested in a language that makes things easy, clear and elegant. I agree with the original article in that I do not find Go to be any of these for many things I would use it for. Hence, I do not use it. I think the author’s comment that Go ignored a lot of modern programming language theory especially hits it on the head for me.

laumars 9y ago
> I am interested in a language that makes things easy, clear and elegant. Isn't the easiest way to establish that by writing code yourself rather than reading an opinion piece written by someone else who likely has a different coding style to yourself?
- SomeHacker44 9y ago
  Been there, done that. We built a heavily asynchronous back-end communications service in Go a year or two ago. It was a great learning experience. I learned that I don't like Go and its limitations and design choices first hand, wrote a bunch of notes about what I did and didn't like (mostly didn't like), and moved on. We had chosen Go to use for the reasons others here have commented about (especially the part about enabling relatively inexperienced software engineers to be productive quickly), but in the end I felt it sacrificed too much on that altar and I would rather spend more time mentoring and training our software engineers to use tools I felt were better. It's mostly a matter of opinion, like I said - with sufficient dedication you can pretty much do anything with any language. But I'm not investing any more time into Go when I have other tools out there (like Clojure, Rust, Haskell, Common Lisp, C#, various BEAM languages, Ruby/Python, etc.) that I find to be uniformly more pleasant to use.
  - lilbobbytables 9y ago
    Curious what you preferred over Go for the task mentioned.

JetSetWilly 9y ago

If you don't like articles on this topic, then don't read them. Why bother to tell us all about how you don't like this kind of article and you would much rather read about X instead? Plenty of people do, so leave them in peace to get on with it.

ebiester 9y ago

I try to read one of these on the major paths I'm not on. It's answering the question, "should I build my next project in what I know, or checking something new out?" Seeing these for Go, Rust, Elixir, Elm, and others let me narrow it down before spending the 4-8 hours to figure out if it works for my brain and use case. (For example, seeing this tells me that Go is bad for the things I want to build because my brain works in types and good error checking.) I'd prefer more of these, frankly.

rwj 9y ago

Why would a professional evaluate their tools?

coldtea 9y ago

>So I'm far less interested in hearing people intellectualise over what they perceive to be good or bad qualities of a particular language (otherwise known as arguing personal opinion as irrefutable fact) and far more interested in seeing what what cool projects people can make. People can (and have for decades) MCGyvered "cool projects" with all kinds of primitive and shitty languages and tools. Progress doesn't come from projects, it comes from better tools. As a caveman, you could build all kinds of heating projects, but you wouldn't get far if your only invention is the fire...

brandur 9y ago
Spot on. Some programming languages can be, and are, better than other programming languages. They've all been evolving along a single historical timeline, and many mistakes were made in the past that we acknowledge and wouldn't make again. To take a well-known example: eminently abusable Turing complete templates in C++ versus the more modern generics as seen in C#, Java, Rust, etc. We should all have a shared goal of building of tooling that maximizes our leverage by providing powerful primitives, and minimizes the number of mistakes we make by providing dependable safety rails. Some more recent programming languages are really doing an exceptional job of this. This critique of Go quite correct. It's a pretty good language with a lot of pretty good ideas, but it's also not without a healthy dose of very sizable flaws as well (which the author has enumerated nicely), and they're made more concerning because most of the Go team refuses to acknowledge many of them. Without even going near the third rails of package management or generics, other niceties like real enums, ways to build typed non-slice non-map data structures, safety measures to protect against Goroutine leaks, or explicit interfaces would all be big improvements. I personally find that once it comes to large projects, Go feels obviously less brittle than Ruby/Python/JS, but much closer to their end of the spectrum compared to languages that offer stronger guarantees (e.g. Rust, Haskell, but also even languages like C#). I don't think that's what its creators were going for.
- edflsafoiewq 9y ago
  Interesting example of PL progress. I would have said that free-style templates were part of the "C++ way", in fact fairly close to its essence. One feature which seems to lie along the axis of forward progress is lambdas (even Java got them) and one that appears to lie in its past is unstructured control flow (IMO this is somewhat regrettable). One thing I wish languages would all evolve is an expression-language syntax but there was and is a surprising amount of kvetching about Rust's "implicit returns" so perhaps I'll be waiting a while longer for that. OTOH, the idea of forward evolution is also deceptive. The imperative world had tagged unions many decades ago, but they were abandoned in the OOP craze in favor of forms of subtyping (the Modula-3 designers at least gave this justification as a form of pure progress) and it's only fairly recently that they have percolated back over from the functional world and OOP-style subtyping has fallen from grace.