9 ms·
I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research
by steinuil 9y ago
I really dislike Go as a language, it has very few means of abstraction and it feels depressing that people think you have to throw out decades of PLT research to achieve perceived clarity like this.
That said, these reasons are almost all linked to tooling, which is something that I have to admit Go gets right, but they're not intrinsically linked to the language itself and its feature minimalism. I wish there were better languages that had such nice tooling, but unfortunately not all langs have the luck of being backed by Google.
- lanestp 9y agoDoes someone want to give a reason for down voting this comment? There isn’t anything controversial here. For myself, lack of genetics are enough reason not to use the language. My personal style relies a lot on them and I don’t see myself sacrificing that power for above average tooling.
- reificator 9y ago> For myself, lack of genetics are enough reason not to use the language. The typo/autocorrect here turns this into a much more controversial statement...
- deleted 9y ago[deleted]
- int08h 9y agoRe: getting tooling "right" and that driving adoption/popularity. I'll argue that Java and the JVM are very similar in this respect. Few will argue Java is a "good" language and the JVM has many shortcomings. However the ecosystem of IDEs, JVM tools, and decades of big company investment (Sun, IBM, Oracle) have created an amazingly productive environment.
- steinuil 9y agoYes, my impression is that Go was created partly to be used in corporate environments to replace Java with a less verbose language that scaled well, and it seems to be doing well in that regard.
- kuschku 9y agoSadly, it ends up far more verbose than Java when you have (as I did after trying to port a project from java to go) over 200 copies of the same observable, sorted, copy-on-write set implementation, because Go doesn’t have generics. And then you change one thing in one place, and gotta change it everywhere again. No thanks.
- eadmund 9y agoSurely you could have used interfaces for this case, no?
- kuschku 9y agoAnd how do I get the same type out that I put in? I'd end up with Java 1 style programming, no generics, and having to cast atuff from Object/interface{} everywhere. interface{} is like Object, if it even exists once in your code, it's broken.
- eadmund 9y ago> And how do I get the same type out that I put in? You can only get out the same type you put in. Presumably in your code you know that collection of Foo objects contains Foos, so you can just do: if foo, ok = collection.get().(Foo); !ok { return errors.New("expected a Foo") } Write a few wrapper functions and you're done.
- kuschku 9y agoSo, we’re back in Java 1.0, and using Object and just casting back again? Seriously, this is why generics exist. I want to write it once, use it everywhere again, and want to have the compiler know if I made a mistake.
- falcolas 9y agoUltimately, programmers fall in a bell curve. Most languages which benefit extensively from that research target people on the right of that bell curve. Go, with its lack of complicated mechanics targets the middle of the bell curve. I don't have the luxury of working exclusively with people on the far right of the bell curve, so I'll end up picking Go with its simplicity for most projects. I can be assured that almost anyone can pick up code written in Go, and be productive much faster as a result.
- eeZah7Ux 9y ago> Go, with its lack of complicated mechanics targets the middle of the bell curve. No, it targets the less experienced - interns, as the language creators said.
- terminalcommand 9y agoI don't think Go targets the less experienced. Could you provide a resource, where the language creators have stated that Go targets interns? Go is a safe programming language, but it is not simple. Go has very rigid rules. I don't see any difference in complexity between programming in C and programming in Golang. Programming in Golang may even be harder than C. If you format your code wrong, Golang screams at you. If you import a package and never use it, Golang screams at you. If you redefine a defined variable, Golang screams at you. If you don't use a variable you defined, Golang screams at you. C is much more forgiving :). Golang makes dynamic memory management safe, but in nowhere easy. You still use the good old void* via an empty interface. For an intern, garbage collection doesn't matter, an intern is intelligent enough not to leak so much memory so that it will get noticed :). I sometimes think Golang resembles the early versions of Java. Creating a safer C-like language, with great ideals. With Java the complexity kicked in after a while. Golang still resists the urge to please everyone.
- lazyant 9y agoYou just gave some reasons why correctly programming in Go is easier than in C, like paint by the numbers or training wheels (restrictions) versus a blank canvas; it's easier to make mistakes in C, ergo harder to program in. Golang screaming at you is like having a coach.
- weberc2 9y agoGoogle doesn't invest heavily in Go. It almost certainly invests more in JS, Python, Java, and C++. I think the difference is philosophical--Go doesn't pretend that every obscure edge case deserves equal support to the main case, and so its tooling is much simpler.
- warent 9y agoI'm not sure where you get your information from, but Google definitely invests a substantial amount in Go. - Paid some of the most celebrated engineers to work on it full time. - Support it as a first class language in GCP - Support it as a first class language internally If you want to see a language Google doesn't invest much into, look at Dart
- roblabla 9y agoEven dart has substantial investment. Look at flutter, the new cross-platform ui toolkit for dart, and its use in Fuchsia.
- weberc2 9y agoGoogle pays a small team to maintain the language, but developing the language is very likely not a business objective in remotely the same capacity as .Net is for Microsoft or even Swift for Apple. It's not even a major headliner for Google's I/O conference. I would like to know where you're getting your information about Google not investing in Dart, because last time I checked, Google appeared to be investing considerably in Dart (this was back before the Dart vs TypeScript battle was settled though, so perhaps Google pulled up its investment). At any rate, Go's tools don't require significant investment because they are designed for simplicity (there is no package repository, no language-agnostic/fully-imperative build scripting language or project metadata files, no bring-your-own-unit-test-framework, no docstring syntax, etc). Go tools err on the side of supporting too few use-cases, where Java, Python, .Net, C++, etc build tooling typically emphasize explicit configuration over sane defaults.
- infogulch 9y ago> I wish there were better languages that had such nice tooling Have you considered that the reason why go has such great tooling is precisely because of its desperate grip on simplicity and non-configurability -- the very things you might call upon as why it's "bad". Maybe this correlation is more than coincidental.
- rdsubhas 9y agoWhile I neither love nor hate Go - I'm really confused about "Go gets tooling right". Is it mostly about the built-in gofmt and compiling to binary? Dependency management is far from right, for example, and so are stuff like hot code reloading, remote debugging, containerized development, etc. How does Go get tooling right compared to, say node/npm or java?
- yagurastation 9y agoTooling in regards to formatting: I guess you get to appreciate it when using gofmt automatically with your editor, eg. with Go extension for Visual Studio Code or vim-go. Turns out pretty much as he says (see given example at play.golang.org). You just type in the style you always have, but with the certainty that in the end it will be the same as the other's, easy to read, easy to maintain, and uncontroversial in terms of formatting. You could agree on google-java-format, I guess. But also potentially waste plenty of time on the decision itself :-) compared to a dictate and tool originating from the language itself.