Some of the smartest engineers I know are not interested in go because they think it solved the wrong problems and prefer rust for something new.
I think with Rust, you are going to have a hard time training someone who has depended on GC for so long that they have to be explicit about the ownership and transfer of ownership of memory and that it's elegant and cool and performant to do so. You are going to have trouble explaining traits and composability and the syntax around it to someone who is used to using more verbose syntax to implement complicated inheritance trees. Pattern matching and enums are fantastic, but also foreign to most of the programming public.
This is why Go is spreading - good middle ground for productivity and performance, easy to pick up, seemingly bright future, Google backing, good documentation (no doc is perfect - Sphinx is frequently not great, Javadoc is terrible, Doxygen is meh, MSDN is overgrown with cruft - but Godoc is decent), etc.
[1] https://github.com/go-lang-plugin-org/go-lang-idea-plugin/co...
Those guys are doing an awesome job.
There is not yet a need for a Go-specific IDE by JetBrain.
I was aware that the plugin didn't support for a long time the new Go structure. But with the overall refactoring it works now perfect.
I do use a few of the Go scripts (https://github.com/robmccoll/dotfiles). There are some really nice ones (continuous build, syntax checking, continuous testing, etc), but most of what I work on has longer build times due to linking in a good bit of C.
I disagree on all points.
1. The similar performance to Java is usually in small benchmarks. Once the program grows, the difference in quality of the GC and code generation starts to show (in favor of Java, of course).
2. Less code? I've seen Go programs in the wild that are indeed shorter than their Java counterparts, but that's almost invariably because the Go code is less "careful" (less attention to error handling, logging, monitoring, maintainability etc.) But when you compare programs that actually do the same thing, I find that the code size is similar, with Go winning fewer characters and Java 8 fewer lines.
3. Interoperability is, IMO, much better in Java, where you can interoperate with both C as well as JVM languages (including JVM ports of Python, Ruby and R); for Go it's just C.
4. As to the standard library -- especially when it comes to concurrent data structures -- there are few if any languages out there with implementations of as high a quality as Java, and the difference between the variety and quality of available third-party libraries is beyond comparison.
All in all, I find Go and Java to be quite similar, and the choice between them boils down to the runtime. I reach for Go when I need small command-line programs where JVM warmup is unacceptable and static linking to a native executable is a plus, and Java for long-running, "important" server apps, where top performance and deep monitoring (and sometimes hot code swapping) are necessary.
But I have to disagree on performance. What kills Java performance is memory consumption and the way memory is laid out. It has always been the number one killer. It killed Applets. It killed Java on the desktop. And it makes Java a bad choice for most server side infrastructure. I predict that Go is going to wipe out Java for that latter kind of task within 5 years if not less.
Memory consumption is what constrains performance for most tasks. That's why most benchmarks are entirely irrelevant.
Java's creators made two huge mistakes:
1) Throwing out structured value types, which is the root cause for Java's insatiable appetite for memory. 20 years of garbage collection research were unable to compensate for the damage done by not having structured value types.
2) Throwing out so many (supposedly too complex and too dangerous) meta programming features that everything meta had to be built around the language. Trading complexity at the language level for a much more unsound form of complexity on the runtime and tooling side is what caused the J2EE disaster.
Go's creators avoided the first mistake but they are busy repeating the second one with even greater determination.
- Oberon
- Oberon-2
- Active Oberon
- Component Pascal
- Modula-3
All with GC, value types, generics (just Modula-3), system programming capabilities and compilation to native code in their reference toolchain (Oberon variants also had JITs).
But now we have Java, with large installed bases, very mature tools, and latest by Java 10 that mistake might be fixed.
Now, I don't know exactly what you mean by memory consumption, but if you mean total memory consumption by the JVM, that's a feature of the GC chosen, which usually trades extra RAM for added performance -- it certainly does not negatively affects performance.
As to point 2, I think that was Java's greatest decision (which Go can't replicate), because the malleability of bytecode afforded by class loaders and agents have made the JVM extremely flexible while at the same time extremely performant. At the language level, annotation processors -- really, AST transformers -- are extremely powerful (see the new pluggable type systems for Java 8) and not easy enough to abuse by under-qualified developers. If you want a more powerful language, the JVM offers quite a wide selection, which is another thing Go cannot do.
Well, I guess I could have also done Structure of Arrays implementation and additionally avoided 'new', but it's not Java anymore at that point, is it? Easier to just write it in another language at that point.
Generic branchy business logic type code is indeed about as fast in C++ as in Java. But that doesn't hold for all types of software.
How fast is Java native floating point math vs. C++/intrinsics? Last I checked, C++/intrinsics seemed to have 2-8x lead. What about sorting? Last I checked C++/intrinsics sort seemed to be about 20-50x faster versus Java.
Some comparison:
http://unriskinsight.blogspot.com/2014/06/fast-functional-go...
Nope. Go and Rust are almost entirely orthogonal in their best use cases.
Go is a langauge for people somewhat comfortable in low level langauges that want to high level things in a somewhat performant way. The older alternative is probably python.
Rust is a language for people moderately comfortable in low level languages that want to do moderately low level things in a complex way. The older alternative is C++.
C is a language for people very comfortable in low level langauges that want to do very low level things. The older alternative is assembly.
I disagree. I think in many (but not all) use cases, Go and Rust are direct competitors. However, they embody a different philosophy. It's New Jersey (worse is better) vs. MIT style all over again.
One can read Gabriel's[1] descriptions of both styles and they map exactly to Go and Rust. Given Go's heritage this is, of course, not surprising.
For me at least, go has mostly taken the role that scripting languages sit in. I surely wouldn't want to write scripts in rust.
What are some of the use cases that you think they share?
For a Pythoner, Go almost solves all my pain points for python, notably the lack of support for real multi-threading so that for long running task we have to turn into processes based 3rd party library like celery/rq with a message queue as intermediate layer, while comes with a relative familiar favor of syntax.
Go is a pragmatic minimalist language, with limited but cohesive set of features that stays at its core. I don't know rust very well, but from what I gather from HN, looks like that it aims to be a more comprehensive solution rather than 'opinionated' one in case of Go.
It's been a long time since I read it, but in Microserfs, the classic "VC" or "Money" guy describes how you can drive around the Valley on a Sunday and predict the success of companies by how many cars there are in the parking lots.
Most conventional wisdom these days is that if you have to work 80-90+ hour mega weeks you're doing it wrong, but I think that the analogy might be that if the team is using an interesting technology stack, there's a higher chance the engineers there are of higher caliber (as they're interested in pushing themselves to use a newer technology.)
Thoughts?
My experience doesn't support this for a few reasons. One of the main reasons is what I alluded to before, the people interested in "interesting" tech stacks are fadish, even if the tech isn't. In 2-3 years, your "interesting" tech stack becomes "uninteresting" or worse, a bad idea. I remember when java was "interesting" then it was php, then python, then ruby on rails, then scala, clojure, haskel, then backbone, then node.js, then angular, then react, then go and rust, then ....