Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

141–150 of 235 posts

Re: A year with Go

#141

Post by Thetawaves »

threeseed wrote: post #56
nostrademons wrote: post #18

Earlier quoted context omitted.

It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.

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…

Most of the benchmarks I have found show go to be faster at cpu things and java to be faster at memory things.

This is no surprise considering that go is a compiled language and the java garbage collector has had decades of very smart people working on it.

Re: A year with Go

#142

Post by pron »

tomphoolery wrote: post #60
RyanZAG wrote: post #40

Earlier quoted context omitted.

Probably Java (or other JVM lang) running something like Disruptor for high performance, or actor based libraries like Akka for general use case. No numbers, but considering how it's used in nearly all the bigger tech and finance companies, I'm guessing it probably has more use as a highly concurrent platform than anything else discussed here.

Another reason for their usage of the JVM could be because a lot of these languages specifically designed for concurrent programming either didn't exist or were in their infancy of real-world usage. Erlang was proprietary until 1998, and Haskell was not created by a large company. In the meantime, Sun was pushing Java everywhere they possibly could. So it makes sense that larger tech and financial firms, especially t…

Forget familiarity, hot code loading, and the huge library ecosystem (the largest in computing history) compared to one of the tiniest, but Java's runtime monitoring is far, far ahead of anything Haskell (or any other language or platform) can provide, and while Erlang's is pretty impressive (a close second), it is still not on the same level as Java's.

Re: A year with Go

#143

Post by pixie_ »

fixxer wrote: post #108

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#?

Re: A year with Go

#144

Post by [deleted] »

tptacek wrote: post #113

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…

[deleted]

Re: A year with Go

#145

Post by nickysielicki »

wtetzner wrote: post #128
echlebek wrote: post #119

Earlier quoted context omitted.

Depends on what you consider obfuscation. Consider the following python code: a.b = c In isolation, there is really no way to tell what that line of code will do. Maybe it will simply assign c to a.b. But because Python has property setters, it might also update some rows in a database[1], write a file, or make an HTTP request. One might call that abstraction, but I think it qualifies as obfuscation. A single line ca…

> A single line can invoke arbitrary behaviour. Isn't that true of any language with even the simplest mechanism for abstraction? How about this go code? doStuff(1, 2) It could "update some rows in a database, write a file, or make an HTTP request."

I think that's fundementally different, you know you're calling a function there.

An example in golang would be something like:

    type foo struct {
        a    string
        b    int
        c    *someOtherStruct
    }
    var blah = foo{"example", 42, nil}
    blah.b = someMagicVariable

Re: A year with Go

#146

Post by coldtea »

It's amazing how Go caught on.

It's not well designed -- lots of special cases reserved just for the compiler, some bizarro decisions, etc.

It's not modern (with the possitive associates of modern, not fadish, and modern being "the last 30 years of experience" which is still like a millenium in IT years).

It's implementation is not great either. Not a very good compiler, not a very good GC, not good tooling.

My theory is it caught on for 4 reasons:

1) It came from Google, and with some famous names to top. This got it initial publicity in programming sites and media, and Google then coughed for conferences, a spot on I/O etc -- so it caught lots of eyeballs, something independent languages don't have a chance to do.

2) It produces static binaries and this was a real need for lots of use cases.

3) It's easy to get started with, and made converts from scripting languages feel empowered, as if they were "real programmers" writing C, what with "pointers" and static types.

4) It makes writing parallel code for some uses cases easy, which is a good fit for some infrastructure/services apps.

(I don't think most teams outside of Google and some C++ or Scala shops have had any beef with "long compile times" for that to have been a major factor. Though it played to the hype of it being "just like a scripting language").

Re: A year with Go

#147

Post by sagichmal »

threeseed wrote: post #133
fixxer wrote: post #108

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 understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.

    > If you were a strong C, C++, Java, Scala, Clojure etc 
    > developer you could equally deliver a highly scalable 
    > solution in 2 hours.
I guess the point is, no, you couldn't. An equivalent solution would be less robust/reliable or take (much) longer. Or both.

Re: A year with Go

#148

Post by sagichmal »

twic wrote: post #72
mikeokner wrote: post #11

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…

    > You install a JRE on the machine.
Whoops. That's where you lost me.

Re: A year with Go

#149

Post by coldtea »

tptacek wrote: post #113

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'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous.

Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.

Re: A year with Go

#150

Post by coldtea »

sagichmal wrote: post #147
threeseed wrote: post #133

Earlier quoted context omitted.

I don't understand what I am supposed to take away from this though. If you were a strong C, C++, Java, Scala, Clojure etc developer you could equally deliver a highly scalable solution in 2 hours. I haven't seen anything yet to show why Go is fundamentally easier to deliver solutions except for single binary development which isn't really an issue for server side development.

> If you were a strong C, C++, Java, Scala, Clojure etc > developer you could equally deliver a highly scalable > solution in 2 hours. I guess the point is, no, you couldn't. An equivalent solution would be less robust/reliable or take (much) longer. Or both.

With some of this languages it would have been much faster AND much more reliable.
Post reply on HN