Then Google announces Go. A cross-platform systems programming languages for high quality web services. That sounds great! I can't wait to see what Google came up with.
So when people saw Go disappointment set in. It has some great properties, but the language is not expressive. So Go web frameworks (like Revel) generate Go code at compile time to get the dynamic parts working. Just like we did in the 70s to work around C's shortcomings. Want a container for a specific type? Code generation! It's so clumsy. The lack of exceptions makes writing correct code really tedious. A web service is not a device driver where every edge case has to be carefully considered. Bailing out with an exception is fine. Go disagrees.
I think the disappointment in what Go could have been explains the vocal dislike. There are only a few companies in the world that can create a new programming language and ensure it becomes popular. Don't get me wrong. Go isn't a bad language. It's just not the language that will push the web forward, and Google was in a unique position to create a programming language that would.
This is part of why Go culture scares me a bit. You seem to be overlooking the huge amounts of software written in .NET and on the JVM, none of which suffers from the problems you just outlined: there are great IDEs, decent type systems, good interactive debuggers, strong standard libraries, reasonable package management etc.
This mental blind spot towards the tools and practices that a massive part of the software industry has been using for years is really odd.
I think we can do a lot better than .NET or Java. .NET isn't even cross platform and Java has a lot of legacy cruft. Not to mention both platforms are pretty bloated and not even designed with the modern web in mind.
These languages are getting better about it, but they are tacking on functional programming to a language that traditionally was strictly OO, and in the same way C++ has a lot of edge case behavior in being "OO tacked onto imperative" these languages suffer similarly.
Yikes, that's an assumption that is going to bite you hard in your career. I recommend escaping it as soon as possible. ;) The web is full of horror stories from people who assumed their part of a web-accessible product wasn't on a critical security / safety / reliability path.
I used to use Python and Ruby on Rails for web services; this is precisely why I left them. I got tired of dealing with typos becoming runtime exceptions.
> Bailing out with an exception is fine. Go disagrees.
Go makes it trivial to bail out with an exception: You panic. But panic is reserved for real exceptions, not common and expectable situations (like "file not found") and its defaults are therefore set to crash the whole process (which is fine if you're doing microservices and therefore can handle failures by crashing and restarting). I find other languages treat exceptions as not sufficiently exceptional.
That is why you must do 100% code coverage on all non-compiled language.
Tedious up front often translates into time saved down the road. Exceptions are often an easy way out while accruing future debt.
Unfortunately, our industry cannot easily measure the time saved down the road and so cannot properly value it. However, many with long term interests in a project will often spend on the "tedious" costs up front to avoid potential future costs.
Exceptions are a red herring; they are just something you can build if you have dynamic control transfers with unwinding. And if you have macros, or at least some kind of access to the language to bend the syntax. Plus perhaps other goodies like testing whether some object X is of a type which is a subtype of T so you can make exception handling frames decide whether the elevator stops here.
The underlying control mechanism not being there makes the language crippled.
Just give me C. Then I also have forty years of research out the window: but but at least with setjmp and longjmp.
How does Bash recover to the top level prompt when the scriptage fails deeply nested in some function calls? Why, longjmp! I will fake the unwinding if I have to.
Is there perhaps a concrete illustration on how using exceptions causes technical debt, especially in a GCed language like Go?
Maybe the static typing and IDE support are enough to make Go awesome for some, but they don't really matter to me as much as concurrency, hot-plug code deployments, the actor model, and stability.
So, as you said, when i looked at go being a smart and small with a modern standard lib, and being modern in a way with its approach to interface programming i thought i would fall in love with it.
Then i saw go didn't have a single generic function for comparing two numbers, because the language wasn't generic enough, and i felt hugely disappointed.
If you want something similar to the Go standard library HTTP server, there is this one that comes with the JDK out of the box. Most people don't know it's there though, as technically it's not a part of the Java platform, it's just something that comes bundled with the standard JDK:
https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver...
If you're building a serious app you will want support for more advanced stuff. That's when you can upgrade either to a better HTTP server like Jetty, or to a full web framework that bundles templating, authentication, database access, session management and all the rest. Play! Framework is quite well known. It ignores all the standard enterprise Java conventions in order to be a lot more opinionated. If you like their opinions, that sort of approach can be way lighter.
Did they actually advertise it as a language for web services? I thought it was designed for command line tools mostly, not for serving HTTP/HTML.
https://web.archive.org/web/20091112094121/http://golang.org...
If all you want is a bail out mechanism then panic.
Go does have exceptions.
I recently moved teams so that I could use Go exclusively. It's often been said that Go solves the problems Google developers have, and it's 110% true. It's much easier to get things working, and it's much easier to write things like Protocol Buffers. But the key for me is that Go isn't fun in the sense of "wow, I'm so smart that I managed to one line this thing", it's fun in the "wow I read this code and I can understand what's happening and hack on it to do something else."
I've worked on teams with monolithic Java code, and it's nigh-on impossible to understand what's happening and where you are in the logic flow. I don't have that problem in Go. I even delve into the standard libraries to see how the original Go devs did something, and I both understand it and think it looks like code I would have written too. I never get that feeling from any other language, where I feel like the standard libs are written by hyper-intelligent aliens.
When I exclaimed this internally, I got the sarky comment "It's almost as if the things Go leaves out makes it easier". And that's the core of it. Would I like generics? Sure; I do miss map(). But that's it.
Go is opinionated. People that don't like Go don't share the opinion. That's OK. It's taken me a long time to realize there is no One True Language that can do everything (it was soon after steveklabnik said something along the lines of "I don't know why you'd want to write a web app in Rust"). Once you get there, you won't hate Go anymore, nor indeed any other language.
Apart from C++. Screw that ;)
1. Things that should be compile time errors turning into runtime errors.
2. An IDE that can't navigate anywhere or usefully analyze the code because everything has interfaces between it.
3. Things being mocked out in unit tests just because they can be, meaning lots of superfluous code and tests that pass when they should fail.
There's nothing about Java that mandates this style of programming. It's the result of years of programmers trying to be clever and finding ways to do things better without being sufficiently cynical about new trends and fashions. Given that Java is 20 years old, there has been plenty of time for people to find ways of making simple things complicated.
Go will suffer this phenomenon too because it's not to do with the languages themselves, it's to do with programmers who have safe corporate jobs finding ways to make themselves stand out from the pack by inventing and spreading 'best practices'. If anything, Go will suffer it worse, because the language itself is so limited, so there's more potential for bizarre hacks disguised as cleverness. Like that Go profiler that worked by rewriting source code to insert stuff between every single line of code.
Non-idiomatic Go (or as you call it "bizarre hacks disguised as cleverness") is frowned upon. One example that comes to mind is the Martini web framework[1], which, once pointed out, resulted in a rewrite[2].
[1] https://github.com/go-martini/martini [2] https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martin...
What is the alternative to it?
I find this hypothesis questionable. It's likely that language "power" in the real world looks more like a loosely-ordered graph, with plenty of bidirectionals tagged with things like "If you are doing lots of matrix algebra" or "If you need the thing to run on a Raspberry Pi." Go solves a specific domain I operate in (data structure transformation and web services) really quite well---well enough that I can move from making the problem fit the language to solving the problem with small amounts of work, without worrying that I'll create a testing nightmare for myself in the future.
When I find a task too big for Go, I'll amend my feelings on the issue.
Mind you, having an architecture in mind is of primary importance, but dealing with such complexity and endless Factories made it impossible to follow the code.
And yes, I know that server-side implementations have an inherent complexity that most client-side apps lack.
I am sure that as you work your way up the Objective-C chain, you will run into patterns and practices that have brought the best results over the years. They will feel burdensome after a while. At that point, you will be right back where you were with C#, except in Objective-C and will be happy to be a beginner at another language so that you are free of the burden of experience.
(Though yet many teams didn't adopt Go. Because if none of your teammembers has Go readability then you have to rely on someone in Go team to do CRs. Those guys are not very pleasant to deal with.)
I got Go readability more than 2 years ago, right before I left Google, but in my experience the Go team was very pleasant & professional. Has that changed?
But the general point does stand: languages have different strengths, and that's totally okay.
I think that's the issue. For many things, that is perfectly fine. But for other stuff (finance, healthcare, safety critical, anything that loses real money/lives when it breaks), the last thing I want is somebody to just "hack on to it".
Anything that evolves over time requires changes. All of the examples you give (finance, healthcare, safety, money/lives matter) are better served with people being able to read and maintain that code.
Python is not a language I would trust in healthcare, finance, etc. on the critical path of consuming and transforming user-supplied data. Go I'd be comfortable with.
> It's often been said that Go solves the problems Google developers have, and
> it's 110% true.
And still, Java is almost used for front end only. When memory is not enough, you have to use C++.
Once I got over the initial learning curve and started to get the nuances I really enjoy working in the language. So much so I've started looking around for a full time Go position.
The rest of the article is little better. It can be summed up in one line: People who dislike Go are upset because they incorporated their favourite programming language into their identity, and the success of Go challenges their own choices.
Although I don't hate Go, I also don't like Go much, but it's not because it challenges my identity. I am not a Haskell or Scala programmer. I've used a whole bunch of languages in recent years, none of which are especially clever. I dislike Go because I agree with the criticisms of it and I'm afraid I might end up having to maintain code written in it one day. That wouldn't be much fun.
Fortunately, so far I've been able to avoid maintaining PHP or COBOL so hopefully my luck will hold and I'll be able to dodge Go too.
> I'm afraid I might end up having to maintain code written in it one day
I have similar fears about Ruby. This is also true of many contractor firms where they write beautiful tested code which is designed to work really well right now, but not designed to last (think views rendering database objects).
I think this is a sentiment people need to have when they see something cool or some sort of solution: Will I, in 4 years, want to maintain this? Will some person, in 4 years, curse my name for having written this?
The same can be said of any programming language community, IMHO.
But this part stuck out for me:
> When I first heard about Go, I thought "What? No exceptions? Pass."
Lo about 12-13 years ago I balked at Python's significant whitespace, but I came around. And rust's lack of exceptions, but I'm coming around. I think there's certainly something to be said for "identity" (maybe it makes more sense to describe it as prejudice/bias/context, but whatever).
I haven't given Go a fair eval yet so I can't say much (except I don't "hate" it.)
and:
"I also don't like Go much, but it's not because it challenges my identity"
You are EXACTLY who the article is talking about. One of Go's selling points is maintainability. Go's inherent bias towards maintainability challenges your identity.
Go's users and designers make all sorts of claims about it. As it happens, I've evaluated them and find that I often disagree with them.
For instance, Go projects often don't specify the versions of their dependencies and choose to just clone the code into their own source tree instead - if you're lucky. If you aren't then the project simply depends on whatever is found in the dependencies git master branch. I find this to be poor practice from several perspectives, maintainability amongst them.
The difference between Go and pretty much every other semi-popular language is that Go is very much defined by what it isn't rather than by what it is. In that way, its success is an implicit criticism of other languages much more than the success of any other language would be.
The issue is, do I wish to spend my days debugging code and writing more code, in Go? I used languages with Go's limitations back in the 1990's. I don't want to go back.
Especially in titles, where there is little context.
https://en.wikipedia.org/wiki/Go!_%28programming_language%29
I know there was a bit of news recently about a game engine defeating a top-level human player. Beyond that, however, the notion that "Go" references on Hacker News should default to the board game rather than the programming language is absurd.
[1] https://en.wikipedia.org/wiki/Go!_%28programming_language%29
i had never heard of the go game, before the ai go thing
https://godoc.org/golang.org/x/tools/cmd/goimports
Hook it to your editor's save command and never worry about imports again.
On the other hand, stop leaving unused variables around...
I don't think there's any problem with doing that. I use a linter to stop me committing code that has unused variables in it, and to highlight those kinds of style issues in my editor so I'm aware of them. But for a compiler to refuse to run unpolished code in development is just bad design.
It's as if Go's designers took the hubristic or naive view that all code would, in an ideal world, be typed out perfectly first time, as opposed to being gradually hammered into shape through trial and error. This is worse than a design flaw, it feels like an active imposition.
If someone creates a ML variant with a day-to-day experience as clarified as Go then I will gladly jump on board.
What about F#?
As a side benefit, it's appears to be the top paying tech worldwide ...
http://stackoverflow.com/research/developer-survey-2016#tech...
... as well as one of the most highly regarded languages by those who use it ...
http://stackoverflow.com/research/developer-survey-2016#tech...
Even if you end up not liking it, I'd say it's worth a try.
I think Microsoft Orleans is the most interesting functional language based on .Net http://christophermeiklejohn.com/papers/2015/05/03/orleans.h...
I think Kotlin and (eventually) Swift comes very close, but both have compatibility as a high priority, which complicates the languages a bit. But I'm hoping these languages will be able to serve as gateway drugs into the world of ML-style programming, and that we'll soon see a no-compromise ML-style focusing on the full experience.
What I think Go has done for me, is crystalize a belief I was already leaning towards, which is that a language being productive or fun is a lot less important than standards cutting through the issues that don't matter.
Not arguing about the best way to format code, or which test library to use, or how to share memory across threads is what makes Go valuable. It is implied that the language has to be this bad to achieve that, which is the open question to me.
Using Haskell for similar stuff is more tedious, even if a actual coding is more fun. I can see (and sometimes feel myself) the cognitive dissonance here.
C is decades old. Haskell was designed to help you write correct programs, rather than simplicity of use or productivity (or that's how I'd characterise it).
If you compared Go to C# or Java 8 or Scala, it'd probably look a lot worse. Deployment isn't so difficult that Go has any advantage in my experience: install a JVM on the server, ensure your build system is producing a fat jar, run it. Done.
With Capsule you can even make self-executable JARs that have a little shell script attached. Then you can run the program like any other UNIX app. chmod +x and ./execute it. Fully self contained, and can even update itself automatically.
I don't think the same could be said for say, Scala or F# which offer many of the same paradigms but in a more flexible way though.
I've since moved to using Elixir (erlang) for web app stuff (even some scripts) and I am much happier. I'm not in love with Elixirs syntax, but it's nice and includes meta programming. Elixir is a much more pragmatic language in my opinion. Once you use things like pattern matching (what could be more pragmatic) you can't go back. Raw performance is nothing to write home about but in my use cases elixir does a great job of hitting the sweet spot.
All of those can be structured as processes. All of those can be independently fault tolerant. All of those can be inspected while they are running...in production. Seriously, for HA APIs or web apps it feels like a no brainer.
I just wouldn't us it for things that are CPU bound, like image processing for example. Try implementing something that is a bottleneck in your system in elixir and then throw some data at it and see how it performs.
Elixir + Phoenix is a real treat for web app devs.
No sane story for request contexts. I got tired of waiting for net/http support for x/net/context.
Coercing Go structs into JSON and vice versus was just annoying enough. I felt like I was paying the price (being more explicit) for static typing without a lot of the benefits of other static typed languages.
and this: //go:generate stringer -type=Pill [https://blog.golang.org/generate]
if (simple_condition) {
} else {
}
for (long and stuffed;
expressions;
here)
{
}
if ((complicated ||
multi_line)
&& condition)
{
}
void function()
{
}
By the way, is grandparent kidding about Go enforcing this?
The only language I can think of which enforces curly brace placement is Awk. (And only in its pattern-action pairs):
BEGIN {
function()
{
if (foo)
{
}
}
}
/regex/ { # can't move this curly to next line
action
}Go forces one format. Although you definitely can ignore formatting your code and just compile it. It won't fail.
Now I'm wondering if I've just been successfully trolled.
True for football teams, political parties, games consoles, superhero franchises, religions, food choices, colour schemes, preferred spelling variants, ...
Computer programming languages are our jobs. It's okay to have preferences. I (a full time front-end webdev), think Python is probably the best language out there. But it doesn't define me, because that's just silly.
And job grades, job titles, job seniority, place of education, type of degree, ...
* Go is a language stuck in the 70’s.
* Go ignores 40 years of programming language research.
I tried to use Go and was shocked how they can use it without package manager, without generics, with so brittle concept of channels, with executable comments in code and with so authoritative model of taking decisions about language evolution.
So I still think criticism of Go is valid and authors are still deaf to it.
Go proponents claim it's simple. I'm more inclined to call it simplistic.
And as usual, http://9front.org/who/uriel/
Can you give some background?
http://uriel.cat-v.org/profile
http://plan9.bell-labs.com/wiki/plan9//uriel/index.html
https://en.wikipedia.org/wiki/User:Lost.goblin
https://www.reddit.com/user/uriel
https://news.ycombinator.com/item?id=4654125
https://www.facebook.com/archangel.uriel
The way they differ is mostly in how they approach memory safety, which gives them different performance characteristics.
Rust (which I understand less) seems to be about making a program that does exactly and only what you said, including deterministic memory. The safety is less about a general intent to be safe, and more about guaranteeing invariants that are needed by deterministic memory deallocation. Its natural hunting ground is real time - any program that has to finish things by deadlines.
At the end of the day, there is legitimate criticism of Go, just as there are legitimate advantages of using Go. As an additional fact, Go's core developers (and some users) have repetedly been dismissive of this criticism.
If I like to use soap and analgesics, is that part of my identity or just common sense application of technology?
I personally don't "hate" go. To be honest, I have barely read 20 lines of go ever. But I do not like the idea of a language specifically designed to limit my possibilities. I want to keep seeing "programming" as an art and a creative activity. Not as a factory-like process where there is only one way to do thing, all developers are inter-changeable, etc.
I get why it's interesting for big corpos like Google. I just don't have to like it :)
However, I hate the Go community, which doesn't hesitate to humiliate people trying to use language in unconventional ways (Martini...) and mock people that come with a valid criticism of the language (rigid type system, lack of dynamic linking, package management...).
So good language despite its flaws, horrible community. Now is it useful? It'd be like asking if Python is useful despite its flaws, yet Python has a great community unlike Go.
The author of Martini, Jeremy Saenz, didn't feel humiliated:
https://codegangsta.io/blog/2014/05/19/my-thoughts-on-martin...
> lack of dynamic linking
You can build and link shared libraries since Go 1.5:
https://golang.org/doc/go1.5#link
> package management
The Go team is listening to the community about package management and is even willing to make changes:
https://docs.google.com/document/d/1Bz5-UB7g2uPBdOx-rw5t9MxJ...
I agree that Go is a conservative engineering project, which can explain some answers you read on Go mailing lists, but I think you mischaracterize the community.
I would add that I'm tired of people repeating that the Go core team is stubborn and doesn't listen to critics about the lack of generics, even though they have provided substantiated answer on this topic:
https://news.ycombinator.com/item?id=9622417
I'm wondering who is not listening to who?
That was not my point and you know it. you can't load shared library at runtime with Go. Like you can do in most languages out there.
> The author of Martini, Jeremy Saenz, didn't feel humiliated:
Yeah, he didn't feel humiliated so much he stopped writing about and programming in Go and interacting with the Go community all together because it's full of bullies.
> The Go team is listening to the community about package management and is even willing to make changes:
The Go team is listening to nothing.
> I would add that I'm tired of people repeating that the Go core team is stubborn and doesn't listen to critics about the lack of generics, even though they have provided substantiated answer on this topic:
That doesn't make them more open to changes, anybody can do an AMA for PR.
Go community is blind to its own shortcomings and the language issues, you just proved my point yet again.
Everyone hates Go because it solves the problems that most other languages suffer from. And if they (Google) make a few improvements it would probably the The Killer Language of Choice out there. But instead they suffer from the elite smugness and won't adapt.
But I just can't stand the "the go way!" people who defend every fault the language itself has with this mantra. I use go sparingly for small scripts and little services, but would never ever use it for big projects. Yes, for programming rookies in a team its very easy to get started to make valuable contributions, but I for myself just want a more adult language with rich expressiveness and actual static typing (interface{} vs. generics sigh). I understand Go as a "compiled PHP" with all the pros/cons one would associate, and accept that it aims to be a "C as it should be".
I do not hate Go in any way, I use it when appropriate.
(PS: I recently realized for myself that Rust will be the ultimate game changer, just give it a few months/years to grow mindshare organically. It's everything but a beginner language, though.)
I would suggest that this is short-sighted. After all, the end product is created by the developer. Making the developer's life easier and end product quality are not contradictory goals.
Here's the summary: (leaving out some smaller arguments i.e. scala/rust vs Go language philosophy)
1. Go challenges peoples identity.
2. Challenging peoples identity makes them respond emotionaly not logicaly.
3. Other people are being deceived into liking Go.
4. People become more vocal as they attempt to sway the deceived from their erroneous path.
5. (conclusion): Therefore, everyone criticizes Go so much.
Notice all the premises could be true, but they would not strongly imply the "so much" part i.e. "a lot". It would just mean some people would respond more vocally/emotionaly, certainly not everyone.
Anyway, I think there's still some missing premise(s) which would explain why there is "a lot of" criticism for Go, if that is the case - I have no idea as I'm not involved with Go at all.
Anyone care to fill those in for me?
But, I think the main point of the article is that Go's complete 180 on many things challenges the beliefs of some and hence their identity. We see it every time a discussion on Go pops up.
Good things are multiple return values, lack of semicolon, optional braces for if and for, insanely fast compile time.
Bad things are forced curly brace style, complicated function declaration syntax, variable declaration which is too different from C in my opinion (type after the variable name).
I'd honestly prefer a language which is even closer to C or C++ in its syntax, with native maps, sets, queues, tuples, etc (pythonic stuff) without necessarily having templates or inheritance. I put a lot of value in syntactic sugar over overblown abstract stuff. Using plain struct with data oriented programming will be more than enough in most of the cases.
We are still waiting for C++ modules, which obviously might be lagging because C++ has an ISO standard and a lot of existing code which involves backward compatibility, but I think we need a new language that could be faster to compile, just like go is.
Given that some level of type inference seems to be the future of strongly typed languages, I expect variable ahead of type to become more and more popular among language designers.
I think tooling really makes the difference in this case.
What little object-level substance is to this post is laughable. Basically: since Go doesn't have modern language features but it's evidently popular and works, all the people who like modern features are upset since it turns out the modern features aren't needed, after all. Half irrelevant, half assertion out of blue air.
The basic argument of the article is that "People who dislike Go are upset because they incorporated their favourite programming language into their identity, and the success of Go challenges their own choices".
That can be summed up as "People who dislike Go do so because they have been hurt psychologically".
Apart from being disrespectful to the community of other languages, this basically makes it impossible to give a counter-argument: Whatever kind of argument you bring, in the end you would simply add support to the author's theory because, in fact, you have been trying to criticise the language, so you must be hurt. I don't see how that contributes to a fruitful discussion.
Some of this stuff is quite a bit older than 40 years. That only brings us back to 1976. Exceptions are around mid 1960's or so (PL/I, Lisp). Functional programming, Lisp again, 1958. (Java-like) OOP Classes? At least as far back as Simula-67. Simula-67 is where C++ gets "virtual" from.
def dislike(hype, results, community, usage): ...
Other hyped technology is/was node.js. I've heard people say crazy things about, it is the best technology, everyone should drop everything and join the winning team etc etc, async programming is the future and if you are still using threads you are stuck in the past and so on. So it was hyped quite a bit. And then it would have been ok, if it actually delivered, if packages weren't broken and half-assed, if servers under load actually didn't crash and so on. If people who used it where a bit more mature, if there wasn't drama at every step and so on. So it ended up disliked quite a bit.
PostgreSQL is hyped, people are saying this is the end and all database and so on. But it is not disliked, and the reason is it actually delivers results. It handles JSON blobs, it does other things right, it doesn't catch on fire, doesn't throw your data to /dev/null. So it not disliked.
As for Go, I haven't used Go, so I don't have much of a comment, but noticed an interesting nuance with how some technologies just happen to be disliked while others, even if hyped are ok.
I'm also a Googler. Rather than inventing Go, if Google instead would have made OCaml its "Go", the world would be a better place than it is today. If the same tooling were built around OCaml, with some problems of its implementation fixed (multicore/parallelism, etc), there would be no complaints.
Every language sucks at something. Switching from Ruby/Python to Golang feels like losing magic powers, yes, but some problems are better tackled without that magic and type safety comes as a plus.
Ruby/Python/C/Java/Scala/Erlang/Elixir/JS/Haskell/Lisp/Clojure/Rust all have different niches. We should really get over it.
> The mere existence of Go says “your views on what makes a good programming language are wrong”.
As someone that dislikes Go, that's not it. It's because Go doesn't "own" the fact that it thrown language research out the window.
If Go advocates waved their imperative programming flag proudly I would just ignore the language completely.
But one of the things it does have is users. It's almost like language popularity is strangely orthogonal to that laundry-list of ideas that the language theory community have invested a great deal of time in. I'd hypothesize that for someone who is excited about those ideas seeing use (and therefore somewhat justifying the time invested in pursuing and polishing them), a language like Go skyrocketing in popularity relative to its age (http://www.infoworld.com/article/2981872/application-develop...) --- a language that looks at decades of PhD thesis work and says "tl;dr we have work to do over here" --- must be downright infuriating.
Well, at least the author saves me the time reading the rest of the article.
I mean, telling C/C++ devs GC is the hit and parametric polymorphism suck? What did they expect...
Don't know if I'm right, but that's the gist I got from all the comments and news about Go.
"People shouldn't like things I dislike." --waaaah
select { case <-time.After(queryTimeLimit): cancel() <-done // wait fmt.Printf("time out") case err :=<- done: if err != nil { panic(err) }
}
// https://github.com/beyondns/gotips/blob/master/tips32.md#17-...
Honestly, it comes across as a language designed by someone only incidentally aware of programming. This isn't an argument, this is the first impression.
At the risk of sounding stupid, and not really having a say in the argument for or against Go, I will say I tried to learn how to program Go on my own by trying to "guess" how to write a program. (A time waster, I had seen code but mainly glossed over it.) The program I tried to write was "Hello, World" and the way I tried to guess was using the Go website's sandbox.
The result: https://play.golang.org/p/oc-cxnjJiI (Best case: https://play.golang.org/p/NJpwhLUPA_)
I'm sure the same thing would happen trying to learn C++ from a compiler's cryptic error messages, but C++ is not Go.
One thing I dislike about Go is the culture or lack-there-of surrounding it. Especially in the canonical Hello World example, which chooses to use Japanese/Chinese language in an unnecessary way. A little presumptuous. Especially since it's used in a one-off sort of way with no explanation.
I also think it's interesting that it's the survivor of the Go and Dart launches, when I never saw the purpose of Go when it was launched, compared to a special set of libraries for C.