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

A little Golang way

aerofs.com

Post reply on HN
Print view View original

81–90 of 194 posts

Re: A little Golang way

#81

Post by aikah »

shocks wrote: post #28
stesch wrote: post #18

How tied is Go into Google? What if Google drops Go?

Go is a programming language born out of Google for sure, but that does not mean it depends on Google. It's a community project after all.

> It's a community project after all.

It is absolutely not a community project. Go governance is a 100% @ Google . There is no go committee or go working group outside Google. It's backed by one company that has full control over it. Sure it's open-source, but good luck with a fork. How can anybody be so misleading about that fact ? What did make you think Go is a "community project" ?

> but that does not mean it depends on Google.

There is a top down , vertical relationship between the Go team at Google and the rest of Go users, Go main goal is to fulfill the Go team needs, period. If you find it useful then it's a bonus. That's exactly how the Go team speaks and act, in fact the Go team makes it really hard to contribute to the core.

Please, stop saying what you say, it is completely untrue and a total mis-characterization of how the Go project work.

I still want to know what made you think Go is a "community project".

Re: A little Golang way

#83

Post by eropple »

kjksf wrote: post #80
eropple wrote: post #67

Earlier quoted context omitted.

This, precisely. If I have to compile YourApp 1.5 with YourTLSLib instead of just `apt-get upgrade`, I'm going to be sending you flaming karmic poop for your karmic doorstep. And not just new features--though SemVer is very often honored in the breach more than the observance--but breaking, sometimes undocumented changes (two Go projects, Packer and Terraform, both come to mind).

`apt-get upgrade` is not magic. Someone had to package the app for apt. Someone had to decide when to make a new release. The same can be done for a Go app and it'll be available via apt just as any other app. A fair comparison would be compiling a C/C++ app from sources vs. compiling Go app from sources and Go wins that contest easily.

It is, to my mind, much less likely that somebody goes through and recompiles and publishes every statically linked application in the Ubuntu repos the day that the inevitable critical bug is unearthed than somebody recompiling and publishing libimportantthing3.

It is also much more likely that a "minor version bump" that happens to contain the dependency with the bug has regressions or new, untested-in-my-environment features that I must accept as the price of a Go application's upgrade unless I want to start playing with said application's vendored dependencies. Which I don't, which is why libimportantthing3 is a vastly superior choice for software I must use but do not want to adopt and care for.

Re: A little Golang way

#84

Post by chadaustin »

grey-area wrote: post #75
eropple wrote: post #33

Earlier quoted context omitted.

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns Really? Java 1.4 had an extensive and consistent standard library, implicit interfaces, composition instead of inheritance, static builds, and built-in concurrency? Go is not early Java, it's more like C 2.0, and I don't really see anything faux about the simplicity, it really is pretty simple, perhaps too simple for s…

> extensive and consistent standard library

yes

> implicit interfaces

no

> composition over inheritance

yes

> static builds

no

> built-in concurrency

sure, with an 1:1 thread model as opposed to an M:N thread model.

M:N is not always a clear win over 1:1:

https://mail.mozilla.org/pipermail/rust-dev/2013-November/00...

http://xiao-feng.blogspot.com/2008/08/thread-mapping-11-vs-m...

Also, to be very clear, Java's threads ("green threads") were _originally_ M:N but they switched back to 1:1.

Re: A little Golang way

#85

Post by davexunit »

hwh wrote: post #77
davexunit wrote: post #65

And the cycle continues, from one crappy enterprise language to the next. I don't who said it, but whoever said "Go is a bold step backwards" is spot on.

There are times when a step back is the mandatory step to get a new perspective on things. Just sayin'.

But this is a step back to the cold, dead, static systems of UNIX. How about stepping back and taking a look at the dynamic, hackable environments of Lisp?

Re: A little Golang way

#86

Post by KirinDave »

sz4kerto wrote: post #4

"Code size was reduced by almost half, from 175 lines down to 96." Hm, I how can we take a 175 LOC project as something relevant in any way?

I'm not sure what you'd expect a microservice with a straightforward bit of logic and a single HTTP route to actually cost in terms of lines?

I suspect the same (or greater) linecount gains could have been gotten by using a language even more pithy. How much you wanna bet the equivalent Clojure or Scala versio would be half again as many lines?

Re: A little Golang way

#87

Post by KirinDave »

aikah wrote: post #6

I'll bite. While it is absolutely true Go servers use less memory that classic servlet deployments, The question is what were you using at first place? where you using a big framework? with this or that big IoC container ? with a bloated ORM ? ... or where you using barebone jdbc and writing servlets without any framework? because essentially that's what you're doing with Go, Go has 0 big framework(and no Beego or Re…

The problem got exacerbated when the container-ized deployment stopped letting the OS more efficiently serve shared memory. There are lots of tricks and wisdom built into platforms like Tomcat to reduce memory use, too. They're just confused when they're alone in what appears to be their own universe.

This is why there's such a strong pressure to move to more svelte language implementations and "microservices" as you start to see containerization take off.

Re: A little Golang way

#89

Post by vorg »

travjones wrote: post #25

There have been several blog posts and conference presentations with a similar theme -- "Go is efficient, especially compared to X." I know it seems like hype, but I encourage others to try Golang out, maybe even slap a web app together with it. What you'll find is that your Go app will be extremely efficient and performant. It's kind of unfair to compare Go to many of the other languages of the web because it is com…

> slap a web app together with it

Web apps are on the decline, being gradually replaced by Android/iOS apps. When people can use Go to slap up a performant Android app, it may find more use.

Re: A little Golang way

#90

Post by vorg »

grey-area wrote: post #75
eropple wrote: post #33

Earlier quoted context omitted.

> What you'll find is that your Go app will be extremely efficient and performant. This is true, for sure. But my experience--and I've written plenty of Go, though I find it unpleasant to write and think about for all the usual reasons that Go partisans roll their eyes and so would rather deal with it as artifacts rather than actually writing it--has led to watching lots of developers make mudball codebases in the pr…

reinventing a lot of Java-1.4-era (because the language itself is essentially that) design patterns Really? Java 1.4 had an extensive and consistent standard library, implicit interfaces, composition instead of inheritance, static builds, and built-in concurrency? Go is not early Java, it's more like C 2.0, and I don't really see anything faux about the simplicity, it really is pretty simple, perhaps too simple for s…

> Go is not early Java, it's more like C 2.0

Or perhaps Go is C+

Post reply on HN