As someone who writes Go every day for work, I can't agree that Go is simple. Using a language for analytics without generics can be quite painful and error prone.
Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself.
When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cases for your code hurts productivity.
I also believe that languages exist to make getting to an end result in given domains easier. Go does not make my life easier.
I really hope it gets generics. I wish it would do away with nil/null.
Nim is a very good language that actually accomplishes the simplicity Go wanted imo.
Go affords simplicity to the Go compiler writers at the cost of burdening Go users with having to remember inane things.
What we like to keep missing is that golang innovates not as a language, but as a tool to contribute to software project success.
Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far?
The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole.
Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards.
This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.
Is it really the case that languages with more features cause more project failures? Has the success rate of Java (the prototypical blub language) decreased after they've introduced new features like generics?
My experience has often been that whatever feature is lacking in the language tends to be made up for by huge code bases that are impossible to navigate, or using frameworks that abuse whatever dynamic features you have in the language horribly with added complexity in tooling and debugging.
Go has been around nearly a decade with the backing of none less than Google and yet it remains a fairly fringe language. Elixir is on a much steeper adoption curve. So is Swift, but Elixir doesn't even have a tech heavyweight behind it.
As some people like to point out, I'd also like to remind that in 1968 Algol had:
- user defined record types
- user defined sum types
- switch/case statement with support for sum types
- unified syntax for value and reference types
- closures with lexical scoping
- parallelism support
- multi-pass compilation
Given that many mainstream languages don't offer even what Algo68 had, I personally understand how a Go developer might thing that "nothing is new under the sun" since the 80's. After all, Go ignores all progress in programming languages for the last 40 years.
I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.
>After all, Go ignores all progress in programming languages for the last 40 years.
I've seen this meme being spouted so much every time Go's mentioned it's ridiculous.
No, piling up feature upon feature is not progress otherwise we wouldn't be using anything but C++.
Go is a language you pick for the right situation. If it's not enough for what you're trying to do, go for a different one instead of trying to expand in the wrong direction leaving you with warts, like Java's done, C++'s done, Python, JavaScript etc... which you will have to end up avoiding in order to write performant and clear code, counting on luck not to have to deal with code that abuses those features to create anti-pattern upon anti-pattern.
I'm no language historian, but I did limit my timeframe to my personal experience of 36 years of development for a reason. There was necessarily incredible research in the 20 years prior to that, which made it into useable languages, of course this is no hard cutoff, just an arbitrary personal choice, and I am happy to stand corrected. My point was simply that at least in the languages that make up 2σ of all code running in production in the last 20-30 years very rarely do they include "language" features that did not appear as truly innovative sometime before that. It may be argued that simply including some prior research in a useable language is innovative, or that the incremental improvements are themselves innovation, but then we are bogged down in semantics. In summary every time anyone in recent years has claimed to be innovating in language design someone else counters it with prior art, and that Go never pretended to be innovative in this direction. Given the lineage, and experience of the Golang authors it is more likely, in general that they considered and rejected, rather than ignored.
The author is quite correct. Go is super boring, and runs fast. Two great points for it.
For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit.
The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that's easy to understand.
Here's just one example from me - both examples scrape some info from HTML:
+100 Go is super boring and that it's a selling point. Code is a tool, not a device for entertainment. I'm yet to meet a 20+year developer who is wowed by extensive/unique/complex features, which makes me think as I also mature as a developer I'm going to find those things less important.
However, the Go version is way easier to understand. Mind you, I have very little experience with Elixir. In the interest of being pragmatic, the easier code is to understand, the easier it will be to maintain, and we spend much more time maintaining code than writing it fresh.
> You end up with significantly less lines of code that's easy to understand.
That is very interesting claim, but there is something more than just tooling and number of lines of codes - a paradigm. Elixir is a functional [1] but Go is imperative [2] programming language. It changes a point in discussion quite a lot, especially when you say 'code is easy to understand'. Personally I prefer Elm over JavaScript/React, because it is 'easier and simplier', but I remember a situation in college when after C#-course we had introduced Prolog and F# and many of newbies found functional programming very difficult... But maybe it is matter of taste.
> Everything about the language and the surrounding tooling is polished.
I don't have strong Elixir experience, but playing with Phoenix framework made me really happy to see how many packages are well documented to create backend for web application. But is almost perfect, almost - because it is not Go.
Go is way more performant (Elixir have results comparable to Python or PHP[3]), has great virtual file system [4], auto generating docs (godoc), gofmt, gorename, golint, gocode (no matter which editor you use - VSCode, SublimeText, Vim you have great autocompletion) and a lot of other things (i.e. examples) which makes learning Go easy for newcomers (i.e. devs who are bored of PHP).
For instance, without changing too much, you could implement scrapeProfile like this: https://play.golang.org/p/sP34n9acy7 I think that reads quite nicely, although I'm sure someone else can do even better.
If you modified dumpToCSV to take an interface instead of the concrete type, you wouldn't even have to prepare the user structure. You could pass in the vcard directly.
This has been my experience as well. I think a lot of people came to Go looking to solve some limitations from Ruby, Python, JS. While it does that, you get a lot of trade offs that make it a great solution where you had a problem but not a migration path for everything.
From what I've found so far, Elixir gives a migration path for just about everything except heavy number crunching. Several people who came to Go from dynamic languages have seemed to echo this sentiment.
Having written a lot of elixir code and now spending my days writing Go code, I think of Go as a tragedy of missed opportunity. If go did concurrency correctly, the way elixir and erlang do it, it would be the language I want to use for everything (well and the pipe operator from elixir is really special.)
But concurrency in go is a terrible hack, it's just slightly better multi-threading with all the deadlocks and mutex and hassles that come with it. Channels and goroutines are not erlang processes.
That so many people think of go as a concurrent language shows how little people understand concurrent programming.
Every engineer who thinks they are decent needs to learn at least one good concurrent language (elixir or erlang would be my suggestions.)
So, Go is designed to be an engineering language and not an academic toy. Contrary to other languages, Go programmers "deliver" and have a pragmatic view of the real development world, not just their own commits. Go programmers need a deeper understanding of computer science because other programmers are lazy and have everything given for free and probably don't need to know how it works.
A whole page discussing the virtues of Go by insulting people.
Well no need to be so aggressive I guess. Many of the points make some sense. But ultimately for me I get the feeling that although the managers might be happy with Go, I'd definitely not want to be such a programmer day-in day-out.
The article mentions a keynote speech by Rob Pike* from 2012 which is quite illuminating. The trade-offs made were all centered around google-scale and the pain points of such a massive operation. It stands to reason that people working outside of that environment may be less pleased with the language.
Google is not the only entity that operates at scale, and simply because google does it does not mean it is the correct choice. That's kinda cargo cultish.
In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening.
tbh I don't think workers even inside of that environment will be much pleased either. The managers are likely pleased because it speeds up the organizational efficiency, but that doesn't necessarily have anything to do with the happiness of the developers who actually write code and have to bear its many unpleasantness. That's just two separate things.
> To provide any solution in Go that needs a dynamic data structure you can choose between hand rolled linked structures or a Slice or Map (or compose with them). As they are quite different the choice is normally obvious. Contrast this to the choice between map, set, hashset, bag etc etc, or rolling your own in a language that makes this a lot harder.
I can't help but think the whole article is filled with bursts of dishonesty.
A language like C++, which let you use the proper data-structure in about two lines of code, is a lot easier when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest.
If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.
I'm not much of a Go programmer but I would definitely regard Go's multiple return and error handling (save the 'no assertions' clause) as very cool. I'm not sure if any other languages have experimented with that approach before the rise of Go, but to me at least it appears much saner than the prevalent ridiculousness of exception handling.
Some languages support tuples - you can also use stuff like ADTs to the same effect. I think Go's advantage here is that it's the only way to handle non-panic exceptions, so you won't have systems where half of the errors are handled with exceptions and half with returning tuples, for instance...(I personally like the lack of "throwing exceptions" part, but find the multiple-return somewhat exotic)
Multiple return is great, though sending a tuple back is how we've been doing it in erlang for 20 years. Not much difference between {foo, bar} and (foo, bar).
Go's error handling however is terrible, absolutely the worst and its tendency to panic is atrocious. Especially without supervision or restart capability. HEre's a spot where elixir has it right and is vastly superior.
> Custom data structures can be composed from the well understood builtins, rolled in under 100 lines of code and can can exist close to the place they are used (yes repeated!). The effect of this approach on readability, maintainability, decoupling, ... adds so much more value to the whole lifecycle, than the cost of the omission.
It's interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google's source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It's of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.
> It is not ‘missing’ comprehensions, or inheritance, or generics, they are omitted (and I pray, always will be). In some way, in the context of the current fashion of returning to more functional languages, or the evolution of good old languages to include more functional paradigms (I’m looking at you Javascript and Python for two examples) then in a tenuous convoluted way Go has ‘innovated’ by avoiding that trend.
That's such a weird statement. If anything, those are likely more OOP-related than FP-related, and he didn't really point out what's so bad about "more functional paradigms", besides the implication that it might be harder for new hires to pick up etc.
Anyways, I see that Go reduces the learning curve and simplifies lifecycle of huge projects, but at considerable costs about language features and expressiveness. I myself if working as a developer would rather not bear those costs just for the sake of the whole clogs of the organization running a bit more smoothly, and also so that myself would not just program day-in day-out en masse with everybody else out there in an overly simplified language that potentially puts me at more of a disadvantage in my career path. Maybe the leaders of huge companies would have other thoughts and there will definitely be developers who are happy to fill those roles, it's just not me.
> “There is nothing new under the sun” rings true in all languages since the 80’s.
Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go.
Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler?
Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime?
Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it's simpler, but at too high a cost IMO.
To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years.
I think this article is very well written, but I don't think it's fair to the innovation going on in other languages.
(Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that's fine with me)
> Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one.
Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program.
Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!).
(inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)
> There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler?
This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck
Thank you, and may I say what a well written comment.
Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference.
Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about.
Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.
The irony in all of these comments is that they almost all fall back to, or start with, discussing language design, and on the whole ignore the tools and processes that have a consistency from Go team to Go team. The value of this power and consistency is probably overlooked in this and many other conversations because they are complex to discuss, and it is simply easier to focus on the almost provable value of the language features, missing or present (maybe another availability bias at work?). The point of the article was to try and refocus on Go as an engineering tool in a much broader context.
If you make a program that is executed a million of times or more a day, it make sense to have a language that is "near the CPU", and allows to optimize and speed up the most. This is what Go is. It will be a mistake to use it elsewhere.
[+] [-] codygman|9 years ago|reply
Go is a language that pushes remembering corner cases and failure conditions onto the programmer rather than the language and runtime itself.
When you already have to remember a myriad of corner cases for business logic, also remembering so many corner cases for your code hurts productivity.
I also believe that languages exist to make getting to an end result in given domains easier. Go does not make my life easier.
I really hope it gets generics. I wish it would do away with nil/null.
Nim is a very good language that actually accomplishes the simplicity Go wanted imo.
Go affords simplicity to the Go compiler writers at the cost of burdening Go users with having to remember inane things.
[+] [-] jksmith|9 years ago|reply
Project success in the software industry is abysmal, and we still keep thinking we can spin up another language that will contribute to project success because it let's us express ourselves in new ways. Well, how's that working out so far?
The reason why golang appears to have such wide adoption in such a short period of time is that it really does seem to contribute to helping devs get their shit done. Massive amounts of working code are being written in golang, and that's good for the software industry as a whole.
Currently I run a massive project written in the standard issue kitchen sink corporate language (C#). It's got generics, functional extensions, all kinds of shit to make the most discriminating programmer happy. Well guess what, IMO C# for all it's features still doesn't serve the business of software dev as well as golang because it doesn't pull off what golang is brilliant at (easy to code for wide range of skill levels, easy to mentor, easy to test, easy to hire for). The result is difficulty finding productive devs, and a code base that is not up to my preferred quality standards.
This may be hard to swallow, but it might really be the case that you can get more quality work done with more devs if toolchain simplicity is emphasized over language features. If the evidence continues to bear this out for golang, then it's time for me to shed some language biases just so I can remain competitive.
[+] [-] snom380|9 years ago|reply
My experience has often been that whatever feature is lacking in the language tends to be made up for by huge code bases that are impossible to navigate, or using frameworks that abuse whatever dynamic features you have in the language horribly with added complexity in tooling and debugging.
[+] [-] njharman|9 years ago|reply
[+] [-] sheepmullet|9 years ago|reply
> easy to hire for
There are 100x as many experienced C# enterprise developers. And that is being conservative.
[+] [-] xiaoma|9 years ago|reply
[+] [-] danmux|9 years ago|reply
[+] [-] bad_user|9 years ago|reply
I recommend watching "Growing a Language", a legendary presentation by Guy Steele: https://www.youtube.com/watch?v=_ahvzDzKdB0
I do love the attempts of Go developers to rationalize Go's choices. But in the end it will end up being a hated language, universally recognized as a net negative in the industry. But that won't stop the working programmer from doing the same mistake again and again.
[+] [-] mixedCase|9 years ago|reply
I've seen this meme being spouted so much every time Go's mentioned it's ridiculous.
No, piling up feature upon feature is not progress otherwise we wouldn't be using anything but C++.
Go is a language you pick for the right situation. If it's not enough for what you're trying to do, go for a different one instead of trying to expand in the wrong direction leaving you with warts, like Java's done, C++'s done, Python, JavaScript etc... which you will have to end up avoiding in order to write performant and clear code, counting on luck not to have to deal with code that abuses those features to create anti-pattern upon anti-pattern.
[+] [-] danmux|9 years ago|reply
[+] [-] snaky|9 years ago|reply
That's not unusual at all. Look what Fran Allen said about previous language from those guys - https://news.ycombinator.com/item?id=11578995
[+] [-] jacques_chester|9 years ago|reply
http://cowlark.com/2009-11-15-go/
[+] [-] sergiotapia|9 years ago|reply
For me however I just never felt happy writing Go code. I have a couple of open source projects with it, so I have put it through it's initial paces to see if we fit.
The language that did make me happy was Elixir. Everything about the language and the surrounding tooling is polished. You end up with significantly less lines of code that's easy to understand.
Here's just one example from me - both examples scrape some info from HTML:
Elixir: https://github.com/sergiotapia/magnetissimo/blob/master/lib/...
Go: https://github.com/sergiotapia/gophers/blob/master/scrape.go...
You tell me which one is nicer to look at and easier to understand.
[+] [-] leighmcculloch|9 years ago|reply
However, the Go version is way easier to understand. Mind you, I have very little experience with Elixir. In the interest of being pragmatic, the easier code is to understand, the easier it will be to maintain, and we spend much more time maintaining code than writing it fresh.
[+] [-] piotrkubisa|9 years ago|reply
That is very interesting claim, but there is something more than just tooling and number of lines of codes - a paradigm. Elixir is a functional [1] but Go is imperative [2] programming language. It changes a point in discussion quite a lot, especially when you say 'code is easy to understand'. Personally I prefer Elm over JavaScript/React, because it is 'easier and simplier', but I remember a situation in college when after C#-course we had introduced Prolog and F# and many of newbies found functional programming very difficult... But maybe it is matter of taste.
> Everything about the language and the surrounding tooling is polished.
I don't have strong Elixir experience, but playing with Phoenix framework made me really happy to see how many packages are well documented to create backend for web application. But is almost perfect, almost - because it is not Go.
Go is way more performant (Elixir have results comparable to Python or PHP[3]), has great virtual file system [4], auto generating docs (godoc), gofmt, gorename, golint, gocode (no matter which editor you use - VSCode, SublimeText, Vim you have great autocompletion) and a lot of other things (i.e. examples) which makes learning Go easy for newcomers (i.e. devs who are bored of PHP).
[1]: https://en.wikipedia.org/wiki/Functional_programming
[2]: https://en.wikipedia.org/wiki/Imperative_programming
[3]: https://www.techempower.com/benchmarks/#section=data-r12&hw=...
[4]: https://godoc.org/golang.org/x/tools/godoc/vfs
[+] [-] randomdata|9 years ago|reply
For instance, without changing too much, you could implement scrapeProfile like this: https://play.golang.org/p/sP34n9acy7 I think that reads quite nicely, although I'm sure someone else can do even better.
If you modified dumpToCSV to take an interface instead of the concrete type, you wouldn't even have to prepare the user structure. You could pass in the vcard directly.
[+] [-] brightball|9 years ago|reply
From what I've found so far, Elixir gives a migration path for just about everything except heavy number crunching. Several people who came to Go from dynamic languages have seemed to echo this sentiment.
[+] [-] viach|9 years ago|reply
[+] [-] 20yrs_no_equity|9 years ago|reply
But concurrency in go is a terrible hack, it's just slightly better multi-threading with all the deadlocks and mutex and hassles that come with it. Channels and goroutines are not erlang processes.
That so many people think of go as a concurrent language shows how little people understand concurrent programming.
Every engineer who thinks they are decent needs to learn at least one good concurrent language (elixir or erlang would be my suggestions.)
[+] [-] junke|9 years ago|reply
A whole page discussing the virtues of Go by insulting people.
[+] [-] codygman|9 years ago|reply
[+] [-] SZJX|9 years ago|reply
[+] [-] jbeja|9 years ago|reply
[deleted]
[+] [-] tux1968|9 years ago|reply
[*] https://www.infoq.com/presentations/Go-Google
[+] [-] 20yrs_no_equity|9 years ago|reply
In distributed systems, go is fragile and dangerous -- because it will panic. IT has no supervision system, and it has the potential for deadlocks, in fact, unless you engineer around it, all coroutines and channels will produce deadlocks and can silently kill your program. When that happens you have no idea why things are broken-- nothings happening.
And this is a language without a decent debugger!
[+] [-] SZJX|9 years ago|reply
[+] [-] p0nce|9 years ago|reply
I can't help but think the whole article is filled with bursts of dishonesty.
A language like C++, which let you use the proper data-structure in about two lines of code, is a lot easier when it comes to data-structures. While the Go programmer implements a multi-map, priority-queue or red-black tree, anyone else will have moved on to an actual topic of interest.
If you need a particular data-structure, surely having one ready in the toolbox is a net positive, not a negative.
[+] [-] unsignedqword|9 years ago|reply
[+] [-] herval|9 years ago|reply
[+] [-] gravypod|9 years ago|reply
[+] [-] 20yrs_no_equity|9 years ago|reply
Go's error handling however is terrible, absolutely the worst and its tendency to panic is atrocious. Especially without supervision or restart capability. HEre's a spot where elixir has it right and is vastly superior.
[+] [-] bpicolo|9 years ago|reply
Not a fan of this sentence. Why try to make it sound like Maps are unusual or bad? Just as fundamental as the list to real programming.
[+] [-] Myrmornis|9 years ago|reply
It's interesting to me that this philosophy comes from the Go designers at Google, and that Google is also well known for keeping vast amounts of source code advancing in lock-step in a single repository. From reading the recent article on Google's source code repository structure, I believe that being able to reuse code (e.g. data structure implementations) without versioning headaches is one of the intended and actual benefits. It's of course not that surprising that two different areas (Go design and repository structure) might pull in two different directions, but these are two important high level issues so it does seem a little inconsistent to me.
[+] [-] SZJX|9 years ago|reply
That's such a weird statement. If anything, those are likely more OOP-related than FP-related, and he didn't really point out what's so bad about "more functional paradigms", besides the implication that it might be harder for new hires to pick up etc.
Anyways, I see that Go reduces the learning curve and simplifies lifecycle of huge projects, but at considerable costs about language features and expressiveness. I myself if working as a developer would rather not bear those costs just for the sake of the whole clogs of the organization running a bit more smoothly, and also so that myself would not just program day-in day-out en masse with everybody else out there in an overly simplified language that potentially puts me at more of a disadvantage in my career path. Maybe the leaders of huge companies would have other thoughts and there will definitely be developers who are happy to fill those roles, it's just not me.
[+] [-] bluejekyll|9 years ago|reply
Really? Nothing? Sure a language like Rust has drawn from many other concepts in other languages, but it has done so while actually bringing high level features to a language that has zero overhead costs. But yes, it's not simple like Go.
Did Go need to make all errors unchecked? There are no guide rails telling you that you forgot to check an error result. This is a runtime thing you need to discover. Is this actually simpler?
Go made the decision to allow for Null, even after nearly every other modern language and other older ones are trying to kick it to the curb; Swift, Rust, Scala, Kotlin, no nulls (the JVM ones have a compatability problem, as does swift with ObjC, but still). Is it simpler to delay discovery of Null data to runtime?
Go decided to not have generics, to keep the language easier to learn and more approachable. It's hard to argue with this one. Like lambdas, it can be a complicated concept to learn, but once you unlock this in you code, you write less code and accomplish more. So yes, it's simpler, but at too high a cost IMO.
To me the innovative feature of Go is the small runtime built into the binary making deployment dead simple and easy. This is a million times better than JVM, Ruby, Python, Perl, etc. This is a huge improvement over Java, and something every language should have an option for. Ironically this is also the least innovative feature, because this is how static binaries in C and C++ have worked for years.
I think this article is very well written, but I don't think it's fair to the innovation going on in other languages.
(Disclaimer: I used Go, discovered the three primary flaws as I listed above, and then searched for a better language. It would be fair to call me a hater, usually I try to avoid this, but in this case that's fine with me)
[+] [-] catnaroek|9 years ago|reply
Plain parametric polymorphism is super easy to understand. Standard ML could be learnt in a week by someone who doesn't know how to program.
Admittedly, the interaction between parametric polymorphism and subtyping is tricky and subtle. And it seems most programmers have gotten used to taking subtyping for granted. But what if subtyping isn't always a good idea? Say, because it forces you to reason about variance (which humans always seem to do wrong!).
(inb4: Yes, Go has subtyping. When a struct conforms to a given interface, that's subtyping.)
[+] [-] omni|9 years ago|reply
This may be considered cheating since it isn't baked into the language but there are tools to do this at build time, here's one: https://github.com/kisielk/errcheck
[+] [-] danmux|9 years ago|reply
Poor old Tony Hoare (algol was mentioned earlier (rightly) as an exemplar of innovation) but Null in a safe memory managed context is a different beast to a true Null reference.
Null appears then as something between a known state and an not quite an exception, it carries different semantics from either, and whilst this could be seen as more complexity, I think the "I just don't know" case in practicality is useful, if harder to reason about.
Your point about the runtime is very true. Partly because of this - error checking is overrated! Yes I said it! We have go code that has been running in a reasonably high scale production environment for over two years and there are `if:...;err != nil` blocks that have never been touched in millions of calls per day, for 2 years. We have redundant services and trap panics in the rpc handlers, the nil becomes very clear and the rest of the system makes good progress. We save lines, save tests, and release a single binary fast. One example of where Go helps us deliver value faster, by being able to choose to ignore exceptions. Many people find this very uncomfortable. I say they are mistaking where the true project risks lie.
[+] [-] iends|9 years ago|reply
[+] [-] dominotw|9 years ago|reply
Is rust the only good alternative here to golang if you one doesn't want to write c/c++ ?
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] danmux|9 years ago|reply
[+] [-] knucklesandwich|9 years ago|reply
[+] [-] IshKebab|9 years ago|reply
There would be paralysis of choice if when you install Go you were forced to choose from that list, but you aren't.
[+] [-] jbeja|9 years ago|reply
[deleted]
[+] [-] AmazingLifeBot|9 years ago|reply
[deleted]
[+] [-] scriptproof|9 years ago|reply
[+] [-] soulbadguy|9 years ago|reply
[+] [-] catnaroek|9 years ago|reply
[+] [-] behnamoh|9 years ago|reply
(Frankly, I doubted that a little, until I realized Al-*-Go was not actually written in Go!)