3 ms·

Is there really anything else in Go than "pretty good standard library". Looking at this and many other Go discussion it seems there isn't. I've been using Go

by illuminati1911 9y ago

Is there really anything else in Go than "pretty good standard library". Looking at this and many other Go discussion it seems there isn't. I've been using Go for a while now and while standard library is ok and definitely better than the one in Node.js and I really like strong typing, I still have to say Go is probably one of the worst programming languages I have ever seen in my life. Error handling is from the stone age, no support for generics, no support for functional programming, no real enum but instead "a hack" you have build by yourself, dependency management without versions etc. Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Due to the language limitations it's also nearly impossible to write elegant code with Go. If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same: Tons of "if err != nil" and for loops.

marcus_holmes 9y ago
Yes. Go is all about writing simple, boring, code that works (to paraphrase another comment here). And works really fast.
- flavio81 9y ago
  >boring Not boring. Just "full of boilerplate" which also means that it will be a nightmare to maintain at a certain point of the lifecycle.
strkek 9y ago
> Is there really anything else in Go than "pretty good standard library". An easy to understand language spec, a compiler that can spit executables that don't depend on glibc, no dependencies on Python 2, and most (if not all) packages under /x/ are BSD licensed. > Error handling is from the stone age I actually prefer this approach to explicit error handling, as opposed to the trendy "uncontrolled non-local gotos" approach (a.k.a. "exceptions". I'm borrowing that term from someone else). The only sane-ish approach to exceptions I'm aware of is that of Java, where you explicitly have to tell which exceptions can happen, and force you to either handle them right there, or modify your function signature accordingly. Still, with a big `try/catch`, if two calls throw the same exception, both exceptions would go to the exact same `catch` block. Yeah, thanks, but I appreciate how Go makes ignoring errors very eye-catching. Makes code review easier. > no support for generics Devs are actually very open to generics. The thing is, nobody has, as of yet, proposed any implementation that would play nice with the rest of the language. > no support for functional programming I don't see the problem. It's not like every new programming language should support every possible feature known to humanity. They would end up like C++, where you don't know if the next version will add the Unreal Engine to the stdlib. If anything what we need is more minimalist programming languages, not the next bloat of the century. > no real enum but instead "a hack" you have build by yourself I can see the point here. > dependency management without versions This is actually one of the things I like the most about Go. "Fix your thing to work with the latest version, or bundle your working version", sounds very reasonable to me. No concept of versions, no centralized source for anything. Just repositories and an ad-hoc way to setup your "registry" just by including an HTML tag in a web server you own. The only assumptions made about "packaging" is that (1) they're somewhere on internet, and (2) you have the command necessary to fetch them. If anything, what I don't like about `go get` is that adding a new "handler" requires recompiling the `go` executable. > Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Sure. Go brings nothing new to the table. > Due to the language limitations it's also nearly impossible to write elegant code with Go. Most Go code looks elegant to me. Same formatting everywhere (except when someone does not use `gofmt`). It also means that whenever I see `a + 1`, and the code compiles fine, I know it's a numeric addition, and not an HTTP request, for example. Go is like a language with some linting in the spec. Compiler error for unused variables? Yes thanks! Makes reviewing code easier. > If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same Looks like a plus to me. > Tons of "if err != nil" I don't know, I always considered a good practice to handle errors as soon and as explicitly as possible. > and for loops. WHAT!? No more `for (;;) {}` vs `while (1) {}` discussions!!!11!1!!ONEONE. Making people think twice before introducing the Go equivalent of `Array.prototype.forEach` vs `_.each` vs `$.each`, looks like a plus to me as well. Working as close as possible to the primitives unless strictly necessary.
GhostVII 9y ago
> If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same I think that's kind of the point though. Go gives you one way to do things, and makes it really easy to read no matter what your level. It makes things very boring, which imo is a good thing in lots of cases. Its also terrible for some use cases because it is quite verbose (as you mentioned, err != nil can get tiresome if errors don't matter much), so you gotta find a good balance.

marcus_holmes 9y ago

Yes. Go is all about writing simple, boring, code that works (to paraphrase another comment here). And works really fast.

flavio81 9y ago
>boring Not boring. Just "full of boilerplate" which also means that it will be a nightmare to maintain at a certain point of the lifecycle.

strkek 9y ago

> Is there really anything else in Go than "pretty good standard library". An easy to understand language spec, a compiler that can spit executables that don't depend on glibc, no dependencies on Python 2, and most (if not all) packages under /x/ are BSD licensed. > Error handling is from the stone age I actually prefer this approach to explicit error handling, as opposed to the trendy "uncontrolled non-local gotos" approach (a.k.a. "exceptions". I'm borrowing that term from someone else). The only sane-ish approach to exceptions I'm aware of is that of Java, where you explicitly have to tell which exceptions can happen, and force you to either handle them right there, or modify your function signature accordingly. Still, with a big `try/catch`, if two calls throw the same exception, both exceptions would go to the exact same `catch` block. Yeah, thanks, but I appreciate how Go makes ignoring errors very eye-catching. Makes code review easier. > no support for generics Devs are actually very open to generics. The thing is, nobody has, as of yet, proposed any implementation that would play nice with the rest of the language. > no support for functional programming I don't see the problem. It's not like every new programming language should support every possible feature known to humanity. They would end up like C++, where you don't know if the next version will add the Unreal Engine to the stdlib. If anything what we need is more minimalist programming languages, not the next bloat of the century. > no real enum but instead "a hack" you have build by yourself I can see the point here. > dependency management without versions This is actually one of the things I like the most about Go. "Fix your thing to work with the latest version, or bundle your working version", sounds very reasonable to me. No concept of versions, no centralized source for anything. Just repositories and an ad-hoc way to setup your "registry" just by including an HTML tag in a web server you own. The only assumptions made about "packaging" is that (1) they're somewhere on internet, and (2) you have the command necessary to fetch them. If anything, what I don't like about `go get` is that adding a new "handler" requires recompiling the `go` executable. > Also the hyped features such as channels are nice, but nothing a simple Rx-library couldn't do. Sure. Go brings nothing new to the table. > Due to the language limitations it's also nearly impossible to write elegant code with Go. Most Go code looks elegant to me. Same formatting everywhere (except when someone does not use `gofmt`). It also means that whenever I see `a + 1`, and the code compiles fine, I know it's a numeric addition, and not an HTTP request, for example. Go is like a language with some linting in the spec. Compiler error for unused variables? Yes thanks! Makes reviewing code easier. > If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same Looks like a plus to me. > Tons of "if err != nil" I don't know, I always considered a good practice to handle errors as soon and as explicitly as possible. > and for loops. WHAT!? No more `for (;;) {}` vs `while (1) {}` discussions!!!11!1!!ONEONE. Making people think twice before introducing the Go equivalent of `Array.prototype.forEach` vs `_.each` vs `$.each`, looks like a plus to me as well. Working as close as possible to the primitives unless strictly necessary.

GhostVII 9y ago

> If you take a look at any codebase, build by experienced senior developer or junior dev straight out of college/high school the code is almost always the same I think that's kind of the point though. Go gives you one way to do things, and makes it really easy to read no matter what your level. It makes things very boring, which imo is a good thing in lots of cases. Its also terrible for some use cases because it is quite verbose (as you mentioned, err != nil can get tiresome if errors don't matter much), so you gotta find a good balance.