This quote: "Russ: The most important thing I learned is that a successful programming language is about far more than the language itself."
and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust.
Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it.
The core language might not be super-exciting, and it might not be as fast as others, as elegant as others, as "powerful" as others, as feature-rich as others, but the overall experience is very, very pleasant.
Admittedly I'm a new programmer, but learning Go has taught me far more than just Go.
For me, Go seemed very low level -- I mean, it even had pointers! But then I tried to rewrite some GNU utilities in Go (still not sure _why_) and I had to translate C to Go, which flipped my world upside down.
Simply because Go was easy enough for me to write as a beginner but close enough to the hardware for me to want to explore, I've learned a lot about the Linux kernel, C, GNU, programming best practices, and so on.
And the best part is everybody is do damn friendly. If I'd ask a dumb question about Go I'd get a friendly response, along with RTFM. With C? Usually just RTFM.
Robert, Rob, and Ken did a fine job. (Along with Brad, Russ, et al.)
I haven't done anything big in Go yet, but I loved that in their tutorial they talk in depth about the design choices they made for the language. It really feels like a language that was designed with a purpose, and they are a little obsessive about keeping it pure, not letting it get bloated with features, which suits it nicely.
On a side note, why does every discussion about Go seem to turn immediately into a comparison/argument between Go and Rust? I'm not an expert in either language, but I don't see why the two languages can't coexist.
If you were an expert in either language, you also wouldn't see why the two languages couldn't coexist. Outside of some nebulous sense that both languages are aimed at "systems programming," and the fact that neither of them existed ten years ago, I have yet to read a convincing explanation of why they have more in common than, say, OCaml and Fortran. We clearly need more OCaml-Fortran comparisons. Or hell, let's do some Rust-Fortran comparisons, at least those might be mildly entertaining like the Go-Algol one.
Your concept of pleasant / your uses of Go must drastically diverge from mine! :-} I find Go to be needlessly obtuse in the language, the configuration, the tools, and the documentation. This is turning into another horror: it used to be that lots of jobs required javascript; now I fear the kool aid is making people push for Go. Note that I have not used Go for the concurrency stuff. Some might say that means I'm not allowed to have an opinion ;-) whereas I think it means I see the crappy foundation more clearly exposed.
Except for how that didn't work for me. Yes, I have a "reverse midas touch" when it comes to technology, but I think that makes me a good UX critic. :-) And even if/when it does work, I detest the whole GOPATH idea. I know the alternatives are not perfect. I know. But still...
Having coded in more than a dozen different languages, I think the Go ecosystem is the easiest I've used - when you look at the entire development and deployment stack.
You're right that GOPATH needs to be set, but is that really any different to having Python, Perl, Ruby, etc JIT's in your PATH env var? And GOPATH is certainly more convenient when it comes to the distribution of program (ie copying the compiled PE / ELF) than having to ensure that you have a Perl et al run time environment (and particularly any required non-standard imports) installed on the destination system.
But Go isn't a JIT / scripting language, so that's probably not a far comparison. So let's compare it to it's closer relatives: C# and Java. Java is just a mess from a UX perspective. It's a mess to install, it's a mess to redistribute. It's just a complete mess compared with Go. C#, however, is a very friendly language to approach as a new developer - if you're writing applications on Windows and for Windows. I will grant you that .NET is open source and cross platform, and that recent reports suggest .NET projects will become more portable in future years, but you still need a Mono runtime on non-Windows platforms. Go compiles it's dependencies into it's binary (hence the size of the binary).
I'm by no means saying Go is perfect, but lots of people have tried to solve the problem you're raising and more often the case is their attempts are less user friendly than Go. Which leads me to think that maybe the minor inconvenience of having to define GOPATH (and it really only needs to be defined once in the entire lifetime of your Go development machine) is a pretty good usability solution.
Last, but certainly not least, the state of the art tooling for Java, the world class GC (and advanced ones like G1), the breadth and depth of its incredible ecosystem, the performance monitoring and extension API, the innovative Quasar library (https://github.com/puniverse/quasar) for concurrency alongside the features and additions in Java 8 pretty much make Java a serious contender for new projects.
If you haven't explored modern Java, I suggest you give it another look.
I haven't, and that's good to hear. But it's still more complicated than Go if just in regards to how you need to be aware of these tools to begin with. Where as Go's behaviour is out-of-the-box.
This is purely from a "this is my first language" angle though. So I'm not to say that the aforementioned Java tooling isn't better than Go's, and in many other ways too.
Maybe (or maybe not) you'll find this[0] useful: touch .gopath in some project directory, your GOPATH and PATH will be set automatically upon cding inside.
Then, work straight on the root for simplest projects or prototyping, or inside src for multi-package projects. In any case, deps will go in src, and you can readily vendor them, or use git submodule, or a simple shell script containing a sequence of "git clone", or not at all. No tool like godep, no import rewriting, no global workspace, per project dependencies, zero overhead.
I concur. This is an easy and efficient solution. We do that in my company with one difference: instead of setting the GOPATH depending on the current working directory, we use a Makefile.
... if you want to get fancy and make sure all your binaries are automatically in your path
5. export PATH=$PATH:$GOPATH/bin
... at this point setup is done, to build your first project using an external library
6. go get github.com/<user>/<library>
7. code, code, use <library>, zug, zug... save code in $GOPATH/src/<your_package>
8. go install <your_package>
9. $ <your_package> # runs it
this package can be shared because it is a static binary -- share with your friends, run on other servers, heck -- even cross-compile for other platforms with ease. Working on Linux -- but want to ship a utility to do X for a friend on Windows, no problem!
After using Rust I see no reason why C++ should exist any longer. Maybe in really limited embedded systems.
Rust is so unbelievably safe to use in complex, efficient systems. Rust is, IMO, the state of the art in programming languages.
Once you put the few months into actually getting OK at it you can write really great code, really fast and not be stuck with burdens since the compiler makes you write code that will work.
There are still jobs I have done in the past that would require C today, but they were never suited for C++. Specifically it was work for realtime systems that required a highly trustworthy compiler like CompCert, the likes of which did not (and I believe still does not) exist for C++.
Go was originally designed as C++ replacement to be used at Google but its lack important C++ features lead to little interest from C++ programmers. Pike found much more interest from Ruby/Python programmers.
And Rust is different, since it does incorporate the features that current C++ programmers need (such as GC-free memory management and generics). So I don't see how that refutes the comment you replied to.
I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this.
While apple and oranges is an appropriate metaphor for the approach that the two languages take, Go and Rust are vastly different, their goal of being systems programming languages is not.
The point of objecting to the comparison is that there are lots of important aspects of Rust's design that Go's design doesn't account for, and many C++ developers (for example, me) depend on those. (In my case, those are memory safety in parallel mode, GC freedom, data race freedom, fast interop with C code, and zero-overhead generics.) The languages have wildly different designs. So saying "Go is going to beat Rust" like the OP did is pointless cheerleading, and the "apples to oranges" comment is correct to point that out.
A useful thought experiment is: If Rust completely failed to garner any mindshare, could I switch to Go for the project I work on (Servo)? The answer is no: Go's design goals are totally incompatible with the project. C++ would be more appropriate than Go (though it would mean sacrificing many of Rust's advantages, of course). That's why I, and the Rust community as a whole, tend to dislike the comparison. Go is a fantastic language that works really well for lots of use cases, but a C++ replacement for all niches needs a lot of things that Go doesn't have. And this isn't a knock against Go: as I said, Go is a great language for lots of things that could also be written in C++.
> I just wanted to point out that Go was trying to be a C++ replacement. Most people tend to forget this.
I was following Go from the start, and I am aware of this fact. What I was pointing out is that they backed out of this claim eventually (event regretting using the term "systems programming language").
Let me amend that: Go was a replacement for C++ in a context where C++ was considered unfit and unsafe. Therein - I believe - lies the source of the misconception: Go was made to fill a gap that people tried to fill with various languages they had at hand due to lack of a fitting language. It just so happens that C++ was the one used by Google in that case.
IOW, Rust aims to be a C++ replacement while Go aims to be something that didn't really exist previously (at least not at this scale or in its entirety).
That is an excellent comment. I wish I could give you a prize, but all I have right now is a banana. Every time somebody mentions the "C++ replacement" aspect, people freak out because you can't use Go to write Unreal Engine 6 in it.
There was a talk/video somewhere where Pike/Griesemer explained how it all started. They were waiting for some gigantic C++ project to compile on their compile farm and every compile took hours. So during one of these down times, they started shooting ideas back and forth of how to speed up compilation. Then they figured out it's easier to start a new language with simple parsing rules than to fix the mess that is C++ grammar.
That's really it - it started with a pain point about C++ compilation speed, not C++ performance.
I have mixed feelings about this. In one sense, it's actually pretty true that no new language has really been developed with compilation speed as its primary focus for ages. So in that sense I applaud Go for its dedication to that purpose. On the other hand, a language devoted largely to compile speed (and that's really the one unifying principle I've seen in Go's feature set, since I view "simplicity" as essentially arbitrary in a formal sense) might be a cool research language, but I wish Go did make a few concessions for the sake of productivity. There are some really fast ahead-of-time compiling variants of ML, like Poly/ML, and in the spirit of pragmatism I think Go could have settled for "fast enough" compilation instead and used well-known techniques like type erasure to basically get 'interface{} but with static checking' generics.
I would agree with the statement that Go was intended to be used in situations where C++ was not necessary but I think Java or C# would have easily sufficed for these problems.
The problem is that both Java and C# are controlled by Google's competitors (Oracle and Microsoft) which is why Go probably got the green light from management.
"and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust."
Why does every Go posting have to have the same argument about the pros and cons of the language against other languages, and peoples opinions of why they like or dislike go? It's so repetitive.
>I think Go is posed to become dominant over other new languages like Rust.
I agree that complete documentation, good stdlib, intuitive build/package system, and friendly community are part of a language's success. But how does Rust fail at those compared to go, considering it hasn't released 1.0 stable?
Well, not having a stable release at this point could be considered a downside. Clearly there's some ground to steal from C & C++ and some advantage to getting there first.
Just playing devil's advocate here as I am a rust fan.
I started following Go in 2009. It was pretty much "stable" in r59 or whatever they called it, a good 2-3 years before Go 1.0. There were a few breaking changes, a few new keywords, and one package - container/vector - disappeared (since the "append" built-in was added).
So every tutorial, every article, every video, every blog post is still an excellent source of information, 5 years later.
Rust? Anything you read that is more than a week old is basically wrong. Entire language features, syntax, keywords have been ripped and thrown into oblivion - the @ qualifier, the ~ qualifier, the entire i/o library is being rethought...
These aren't bad things. I'm a huge fan of not maintaining infinite backwards compatibility.
But it leaves a strange taste in my mouth. Go was basically "done" in the general sense in early 2010. Rust reinvents itself every 3 months. You could say that the Go authors knew better what they wanted from the get-go, maybe? There's a sense of "they know exactly what they wanted" vs "these guys are shooting in the dark and hoping to hit the bulls-eye" which is kind of the impression Rust leaves me with.
Go made the (pragmatic) decision to go with concurrent garbage collection. This meant they could use very familiar solutions to problems that Rust was struggling with at the time. It also meant that they failed at their initial goal to attract C++ programmers. That doesn't make Go a failure as a language, but I sometimes get the sense that people don't realize just how much Go relies on the GC, or how much of Rust's changing design revolved around its changing relationship with GC. As one example, without GC, Go would likely have had to abandon green threads for performance reasons (the switch away from segmented stacks relies entirely on being able to trace pointers).
I would argue that Go's focus on a small feature set made it easier to get right more quickly. The few Go designers knew what they wanted out of the language. They decided early on that Go would be very opinionated. And they were OK with sacrificing purity for simplicity.
Rust has many more features than Go. (And language complexity increases approximately combinatorially with the number of features.) Features in Rust are decided more democratically. Rust designers are OK with a long (re)discovery period for features to find the purest design.
I believe these differences in language authorship explains the churn that Rust has experienced relative to Go.
> Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it.
One way to put it is that this highlights Go from a user's perspective.
The very same thing is true from the compiler developer's perspective.
I've found that the process of installing dependencies, pulling source, navigating source, building, testing, contributing patches, etc is important for success--as well as the user experience.
I've had bug-fix patches accepted into Clang, GHC, and Rust. I found Rust to be a bit pricklier than Clang and GHC. I'd like to make time to get a similar experience with Go--I suspect it would be good.
I do not want to pick a fight, but how is Rust not doing that?
Check out /r/lang_name subs on Reddit, you will not find many other communities as vibrant (maybe some, but not the majority). Then check out rust_gamedev, dedicated to game programming.
I have not checked out their IRC but excerpts from IRC on /r/rust tells me the community is vibrant on both ends of the hose. They also had like one bad incident on IRC about a gender issue, and they shut that crap down with a strict Code of Conduct imposed everywhere. Whether or not your are into that, I think they take community management very seriously, and regardless of politics, I applaud that.
They have done every single thing about the language through RFCs and discussions of bugs and PRs on Github from almost project inception, where the community drives a lot.
There are very talented people writing tutorials on writing Rust, from tooling, to the Servo web browser experimentation, to http server libraries like Chris Morgan's work, to work on the Piston game dev library.
Granted, I have not checked for videos yet. Others correct me if I am wrong.
I mean, I understand that Go has these things, but maybe I am reading too much into your comment. I just think Rust has a wonderful community, media and all, about what you can do with it.
Rust is nonetheless a work in progress. I am not saying this to be judgemental, but Googlers released Go after work was complete at some stage. Volunteers and a few Mozillans have worked on Rust iteratively, on many iterations and revisions, out in the open. This makes a big difference in perception and how easy it is to get started.
Granted, I have not started with either. But what keeps me interested in Rust, even though it is way out of my comfort zone and I have terrible systems programming knowledge, is exactly about what you describe with Go.
For me, I look Rust more, personally, because of my perception they are willing to try simple, try complicated, but as long as it is a reasoned discussion about language design. And the best part: IF X IN RUST DOES NOT WORK, OUR BAD, WE THROW IT AWAY. I caps that because it is so refreshing to see that. People have complained a lot. Some of the complaints are there, but many redundant or irritating features were removed simply because they were not useful or outlived usefulness. I wish this honest experimentation was more frequent in the industry, but my myopic view, as largely an outsider, is that it is not the norm. (And to be clear, I am not saying Go or language X does not do these things, but observing Rust you see they are briskly paced but willing to make deliberate changes at a pace and keep reviewing the drawing board; I cannot pass judgement on other langs, and this is just my impression.)
> I think the interest in Go has been increasing with or without Google's name tacked on to it, honestly.
> Otherwise, you might as well say that the only interest in Rust is because it's funded by Mozilla?
Of course some interest in Rust is because it's funded by Mozilla, but the difference is the only there.
Go and Rust differ in that Rust actually builds upon the last few decades of programming language research and takes a good shot at solving some real-world problems. It occupies the same space as C/C++ but solves many issues that plague both languages. You could explain Rust's popularity by association with Mozilla, but you could also explain its popularity by the fact that it's actually a pretty interesting, well-designed language.
Meanwhile Go is neither low-level enough to be useful for performance/memory intensive work nor does it provide reasonable features to compete with higher level languages. It solves some very Google-specific problems (compilation time? If compilation time is an issue for you, it's much more probable that you've done something wrong than that you need a faster-compiling language). And to do that it gives up features which make it inappropriate for almost every project (I don't even want to hear about how you don't need generics--if you're creating empty interfaces you should be using a dynamically typed language and if you're using `go generate` you should go back to 1980 and rediscover why type-unaware code generation is fucking terrible idea). Literally every feature in Go is done better in languages that existed before. Go brings literally no innovation to the table (if you say that Go has a new way to do threading my head will explode). And Go doesn't even include most of the innovations of the last few decades of language design. It's literally decades behind. Given that, I can think of no explanation for its popularity except its association with Google. There's simply nothing it has going for it except hype.
Do you have any source for this? I think you will find that people think quite a lot about the user interface to code. For example, this is why in many modern languages principal types are inferred and instance selection is implicit.
Maybe the "Google" part has to do with the fact that the language has some backing and isn't going to disappear overnight because the lone developer decided to abandon it.
p.s. Your hatred of Go is kind of funny to this outsider. I may be just a stupid coder w/o a CS degree but spent a couple of decades in the trenches. Since a superior language would naturally eliminate the puny offerings of Go, I await your wisdom in the language that will save me and other mindless drones from futile coding. Please enlighten me with the language that will save me from this programming plague.
> Maybe the "Google" part has to do with the fact that the language has some backing and isn't going to disappear overnight because the lone developer decided to abandon it.
...which is also true of numerous alternatives to Go.
> p.s. Your hatred of Go is kind of funny to this outsider. I may be just a stupid coder w/o a CS degree but spent a couple of decades in the trenches. Since a superior language would naturally eliminate the puny offerings of Go, I await your wisdom in the language that will save me and other mindless drones from futile coding. Please enlighten me with the language that will save me from this programming plague.
Yes that's very witty.
I don't believe there's one true language--if I have a choice of languages I choose the one I feel is most appropriate to the job.
However, I would like to see the industry move forward. I want to be able to find work with better programming languages. I'd love to see Rust replace C/C++ in spaces where performance, memory, size, etc. are priorities. I'd love to see one of the handful of higher-performance scripting languages that have come about in the last few years gain the maturity and library support that Ruby and Python have. Seeing Go become popular is frustrating because it's a step back, not a step forward. If the industry goes in that direction, it will affect the industry negatively, but it will also affect me negatively. And if you're still working in the industry it will affect you negatively too, so I'm not sure why you think it's funny.
As I said, there's not one true language. If you want my recommendation for what language you should be using you'd have to tell me what problem you're trying to solve.
Yes, it's hard to choose the right language, but Go doesn't solve that. It just throws a shitty tool into the mix.
For the situations where you need moderately high performance but don't need manual memory management (which is where people seem to be using Go) I'd look at Lua or Julia. Both support the same threading model as Go and comparable performance, with the option to optimize in C. But unlike Go, which provides neither the safety of a reasonable static type system nor the convenience of a dynamic type system, they choose dynamic types. They also both have pretty good library support and active communities.
If you want something low-level like C, there really aren't better options. Objective-C is worth considering, but it still has a lot of C baggage. C++ is just far too complicated a language with too many dark corners; I can't really stomach it any more. Rust is still bleeding edge, but it might be worth the risk of having to change code later to use it. Yes, I realize I'm not providing a solid solution here, but let's be clear: neither are you. Go is not a solution to this problem.
If you want something high-level like Python, you really can't do much better than just doing Python. Racket might be worth consideration--I don't have enough experience in it to tell yet. Ruby is okay too. I don't think this space suffers from a lack of solutions. If you need a little more performance you might look at Clojure.
They didn't hype Go either. All "hype" Go has is team members and community members writing blog posts and giving talks. Even the web page is designed by the Go guys themselves.
Can you point me to any evidence that Google ever "hyped" Go ???? Like some kind of company announcement by Larry Paige? What language (any???) has Google every hyped? They hype products, that's it.
Not only that, but there's less than 6 people probably in Google who work "full time" on it. For the vast majority of other Google employees it's a "20%" project. More and more of the pie is being worked on by the community, not the core Google team.
I know you hate Go, I realize that, but other people like it, and it's not because "The Great and Almighty Google" is shoving it down our throats?
I hate PHP with a passion for example, but I don't think there's a vast conspiracy to see it still being pushed around?
> and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust.
Is there some law that says that any top comment on HN that mentions either Rust or Go, a mention of the other is bound to happen in the same sentence? Like some kind of magnetic, rhetorical force. Heh.
If either, or both, Rust or Go succeeds, it will be for widely different reasons. edit: to whoever is adamant about downvoting my questions for today; you forgot the one previous to this one.
I think your comment had enough respect/content not to warrant a downvote. Sorry to see the haters out today, comrade. Rust and Go seem to have the potential for some overlap. But it seems Rust will be successful as a lower level systems language while Go may be easier to maintain when building highly concurrent, networked applications.
and the article linked from that comment is why I think Go is posed to become dominant over other new languages like Rust.
Go's documentation, tutorials, videos, support, community - what forms the ecosystem, basically - is really the reason why I keep coming back to it.
The core language might not be super-exciting, and it might not be as fast as others, as elegant as others, as "powerful" as others, as feature-rich as others, but the overall experience is very, very pleasant.