Live data from Hacker News

A little Golang way

aerofs.com

101–110 of 194 posts

Re: A little Golang way

#101
post #8

Earlier quoted context omitted.

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.

JDK... 167MB tarball + 330MB uncompressed

Re: A little Golang way

#102
post #95

Earlier quoted context omitted.

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.

Argument ad populum.

Re: A little Golang way

#103
post #89

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.

What are these mobile apps that don't have Web backends?

Re: A little Golang way

#104
post #89

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.

So slap an http api ?

Building native apps is hard unless you are specialized , but puking up some html and json is easy ,hence building a blog is usually good for introduction.

Re: A little Golang way

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

It's merely a positive (to most) data point. Do with it what you wish. Dismissing it outright seems impruduent.

Re: A little Golang way

#106
At my organization we have several Java-based services (some of them can even qualify as a form of microservices, if you squint your eyes). We have found that when you have very good developers and you write almost to the letter of the spec, Java can easily provide a stable base (which is probably true of any language/runtime/library).

However, we've been eager to try Go in several places. Believe it or not, what has held us back is the lack of a solid LDAP library. We could/should scratch our own itch and be done with it, we lack the time... still so many things to do! In the mean time, for us, Java support for LDAP is nothing short of stellar; and has been for years.

Re: A little Golang way

#107
post #8

Earlier quoted context omitted.

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.

Until you have enough microservices and each microservice carries its own Go runtime. Then having one JVM suddenly isn't so bad. The problem (as someone else said) is that using Docker may not be the right solution here. There are enough solutions (e.g. servlet containers) where you can run multiple services in one VM, with isolation, and security hardening (using security manager). With regards to memory footprint -…

> With regards to memory footprint - the difference here is that Java uses a minimum and maximum heap size that can be tuned with parameters. This has ... upsides (upper bound on the maximum memory use of a process).

If you're running a Go app in a container, you can use also tune the upper bound on memory use by restricting the available memory for the container.

Re: A little Golang way

#108

the only thing that's preventing me from jumping on the Go bandwagon is lack of a nice collections library (a la lodash).

That's due to a lack of generics. There are some workarounds like gonerics [1] -- a clever abuse of import declarations.

[1] http://bouk.co/blog/idiomatic-generics-in-go/

Re: A little Golang way

#109
post #8

Earlier quoted context omitted.

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.

Basically Ubuntu 15.04 docker image + openjdk8 + mysqlclient + the service itself

Re: A little Golang way

#110

Wow that pun in the title is painful.

Hehe, yes, I'm afraid I have a proclivity for terrible puns. I do think they're somewhat less cringe-worthy that the link-bait titles that are all the rage these days (or at least endearingly cringeworthy).
Post reply on HN