101–110 of 235 posts
Earlier quoted context omitted.
Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.
>But Go is still a much better choice for getting things done. What makes you say this?
Earlier quoted context omitted.
See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pa…
As I get older and I gain more perspective, I can't stress enough how true this is. Listening to younger programmers bemoan Ruby and Rails is humorous to me because they don't remember the world of Java web dev before Rails. Miles of XML configs everywhere, factories, impls, proxies, beans. So. Much. Boilerplate. It's easy to bitch about things the way they are now, but understand there are people and technologies wh…
Earlier quoted context omitted.
Yeah, that seems weird. A properly implemented mutex is one atomic instruction in the uncontended path to lock and one more to unlock. And if you remove the mutex, you're turning "the contended path" into "the path that blows up your program". Atomic instructions can be painful on, for example, ARM (where they turn into load linked/store conditional loop + memory barrier) but they shouldn't be too bad on x86 servers.…
It is not unprecedented, e.g. see: http://en.wikipedia.org/wiki/Crash-only_software Martin Rinard at MIT has done a lot of work in this area. It can be safe if you can rollback to a good state to avoid data corruption. Glitch, my current project, does not bother with reader locks for multi-core execution; instead it can rollback and retry when a write-after-read is detected effects are logged (dependencies are traced…
Earlier quoted context omitted.
Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones. Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes se…
Adrian Cockcroft does and I don't disrespect his opinion even though I'd far rather functional languages won the developer mindshare myself. We shouldn't be under-selling how light the Go footprint is. In the long run it may be one of the few languages to compete with unikernels.
Can you please clarify what this means? I don't really understand what it would mean for a language to compete with a unikernel.
Earlier quoted context omitted.
Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones. Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes se…
"Let's also not forget that Java is significantly faster" Citations please. While I am not necessarily saying I don't believe you (because a properly tuned JVM is lightning fast), making a statement like this without numbers to back it up is a gaping hole in your argument.
http://benchmarksgame.alioth.debian.org/u64q/go.html
Keep in mind this is comparing Go 1.4, I'd expect 1.5 to do better.
Earlier quoted context omitted.
It is not unprecedented, e.g. see: http://en.wikipedia.org/wiki/Crash-only_software Martin Rinard at MIT has done a lot of work in this area. It can be safe if you can rollback to a good state to avoid data corruption. Glitch, my current project, does not bother with reader locks for multi-core execution; instead it can rollback and retry when a write-after-read is detected effects are logged (dependencies are traced…
I'm aware of crash only software (isn't this how Erlang/OTP does things?), however this doesn't seem to be what the OP intended. Running your code without caring about data races means your data can be corrupted and program might not crash.
Earlier quoted context omitted.
> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…
> You deploy. You're done. Then you set your memory parameters. Then you tweak them, to make it more performant. Then you increase them some more to make the GC work less. Then you hook up to the JMX port so you can profile what's going wrong, and identify some XML library as allocating megabytes of strings when it then dumps. Then... Yeah.
I would love to have a GC which tunes itself to accommodate the workload. On the JVM, G1 is a step in the right direction. How does Go's GC work in this regard - does it auto-tune itself?
Also, how are Go programs monitored in production? Are there tools like AppDynamics, NewRelic, JConsole or similar APM/telemetry solutions available to monitor Go applications?
I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done. We march on.
Could I have written this service in C++? Absolutely, but it would have taken me 20 hours to get to the same level of confidence. Maybe some could do it on 2 hours; I'm admittedly not a great C++ developer or frequent user.
Could I have written it in Python? Sure, but I would have had to scale and put it behind a load balancer, adding complexity to get equivalent performance.
From what I've seen of Rust, I like it and plan to give it more time now that it is stable. I haven't spent time with D. I played with Erlang. I don't care for Haskell for anything remotely related to "work", but I don't dispute that it has a place in computer science.
In my 2 years with Go, this is not my first positive experience. I have found that Go works well for cranking out high fidelity, snappy services like this. I think this is the result of the language's constraints enforcing simple patterns. Unlike C++ and Python, there are not a huge number of ways to accomplish tasks (at least not ways that feel natural).
Take it or leave it, but I like Go (for certain things).
Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done…
Probably. C++ productivity really relies on knowing good libraries, and having the freedom to use them. Without details, I'd wager you could have done it in 300-400 lines. If you gave a brief overview of what you needed, I'd describe my first instinct for doing it in C++.
Earlier quoted context omitted.
I think you must agree that no matter how painless it is, binary < JAR + JRE, in terms of deployment effort.
Depends. For me, creating an uberjar with my default project/package manager is easier than to setup cross-compilation with Go. YMMW.