Compiled to native binary, garbage collected, no JVM and not object oriented is why I like it.
Very well put. I would also add nice UTF-8 support, easy concurrency and overall simplicity.
Why Go is doomed to succeed
51–60 of 330 posts
Re: Why Go is doomed to succeed
#52> Go won’t let you abstract yourself in the foot. What a brilliant sentence.
Abstraction if necessary but not necessarily abstraction.
Re: Why Go is doomed to succeed
#53Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…
Sure, there is some nice things about the JVM.
However, for me, Java was the first language to get ditched when I got comfortable enough with Go to accomplish similar tasks.
Reasons are many, but Go definitely wins "single native binary" argument. Java has to be installed, and it has different versions that can be installed. Go you simply compile for whatever platform you want, and you literally have a single native binary. No other dependencies need to be installed.
Hot code loading and swapping is neat in Java, but most places I have worked do not have the operational skill to really take advantage of this, and instead compound that against the JVM's slow startup time, which makes it double bad. With Go, you ship a simple binary that starts up very quickly, and so operationally the effect of faster, more seamless deploys are a much better experience.
Re: Why Go is doomed to succeed
#54Whether you like Go or not depends on whether you think of software development as engineering or as craft.
This got downvoted but I think there's more truth here than on much of the rest of the thread, though I might use words other than "engineering" and "craft". I'm fond of saying that Golang isn't a particularly great programming language, but is one of the great programming tools.
Re: Why Go is doomed to succeed
#55This article seems to suggest that Go was designed as a language for large teams. Firstly it was designed as an research project and secondly I don't think it does work for large teams.
The simple type system and lack of genetics makes code verbose. The dependency system seems to require everyone is on the bleeding edge, correct me if I'm wrong. The channel based concurrency is very elegant but appears to be too coarse grained for high performance programs that would otherwise use it.
That said I like the languages simplicity and do think it has it's uses in the world. Just not large team, large project development.
Re: Why Go is doomed to succeed
#56> To understands why Go is the way it is you need to know why it came to exist in the first place: "The goals of the Go project were to eliminate the slowness and clumsiness of software development at Google, and thereby to make the process more productive and scalable. The language was designed by and for people who write—and read and debug and maintain—large software systems. source" The problem with this idea is t…
How is Rust incomplete and too complex (especially "incomplete")? Compiler-enforced-correct manual memory management may not be the right choice for every project, of course, but I think "too complex" is too strong of a way to say that. That implies there was a simpler way Rust could have achieved the same goals, and I've never seen anyone suggest one that works.
It's rather that Rust's standard library and third party library support is incomplete. E.g.:
- last time I checked there was no option to have non-blocking IO which is a pain.
- custom JSON serialization/deserialization from/into custom data structures is extremely painful (for reference, rustc_serialize's Decodable trait).
- thread::scoped leaking destructors under certain conditions. This is more of an example of how a complex language gives rise to complex issues that very are difficult to debug and fix.
This will get better in time obviously but this is the current state of the language. Nonblocking IO in particular is really unfortunate to see in a 1.0 version tag.
Re: Why Go is doomed to succeed
#57Earlier quoted context omitted.
Not the parent, but I've read many comments here on HN from users who feel that if a language doesn't include an HTTP server in the standard library, it's not ready for production work. Ridiculous, of course, but that may be what the parent is referring to.
[deleted]
There's a funny story here about how Rails had to keep some patches around because Heroku users were accidentally using WEBrick in production because of defaults...
Re: Why Go is doomed to succeed
#58Go seems to be attracting a lot of developers from Python, Ruby and Node because Go offers them the easy path to getting started that they place a premium on, combined with speed, but relatively few people from the order-of-magnitude-larger JVM world. Coming from Java I like that there's a very similar language that I can use for command line applications (a JVM sore-spot) or a simple daemon -- both because it doesn'…
Many of the Java monitoring is only critical because of the garbage collection issues with large heaps. Since switching away from Java we don't miss any of the features you've listed. The problem with Java is the mountain of bloated frameworks which have become standard over the last 10+ years - things like Spring, Hibernate etc. which new developers are expected to learn. With Go new developers which join the team aren't saddled with years of legacy frameworks which are expected as standard knowledge. The JVM is a great platform, but Java the language and to a greater extent its frameworks are a major liability for the future of the JVM. Go and Java (the language) are both incredibly boring to program in (a good thing in if you have developers of varying skill levels), but they are a safe choice with a low bar for learning. Java unfortunately has a mountain of legacy cruft which makes it a pretty terrible choice for new hires to ramp up on.
Re: Why Go is doomed to succeed
#59> TL;DR Golang was explicitly engineered to thrive in projects built by large groups of programmers with different skill levels, and there is no larger such group than the open source community. Very true. This article hits the nail on the head. Most people say that they cannot "express" certain things in go, or have to jump through hoops to do it. The point of go is not to create a highly expressive language, but ra…
"explicitly engineered to thrive in projects built by large groups of programmers with different skill levels"
Reminds me of Java. Although, Java gets increasingly complex these days. It also started out without generics.
Re: Why Go is doomed to succeed
#60Earlier quoted context omitted.
Any decent programmer should be able to switch between {C,Java,Go,Python} without too much difficulty. They each have their own differences and learning curve, but as long as a programmer doesn't identify themselves too tightly as a specific language developer (e.g. some people say "I'm a Java programmer", implying they couldn't possibly learn something else) then it's not hard to pick up Go.
If you took "C" out of that list, I'd agree with it.
Yeah, C is probably the hardest to learn in that set.