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

91–100 of 194 posts

Re: A little Golang way

#91

Post by jfb »

KirinDave wrote: post #86
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?

> How much you wanna bet the equivalent Clojure or Scala version would be half again as many lines?

263 lines?

Re: A little Golang way

#92

Post by benashford »

mkozlows wrote: post #8
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?

The relevance is that even a 175 LOC project in Java takes up enormous memory and disk footprint -- that the JVM is this super-heavyweight thing that's really just inherently inappropriate for a lot of applications.

The disk footprint was measuring the size of the docker container, who knows what was in it. Something would have to be wrong for 175 lines to require 650MB of dependencies... it could if it were loading all of Spring/Hibernate/etc., but then I'd challenge it wasn't a "microservice" at all.

Re: A little Golang way

#93

Post by grey-area »

vorg wrote: post #90
grey-area wrote: post #75

Earlier quoted context omitted.

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+

;)

Re: A little Golang way

#94

Post by hueving »

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.

You are missing the point. "apt-get upgrade" would just get the latest SSL lib and fix the vulnerability. You wouldn't be required to upgrade the core app in question.

Re: A little Golang way

#95

Post by _ak »

davexunit wrote: post #85
hwh wrote: post #77

Earlier quoted context omitted.

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?

You should rather ask yourself why Lisp hasn't been able to attract the same large and active community in 5 decades that Go has been able to attract in 5 years.

Re: A little Golang way

#96

Post by skarap »

I guess nobody will be saying that Java is lightweight, but the actual results of porting from Java to Go will vary wildly from usecase to usecase.

Both examples mentioned in the article (the 175LoC program and the CA) sound like very simple programs. E.g. I once wrote a C program which watched some directories with inotify and compressed new files using zlib. The memory footprint was 350KB. Obviously an empty JVM alone would use 100x more RAM. This static ~30MB overhead might be important in some cases and not relevant at all in others. The incremental (per-object) overhead is probably more relevant to almost all real-world usecases which are a bit more complex then the ones mentioned above.

Also - care should be taken not to compare apples (no TM) to oranges: e.g. if you use a huge ORM in Java (which among other things also caches results of each query) and then do a simple SQL query in the new implementation, would be strange to expect those two to perform similar. This happens quite often with rewrites - they almost always aim for simplicity, do short cuts, get rid of "unused stuff". Basically a rewrite from Java to Java will also usually improve performance.

Must-read about rewrites: http://www.joelonsoftware.com/articles/fog0000000069.html . Though, I guess, everybody has already read it.

Re: A little Golang way

#97

Post by pcwalton »

KirinDave wrote: post #88
stesch wrote: post #18

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

If you're concerned about Go, you might also find better results with Rust or Nim. Both are up-and-coming in similar spaces to Go.

Go isn't going away anytime soon. Neither is Rust. You shouldn't choose Rust over Go because of fear of the language being abandoned.

(I'm not too familiar with Nim's community so I can't speak to it.)

Re: A little Golang way

#98

Post by grey-area »

chadaustin wrote: post #84
grey-area wrote: post #75

Earlier quoted context omitted.

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 threa…

The comparison offered by the OP was Java 1.4 to Go 1.4.

I think the standard library is debatable (see the infamous early Java Date class), Java encourages using inheritance (so not composition instead of inheritance) - something Gosling later remarked as his biggest regret, and concurrency had improved tools in Java 2, not sure the story was as good in early Java.

Re: A little Golang way

#99

Post by s73v3r »

staunch wrote: post #52
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…

> Statically linking your SSL library makes you an asshole...Heartbleed 2.0. Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0. You haven't written much Go if you don't know that. The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases. Deploying a new Go binar…

"Go has its own SSL library, crypto/tls, which is not linked to any C libraries and wasn't affected by Heartbleed 1.0."

Is it going to be affected by Heartbleet 2.0? How about whatever the next exploit is?

"The argument is specious anyway, there's nothing difficult about building a binary from an old version of your code or just upgrading in most cases."

Not in every case, and not for customers who don't have access to the code.

Re: A little Golang way

#100

Post by 0xdeadbeefbabe »

aikah wrote: post #81
shocks wrote: post #28

Earlier quoted context omitted.

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 dep…

What do you mean good luck with a fork?

I know of one fork that will provide some lucky grad students with a degree. Can't find the link right now.

Post reply on HN