171–180 of 235 posts
Apparently, the author doesn't understand how pointers work in Golang. He should read this article: http://openmymind.net/Things-I-Wish-Someone-Had-Told-Me-Abou... . In short, golang pointer is neither c pointer nor java reference.
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.
Here's one example:
// imagine a for-loop around this
s := foo[i:i+4]
s[3], s[2], s[1], s[0] = s[0], s[1], s[2], s[3]
The reasonable assumption is that the second line generates either zero, one, or four bounds checks on s. However, the Go compiler likes to be sure, and turns it into 8 bounds checks.
I agree it's not a typical for a server to spend the majority of it's time swapping bytes. In the rare case that happens, you're going to hate the compiler for not being smarter.
EDIT: fixed formatting of the example
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…
Not sure why you didn't compare to 2 languages at about the same level, and instead went with a lower level and a higher level language.
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…
If you have 20 c# devs, why not code it in c#?
I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…
I completely agree. Some languages are written to adhere to an ideal (everything is lists), and make sacrifices in order to stick to that ideal. Some are written to be close to the metal, or to be as abstract and flowery as possible, and make different sacrifices. Every language has some primary goal, and all the rest must bend to accommodate that goal. Go's primary goal is: excellent tooling.
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 install a JRE on the machine. Whoops. That's where you lost me.
Earlier quoted context omitted.
Yes, Gosublime is a good example of how tooling can be helpful, though from what I can tell it is somewhat less helpful than what you'd expect in a decent IDE (e.g. no refactoring support, the interface is mainly dropdowns, weak support for finding definitions and usages).
Really, all I need is gofmt on save, and even that is mostly because I've gotten so used to it that I drop ugly unformatted dreck into my editor and let gofmt clean it up. I worked full time for year without go to definition, mostly because full text search is almost as good most of the time, due to how regular formatted go code is. I don't really use anything else, mostly because I don't need anything else and I hav…
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…
I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…
> 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…
I'm not saying that library versioning and dependencies are not a problem with Go. Quite the contrary. But it's a compile time issue. There are far fewer surprises at runtime and that makes deployment a lot easier.
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…
> I don't care for Haskell for anything remotely related to "work" Why not? Haskell seems perfect for this task. It has fast, robust and safe concurrency and GHC's IO manager is highly optimized and insanely fast.