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.
I like Go and was seduced by channels and go routines. But, I found time to learn Rust (still learning really - Rust is an epic and amazingly rewarding to learn!) and have to admit Rust is far and away the most modern, state of the art and most important programming language of our time. Go compiles easily (pay for it later!) and is sponsored by Big-G. Rust doesn't compile easily but when it does there's a lot of guarantees. And, it does concurrency just as well. Apples to oranges really though.
After picking up Rust I feel like Go just offers nothing. Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM. Want something less safe and easier to write in, why not use Python, etc?
You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go.
Go has a couple built-in features that other languages can and will get with library addition. Go is a 1-trick pony I feel sometimes. It's an "in thing" that doesn't serve much of a purpose overall I feel. It looks like C but lets face it, it's nothing like it in terms of performance and never will be. It isn't a replacement for C.
Is it Google looking at the same strategy as Sun/Oracle and Microsoft? Who knows. But, after using it for awhile and letting the glimmer fade, it feels like a regression. Developers, developers, developers!
Go has an well-designed, integrated lightweight thread scheduler. The only popular languages with equivalent lightweight threading systems are Haskell, which takes orders of magnitude longer to master than Go, and Erlang/Elixir, which lack static typing. There's also Clojure with Pulsar, but Clojure lacks statically typed libraries, and the Java equivalent of Pulsar, which is ugly to use compared to goroutines as it's not a built-in language feature and Java syntax can't easily be extended like Clojure's.
Rust has libgreen, but it is extremely underdeveloped compared to the schedulers/runtimes mentioned above. For developers interested in static typing, lightweight CSP-style threads and ease of learning, Go hence currently represents a much better choice than Rust.
From what I've seen over the last 10 or so years programming in both static (C++,Java,C#) and dynamic languages (Erlang, Python) things like "I got a string but expected an int" are pretty low on the list of what fails or brings a project down. Especially when it comes to distributed systems, thing like netsplits, logic and timing errors, mis-configuration, capacity overload are much more serious things.
Now you can argue static typing means really fast speed. And it is generally true. But lately with v8, PyPy and other such things that lines gets a bit blurry.
In my experience - also using both static (C++, Java, Go, Sawzall) and dynamic (PHP, Python, Javascript) languages - I don't get type errors either. However, what actually brings dynamic languages down in larger systems is the time spent tracing through code to figure out what the actual type of the variable is, and hence what you can do with it. When a script is small this is negligible, but when you've got large teams and hundreds of source files, you can spend 10x the time doing this than actually coding.
I view static typing as essential to larger projects, but for documentation reasons, not performance. The performance and error-checking is a nice boon, but you can recover the former with smart VMs and the latter with unit tests. The documentation can only be recovered by writing your types out in comments, where they won't be checked by the compiler and invariably become out-of-date.
You are right, it would help with documentation, good point.
In general I use integration and unit tests for checking breakage. And of course documentation is in comments but that is not forced. The first set of unit or integration tests also function as "example code". Even when reading documentation I usually gravitate to "examples" section quickly anyway.
I just had smaller components that are rather independent if I can. It depends on the project of course. I guess I've been doing micro-services before they were cool.
It's not initially that it's an issue. Refactoring is where static typing shines.
When you change an anonymous (or otherwise ungreppable) function that's passed around all over from taking a string to an int, it's great to have the compiler tell you that you really did find and fix all calls to the function.
Spot on. Right now if you want to build any kind of highly concurrent server or daemon Go is just so immensely practical and productive.
Channels are very easy to work with and both the scheduler and the large standard library are rock solid.
I used to us Haskell for building these kind of services, and it's awesome as well, but has pretty much the largest learning curve of any somewhat mainstream programming language.
Go, on the other hand, can be picked up in a couple of days by anyone familiar with C.
Rust has the potential to be awesome for these kinda services, but the learning curve will always be much higher than Go and right now the scheduling/standard library is still not comparable.
I think that's an important thing though. Rust doesn't need to have concurrency built into the language like Go. With Go you are using their version of concurrency. With Rust, you can use the standard libraries or find another library that suits your purpose.
So although Go does indeed have a well designed thread scheduler - I may discover after months of development on a project it isn't the thread system I need after all and now I'm stuck with a bunch of code I can't use.
Rust in general is far more underdeveloped than everything you mentioned and yes, right now, Go is probably a better choice - maybe.
Highly unlikely Go will be more performant than the JVM.
Why not? C still beats Java in many cases (e.g. numeric code) thanks to compiler optimisation and I see little reason why (outside garbage collection) Go cannot achieve similar compile time optimisation (in fact, inlining should be easier than in C).
Besides that, Go gives more opportunity for optimisation since it has value types.
Also, in my personal experience (having written a fair share of natural language processing tools in Go and Java), they are approximately in the same ballpark performance-wise. More synthetic benchmarks such as the Computer Language Benchmarks Game seem to confirm this. And there is definitely still more low-hanging fruit in Go optimisation.
Why not use Java or .Net instead of Go?
Because I value the Unix tradition and like small standalone binaries with quick startup time more than dragging around a JVM (although I use Java to for projects)? Because it has value types? Because it is easier to call C from Go? Because I like its profiler more?
Inlining is actually something JITs are really good at... I'm not sure why you think it would be easier in Go than in C, but the relevant angle is the JVM.
Go's value types are hyped up, but they're really not that great. Taking a reference instantly heap-allocates them, C# already has them, and Java is getting them too (in 10).
Calling into C from Go is easier than in Java, but it's not any faster (in fact, it's generally slower, because you can't call into it without switching away from one of Go's tiny stacks into one that the C expects). One of the unfortunate consequences of this is that optimizing a hot loop by calling out to C doesn't work nearly as well in Go as it does in many other languages.
As far as general points about AOT compilation: many don't apply to go compile simply because it will not waste the time to actually perform those optimizations, because it is very focused on its goal of compilation speed. gccgo, sure.
I'm going to try and not come off as frustrated, but as someone who really enjoys and sees a place for both languages, I'm getting a little tired of the rust vs go zero-sum game thing here on HN. And at least you end your first paragraph with the acknowledgment that it's really "Apples to oranges really though." But -- since you did write that paragraph I'm going to address your points.
> Rust is an epic and amazingly rewarding to learn
I liked learning it too because it filled a pain point I've been feeling for years when it comes to systems programming. Can you specifically explain a bit why its "epic" and "amazingly rewarding" to learn?
> Rust is far and away the most modern, state of the art and most important programming language of our time
Holy guacamole that's quite the assertion by someone who, by their own admission, is still learning the language, how do you feel qualified to make such a ... well.. hyperbolic statement?
> Go compiles easily (pay for it later!)
By easily, I assume you mean quickly. How do you pay for it later?
> there's a lot of guarantees
Like what?
> After picking up Rust I feel like Go just offers nothing.
Why?
> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM.
It already is, in some ways. Can you be more specific?
> Want something less safe and easier to write in, why not use Python, etc?
Go is less safe than rust?
> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go.
Why do you personally think that? For example, I'd say that Rust gives you more control over memory. And has smaller binary sizes. But still, I've been frustrated by the overall size of binaries in both languages. Go in particular makes embedded programming near impossible (I was hoping to write software for my MIPS router in Go but was unhappy to discovery a nearly 12 MB binary file)
>Go has a couple built-in features that other languages can and will get with library addition. Go is a 1-trick pony I feel sometimes. It's an "in thing" that doesn't serve much of a purpose overall I feel. It looks like C but lets face it, it's nothing like it in terms of performance and never will be. It isn't a replacement for C.
Why do you get the impression that is Go's purpose?
> Is it Google looking at the same strategy as Sun/Oracle and Microsoft? Who knows.
Don't let copsarebastards phase you. They seriously hate golang as is obvious from their prolific ranting about its deficiencies in many a thread. I really wish they would just let it go, but some people really obsess over how "right" they are in their thinking. It is myopic really. Golang is a wonderful language (even without generics) :) It is the first language I have ever enjoyed writing concurrent code.
I'm not the person you're responding to, but I agree with most of what they said, and here's how I would respond to what you're asking:
>> Go compiles easily (pay for it later!)
> By easily, I assume you mean quickly. How do you pay for it later?
I think they actually meant easily, not quickly, in the sense that the type system doesn't require a lot from the user. However, you pay for that later when your codebase becomes larger and you start experiencing bugs that could have been caught by a more sophisticated type system.
>> Rust doesn't compile easily but when it does there's a lot of guarantees.
> Like what?
Rust guarantees a number of kinds of memory safety. It's important to note that this is in comparison to C, not to Go (Go actually has stronger guarantees because of GC, I think). But Rust's strong typing also catches a lot of kinds of bugs that are hard to quantify mathematically but are pretty apparent to anyone who has worked in both strongly and weakly typed languages. I wouldn't call these "guarantees" but I would say that I'm definitely more confident in strongly-typed code than in weakly-typed code.
>> After picking up Rust I feel like Go just offers nothing.
> Why?
Because after using both languages, he hasn't found anything that Go offers. What exactly do you think Go offers that isn't available in other languages?
>> Why not use Java or .Net instead of Go? Highly unlikely Go will be more performant than the JVM.
> It already is, in some ways. Can you be more specific?
For general use cases, the JVM has years of tuning behind it. You can't get more specific than that, as obviously there are some use cases where Go might shine. But as projects grow large, many use cases come out and it's highly unlikely that an arbitrary project will just happen to only have use cases that favor a new language without years of performance tuning behind it, especially when the designers of that new language shows no interest in looking at the last few decades of language research.
>> Want something less safe and easier to write in, why not use Python, etc?
> Go is less safe than rust?
Absolutely. Go's type system is decades behind. C++ has a stronger type system. Rust's, meanwhile, is extremely sophisticated, using ideas from strongly typed functional languages. There are some cases where compromises were made to allow low-level memory access which might allow some bugs which aren't likely in Go, but those are calculated compromises. Go's type system offers neither the safety of a modern statically-typed language nor the flexibility of a modern dynamically-typed language. Go's type system is just pitiful.
>> You can't write real time systems in Go and you never will be able to. You probably shouldn't write "systems" programs in Go.
> Why do you personally think that?
Because GC simply isn't to the point where it can be used for real-time programming, and systems-level access often is just easier to do with manual memory management.
>> it feels like a regression
> From what? Why?
From any other major recent language, because it offers no new innovations and actively doesn't include ones that have proven effective elsewhere.
>>> For general use cases, the JVM has years of tuning behind it.
Much like that Camaro in my cousin's front lawn. The JVM has years of tuning behind it because nobody can make it work. It is so awful that there exist genetic algorithms[1] just to try to set all the GC parameters to something with good throughput and minimal pausing. Meanwhile, the number of times I've been paged in the middle of the night because my Go server's new-gen permanent eden survivor ratio was critically low has been exactly zero.
The number of times I've been paged in the middle of the night because my Java server had any issue caused by the JVM's configuration has been exactly zero, too. Basic configurations for both the JVM and Go are adequate for 99.99% of projects. You haven't run into problems in Go for the same reason that you wouldn't run into problems on the JVM--you're not writing 0.01% use cases.
According to Oracle, 3 billion devices run Java. That means that a JVM problem which occurs on 1 in 10,000 devices occurs on 300,000 devices. An obscure problem in the JVM can affect more devices than you'll probably ever write code for.
The other 0.01% of projects probably just don't exist yet for Go. If people start using Go on the same frequency, variety, and scale as they use the JVM, I'm quite certain that problems will arise which will require tools like groningen to solve. It's ridiculous to compare JVM tuning complexity with Go tuning complexity when Go hasn't been applied to a fraction of the problems that the JVM has.
Basic configurations for both the JVM and Go are adequate for 99.99% of projects.
No! The standard Java maximum heap size is often not adequate for projects, and you have to find a sane value rather than letting your operating system do memory management.
I said "basic configurations", not "default configurations".
I will say that I have run into this issue twice. In both cases, the solution was to eliminate fix code that were flooding the heap with unnecessary allocations.
There are certainly cases where you would want to increase the heap size, but those really are 0.01% use cases. More often than not, you should fix the code that's using so much memory. If your criticism of the JVM is that you wrote shitty code and your shitty fix for your shitty code was to configure the JVM, I'm not feeling a lot of sympathy for you. If that's the case, go be happy with Go, by all means. And if your use case really was one of the cases where increasing the heap size makes sense: well, that kind of project is going to cause issues for Go, too. Just because it silently allows you to pile your heap into the stratosphere doesn't mean it's going to deal well with your larger heap size. In fact, given that it's parallel mark-and-sweep (and not generational) you're almost guaranteed to have performance issues in larger heaps--it's geared toward low overhead and performance on smaller heaps.
As an aside: Azul systems produces a really cool JVM implementation called Zing that does some amazing stuff with pauseless GC. Worth checking out for anyone interested in GC implementation.
especially when the designers of that new language shows no interest in looking at the last few decades of language research.
Since this is Hacker News, it's very likely that you are typing this on a machine running either an OS that is directly based on 60/70ies OS design (Linux) or a dead-end in 80ies microkernel research (Mach). Still, Unix powers a large number of devices and is popular among hackers. Unices may be less principled than their later peers, but people appreciate the trade-off between architectural principles (composability, everything is a file) and pragmatism in the form of 'worse is better'.
Go's developers are probably aware of most research in PL design. Go supports structural typing after all (OCaml and C++ via templates being the only other major languages to support it), and has CSP (yes, I know that's 78-85 research). But besides that, in line with its UNIX/C/Plan 9 heritage, Go is relentlessly pragmatic, choosing simplicity over abstraction power.
Evidently, Go has hit a sweet spot for many people, because Go already has big success stories (from Docker to Juju), which is impressive given it's short lifespan.
I don't think Go's developers are aware of "most" research in PL design. But that's true of most languages, really, there are a billion papers to read. I think people are frustrated by what research they chose to ignore, though... anyway, saying that OCaml and C++ are the only major languages to support structural typing is a bit silly, since a lot of other languages that are probably more popular than OCaml have it (like F# and Scala). And Go's variant of structural typing is pretty limited.
I think Go's unique selling point is: it's the anti-LISP, the programming language that isn't particularly programmable and you don't miss it, because the built-ins are sufficient. As a result, code in Go tends to be far more about solving the problem than is the norm; in most languages, you'd first be solving the language or replacing the stdlib. Concurrency is an example, yes, but so are the HTTP and the TLS libraries.
Agree. It has message passing with a nice thread model, and the engineering seemed sound when I experimented with Go a few years back, but it lacks everything I need in order to actually program.
I don't really understand what this means. In ALL languages you are going to be spending some time learning, understanding and customising the platform to some extent. Go is no different. I have seen nothing particularly special about Go's standard library apart from having a clean concurrency model.
Another post about Go where the Rust crowd comes out to play. I cannot wait for your language to stabilize so that you will no longer feel the emotional need to bash on golang :)
Moderator of /r/rust and #rust here, I honestly have no idea where these people come from. We have rules against language bashing, so I guess we ended up exiling them all to HN?
I used to be of the same mindset until I tried it. I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this".
I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO
> I still miss generics, but ...not as much. From a "non-starter" it became "I don't love it but I can learn to live with it" to "let's look at creative solutions, perhaps using code generation, to try to solve this".
If you're trying to solve problems caused by your language, maybe the solution is to switch languages.
> I think generics will come, honestly, but not in an easily-recognizable form. The "go generate" is a small step into the direction this will take, IMO
Static code generation is what people tried before templates, which were then improved upon by generics, and that's only looking at mainstream languages--if you're willing to look outside that, there's Hindley-Milner type inference and typeclasses.
The rest of the language design world went down this path decades ago and already made the mistakes Go is making and learned from them. `go generate` is a fucking terrible idea. People aren't saying this because they're afraid of change, they're saying it because they've seen it before. We know how the story ends and it's not a happy ending. The fact that Go's designers can't be bothered to read the book only goes to show that they shouldn't be designing a language, and Go's popularity is only due to a combination of ignorance and hype.
No. `go generate` is great for what it was invented for:
Programs that write programs are therefore important elements in software engineering, but programs like Yacc that produce source code need to be integrated into the build process so their output can be compiled. When an external build tool like Make is being used, this is usually easy to do. But in Go, whose go tool gets all necessary build information from the Go source, there is a problem. There is simply no mechanism to run Yacc from the go tool alone.
I was responding to `go generate` as a subsitute for generics because that's what PopsiclePete was proposing.
But while we're at it, `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research. C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language. You could go even farther and look into combinator parsers.
Yet again Go ignores decades of programming language research.
> `go generate` as a substitute for lexer/parser generators is another example of Go being decades behind programming language research.
Nobody wrote that `go generate` is a substitue for lexer/parser generators. `go generate` is just a mechanism to automate the execution of the generator, as explained by the comment you replied to.
Repeating ad nauseum that Go is "decades behind programming language research" is not enough to make your point :-)
> C# and clang have both innovated a lot in this space by writing sophisticated functional parsers by hand using libraries which in C#s case is then exposed in the language.
It's exposed through Roslyn (I was technically wrong in that it's not included in the language, but in Visual Studio). It's not very well-documented (to give you some idea of how not well-documented it is, some of the most useful documentation is in a Word file[1]). The code is Open Source[2].
I found out about Roslyn through hearing Erik Meijer speak at a conference. A quick search shows that the content of his talk at the conference I went to is probably covered in his C9 lectures[3], probably in Chapter 8[4]. But I'm pretty sure that will only cover the parser combinators, which is the algorithm, but not the specifics, of how C# is parsed.
When I was doing C# parsing I was working with the CodeDom[5]. If you just need the AST I think ExpressionTrees[6] are now the idiomatic way to generate it, but I'm not sure how that relates to Roslyn.
Disclaimer: My day-to-day development switched over to primarily C/Python/JS about a year and a half ago, so it's been a while since I fired up Visual Studio. My knowledge is probably out of date, and might be flat wrong--nobody's memory is great after a year and a half.
The "go generate" is a small step into the direction this will take, IMO
It's not. The problem is the number of possible types you want to instantiate a generic type or function over is potentially infinite.
If I write say a binary search tree package, I can only use 'go generate' to generate instantiations for a finite number of types. If a user of my package need a binary search tree of another type, touch luck. The best they can do is use interface{} or start 'go generating' in their own projects.
'go generate' is great for generating code using yacc or Ragel, but it's not a solution to the lack of generics.
Like I said, it's a "small step". It's in the quote you quoted in fact. A small step, that's all. There's go generate now, maybe somebody will write "go super-duper-generate" later. All I'm saying is, if "generics" come to Go, it will be through a tool like "go super-duper-generate-v2.0-apples", not syntax. That's all.
I mean, we did this. It was called CFront. Now we have C++ templates that are probably Turing-complete and we use them to create things like Boost. Regardless of howyou feel about compile-time metaprogramming like Boost, Go exists as a direct reaction to its complexity, and that's exactly where go generate will take it.
In the other hand, it helps prevent people to build needlessly complex abstractions. That's what I like about go: relatively straight-forward code to read in most project that I have seen.
agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang without all these abstractions and "elegant" ways to do things. (than some languages like java)
yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity.
at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.
agree. when it's 3:42am and you get called in to debug something in a production system in the middle of the night, it's a hell of a lot quicker to visually and mentally parse and digest golang
You think this that functions returning interface{} are easier to debug than functions that return a specific type? Because that's exactly what you are throwing away with generics.
Allowing specification of the element type of a container data structure is not unnecessary abstraction, it's type safety!
while that's an example that I do see in the wild, not every function returns interface. but it doesn't really hurt my argument.
if I have a function that returns an interface I can grep who is calling it and probably digest what it is within a few moments and probably 2 or 3 files of code.
with java I find its so once you get through the factories, abstractions, and more, I have never found what I'm looking for in 2-3 files until I am more intimate with the code base.
Not in a container, where generics are typically used. Of course, blah could be an interface requiring a comparison or hash method, but the effective result is the same: you have to do reflection to find out what is in the container, there are no compile-time guarantees.
Amusing that you talk about production support considering Go is by comparison a bit of a joke compared to the JVM. I can get detailed remote metrics through JMX and introspect running code with Java Agent tools like New Relic or AppDynamics.
I completely get what you mean about Go being simplistic and easier to reason than your typical J2EE app. But remember you don't have to write your Java apps that way. Unfortunately "design patterns" took off a decade ago and ended up dragging Java and many other languages into the complexity quicksand.
I hope Go learns from these lessons as it matures.
"you don't have to write you apps this way" , but that's the point in making , is that the culture and parts surrounding Java, which I end up having to support and debug as part of the job, I don't get to use my time machine to go back and fix it.
I'm intimately familiar with the jvm and app dynamics and they do have wonderful tooling.
but, without that tooling I would be really paddling upstream.
call me old fashioned but I like simple tools, and golang I can profile faster and find bugs sooner. I have supported critical infrastructure on both platforms ( Java for many years , golang for 2) and it is not a hard choice to make for me, even with app dynamics and similar tools.
Yeah I have to second this, a lot of people are really off the mark about how "useful" their abstract solutions to a problem are. Often something is very over-engineered. Once you have to build anything complex on that type of foundation, well, good luck to you!
Besides from what I understand the lack of generics is mostly about compile time speed. I love how fast go compiles and would rather that not change.
Templates are slow to compile, most modular parametric polymorphism solutions are pretty fast (C#, Java). Barring Scala...but to be fair they have a lot of other things going on in their type system!
I think it is worth the time to figure out how to do generic code better than it is currently done with parametric polymorphism and templates. And yes, I think going simple on the type system is a valid direction (vs. Scala which focuses on power and expressiveness).
But I don't buy the argument that we don't need them, and that we will necessarily write worse code with them.
I found Go extremely difficult to build abstractions in when I did some work in it last year. I would actually rather write Java (speaking as a Lisper). :-)
Yeah, it does kind of suck to write "generic" data structures/algorithms in. Rob Pike has a funny git commit where he implemented general map/reduce in Go using reflection, immediately followed by the comment "don't do this, ever".
For some reason, the core Go team has no need to write general algorithms/data structures. They just...write the code when they need to.
It's a strange way to think about programming, but for me, it can work. You focus on the "executable", not the "library" (I know that sounds strange...)
For all the people complaining about both (the lack of) generics and high performance systems level programming, this and his allies in the video game industry such as Mike Acton
argue that performance and the focusing on the problem you are trying to solve are intimately related. Needless levels of abstraction (particularly ones that go against the hardware) and generically trying to solve for cases you will never actually use is a waste of real performance and developer time.
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.