5 ms·

> Developers, please suck it up, get over it and learn C/C++ and some variation of Lisp. I've got over 20 years of writing production C/C++ under my belt and I

> Developers, please suck it up, get over it and learn C/C++ and some variation of Lisp. I've got over 20 years of writing production C/C++ under my belt and I know Lisp. So I've "sucked it up." Am I allowed to like Go now? It never ceases to amaze me how many people are bothered about other people's taste in something so mundane. If you don't enjoy programming in Go, don't do it. I personally think it feels light and easy like a scripting language, but with more C-like performance. I like the fact that its stdlib is very complete, so I can sit down and do pretty much any kind of small project with zero external dependencies, I like the fact that the core libraries are well-designed so the interfaces are consistent and easy to learn, I like the fact that it produces statically-linked binaries so deployment issues are minimal, I like the simplicity of the CSP approach for a lot of concurrency problems. I could also come up with a list of things I don't like about Go, but I'm not going to bother, because I've decided that on the whole, I really like it as a tool. Btw: > Positives... Has a fairly nice package manager like npm One of my biggest complaints about golang is that it really doesn't have nice dependency management. It's terrible and probably the one issue that has made me seriously consider walking away. :)

socmag 10y ago
Sure, what you say is true but equally so or better for .Net or Java as well, plus they are generally faster and in the case of C# a better language imho. Why not them? You are right, the standard library is a pleasure to work with in Golang and for the most part I trust it, but hey anything you can do in that library is easily reproducible in more or less any other mainstream language. I really don't have an axe to grind with the language itself, it's a fun and productive thing to use for sure. My main problem is with people who spend most of their time writing customer service applications thinking that the same language they are ultra successful with in that space is suddenly appropriate for writing systems software, because, ughh "safety"? There is a heck of a lot more to safety than buffer overruns, and if you can't formalize abstractions for dealing with memory usage patterns, one might argue you have no business writing Tor in the first place. Hah well compared to C/C++ dependency management, Golang does pretty darn well!
- geodel 10y ago
  I see Go equally fast compare to Java/C# and uses quite a bit less memory. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=csharpcore http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html
eropple 10y ago
> If you don't enjoy programming in Go, don't do it. Ordinarily, I would agree; I don't really care what people do when writing application code. The way it's filtered into devops tooling makes the choices of Go peoplea problem for me, though. If I'm going to be stuck with a language with bad error handling and inexpressive typing, I'd rather it be Python or Ruby so at least I can leverage dynamic typing instead of bad static typing.
- hamburglar 10y ago
  Well I could make the same complaints about how ruby has "filtered into devops tooling." If I never see another quasi-DSL that's really just a cute set of ill-specified ruby methods I will die happy.
  - eropple 10y ago
    You're talking a taste thing; I'm talking a correctness thing. The inability to create an easily-managed DSL doesn't compensate up for Golang being actively dangerous when it comes to error management. One of these provides structures for ensuring that you catch errors and can do the right thing, and the other demands that you if-check them upon every invocation of a method that can fail.

socmag 10y ago

Sure, what you say is true but equally so or better for .Net or Java as well, plus they are generally faster and in the case of C# a better language imho. Why not them? You are right, the standard library is a pleasure to work with in Golang and for the most part I trust it, but hey anything you can do in that library is easily reproducible in more or less any other mainstream language. I really don't have an axe to grind with the language itself, it's a fun and productive thing to use for sure. My main problem is with people who spend most of their time writing customer service applications thinking that the same language they are ultra successful with in that space is suddenly appropriate for writing systems software, because, ughh "safety"? There is a heck of a lot more to safety than buffer overruns, and if you can't formalize abstractions for dealing with memory usage patterns, one might argue you have no business writing Tor in the first place. Hah well compared to C/C++ dependency management, Golang does pretty darn well!

geodel 10y ago
I see Go equally fast compare to Java/C# and uses quite a bit less memory. http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=csharpcore http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... http://benchmarksgame.alioth.debian.org/u64q/go.html http://benchmarksgame.alioth.debian.org/u64q/go.html

eropple 10y ago

> If you don't enjoy programming in Go, don't do it. Ordinarily, I would agree; I don't really care what people do when writing application code. The way it's filtered into devops tooling makes the choices of Go peoplea problem for me, though. If I'm going to be stuck with a language with bad error handling and inexpressive typing, I'd rather it be Python or Ruby so at least I can leverage dynamic typing instead of bad static typing.

hamburglar 10y ago
Well I could make the same complaints about how ruby has "filtered into devops tooling." If I never see another quasi-DSL that's really just a cute set of ill-specified ruby methods I will die happy.
- eropple 10y ago
  You're talking a taste thing; I'm talking a correctness thing. The inability to create an easily-managed DSL doesn't compensate up for Golang being actively dangerous when it comes to error management. One of these provides structures for ensuring that you catch errors and can do the right thing, and the other demands that you if-check them upon every invocation of a method that can fail.