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

Go best practices, six years in

peter.bourgon.org

Post reply on HN
Print view View original

171–180 of 207 posts

Re: Go best practices, six years in

#171

Post by brightball »

pjungwir wrote: post #137
brightball wrote: post #78

Earlier quoted context omitted.

At some point mid #3 I finally hit the "I think it's time to just learn Elixir for every situation where I don't need a portable binary..." So far, looking like a solid decision.

I'm looking to transition from Rails to something more performant. Phoenix is at the top of my list, but these benchmarks worry me: https://www.techempower.com/benchmarks/#section=data-r12&hw=... https://www.techempower.com/benchmarks/#section=data-r12&hw=... In both Phoenix has very high error rates, and in the first it seems really slow. Here is their Phoenix test app: https://github.com/TechEmpower/FrameworkBenchm…

Yea, I had the same concern until I heard the reason. There are other benchmarks out there that compare to Go/gin that are more accurate.

Edit: Here.

https://gist.github.com/omnibs/e5e72b31e6bd25caf39a

Re: Go best practices, six years in

#172

Post by fauigerzigerk »

threeseed wrote: post #169
fauigerzigerk wrote: post #164

Earlier quoted context omitted.

>Java is actually very memory efficient, all things considering That makes me wonder about your universe of things to consider. Java's terrible memory usage was set in stone the moment they decided not to include structured value types.

Value Types are being worked on now for Java 10+. https://en.wikipedia.org/wiki/Project_Valhalla_(Java_languag... The Java language is definitely not set in stone.

No, the Java language is not set in stone. Its terrible memory usage is set in stone as long as the language doesn't have value types.

If (and that's a big if) they introduce value types in 2018, it will have been almost 25 years since that fateful decision that has done so much damage.

Re: Go best practices, six years in

#173

Post by pjmlp »

fauigerzigerk wrote: post #164
bad_user wrote: post #157

Earlier quoted context omitted.

> 4. Who really cares about cross-platform code if all I do is on Linux? Deployment happens mostly on Linux, but development happens mostly on OS X and Windows. Having guaranteed behavior, compiling it only once, being able to deploy as a simple JAR file, the same JAR file that you tested locally, is awesome. > 5. Why does this program require 4GB of ram? Java is actually very memory efficient, all things considering…

>Java is actually very memory efficient, all things considering That makes me wonder about your universe of things to consider. Java's terrible memory usage was set in stone the moment they decided not to include structured value types.

Besides being planned for Java 10, there are AOT and JIT compilers for Java that are able to convert simple Java types that follow a specific value pattern into value types.

An example would be how the IBM J9 JIT converts a final Point class, just with getters and setters into a value type.

Also there are language extensions from JVMs like IBM Packed Objects or Azul Object layouts that are exploring how to involve the language into value types.

It sucks that they didn't follow the route of Mesa, Modula-3, Eiffel and Oberon in regards to value types, but they aren't holding still.

Re: Go best practices, six years in

#174

Post by nedsma »

tujv wrote: post #85
xixixao wrote: post #80

Earlier quoted context omitted.

Surprises me it doesn't have syntax highlighting.

Possibly because Rob Pike is not a fan of syntax highlighting, calling it juvenile. https://groups.google.com/forum/#!msg/golang-nuts/hJHCAaiL0s...

Maybe it has to do something with the fact that Go's grammar is modest in size, being only 25 keywords. Compare that with C99 - 37, C++11 - 84, Rust 52 etc.

Re: Go best practices, six years in

#175

Post by pjmlp »

dig1 wrote: post #163
Hydraulix989 wrote: post #154

Earlier quoted context omitted.

But the Java JRE update installer wizard for Windows touts the fact that Java is "in" thousands of embedded systems -- parking meters, toasters, etc.

Imagine, Java is run on your phone's SIM card. Enough? On other hand, on truly constrained embedded systems where real time is essential, no GC-based language has any business, no matter how GC is good. Even C++ is sometimes avoided.

You mean like missile radar control systems?

http://www.pr.com/press-release/136232

Or do you prefer Aegis battleship Weapons System ?

http://dl.acm.org/citation.cfm?id=2402699

These are my favorite examples for Java being used in life critical situations.

Re: Go best practices, six years in

#176

Post by pjmlp »

fauigerzigerk wrote: post #172
threeseed wrote: post #169

Earlier quoted context omitted.

Value Types are being worked on now for Java 10+. https://en.wikipedia.org/wiki/Project_Valhalla_(Java_languag... The Java language is definitely not set in stone.

No, the Java language is not set in stone. Its terrible memory usage is set in stone as long as the language doesn't have value types. If (and that's a big if) they introduce value types in 2018, it will have been almost 25 years since that fateful decision that has done so much damage.

While it sucks that Java does not support value types like other GC enabled languages, apparently Go owner's are fine with that decision, to the point of fighting to keep using it on their products instead of replacing it with Go.

Re: Go best practices, six years in

#177

Post by fauigerzigerk »

pjmlp wrote: post #173
fauigerzigerk wrote: post #164

Earlier quoted context omitted.

>Java is actually very memory efficient, all things considering That makes me wonder about your universe of things to consider. Java's terrible memory usage was set in stone the moment they decided not to include structured value types.

Besides being planned for Java 10, there are AOT and JIT compilers for Java that are able to convert simple Java types that follow a specific value pattern into value types. An example would be how the IBM J9 JIT converts a final Point class, just with getters and setters into a value type. Also there are language extensions from JVMs like IBM Packed Objects or Azul Object layouts that are exploring how to involve th…

If the compiler can prove that an object is final and immutable and is never used in any other context that requires reference semantics, it could potentially use that optimization.

But then you also need data structures that can be parameterized to store such value objects as values. Otherwise you're back to square one.

Re: Go best practices, six years in

#178

Post by fauigerzigerk »

pjmlp wrote: post #176
fauigerzigerk wrote: post #172

Earlier quoted context omitted.

No, the Java language is not set in stone. Its terrible memory usage is set in stone as long as the language doesn't have value types. If (and that's a big if) they introduce value types in 2018, it will have been almost 25 years since that fateful decision that has done so much damage.

While it sucks that Java does not support value types like other GC enabled languages, apparently Go owner's are fine with that decision, to the point of fighting to keep using it on their products instead of replacing it with Go.

That's like saying you're fine with every decision taken by a government you voted for.

Go owners have millions and millions of lines of existing Java code and they employ many people whose entire careers were made on top of Java.

I'm not saying there are no rational reasons to prefer Java over Go. But Google is hardly the yardstick for that.

Re: Go best practices, six years in

#179

Post by gizzlon »

dig1 wrote: post #119
gtrubetskoy wrote: post #92

Earlier quoted context omitted.

Java was: 1. Wow, this program runs on any platform! 2. Wow, no need to free memory! 3. Wow, threads and locks are so easy to do! Then many years later 4. Who really cares about cross-platform code if all I do is on Linux? 5. Why does this program require 4GB of ram? 6. Must I really download and install the JVM all the time, and what is it good for anyway? Go: 1. Wow, I can write stuff that previously could only be…

2. Yea, right. Obviously you haven't run enough Go binaries

Really? I also find that to be true for the go stuff I run.

The last example is nsq[1]: Download, unzip and run the binaries .. aahh :)

Obviously this can be true for non-golang programs as well, but I can't think of any right now.

1: http://nsq.io/deployment/installing.html

Re: Go best practices, six years in

#180

Post by gizzlon »

bad_user wrote: post #157
gtrubetskoy wrote: post #92

Earlier quoted context omitted.

Java was: 1. Wow, this program runs on any platform! 2. Wow, no need to free memory! 3. Wow, threads and locks are so easy to do! Then many years later 4. Who really cares about cross-platform code if all I do is on Linux? 5. Why does this program require 4GB of ram? 6. Must I really download and install the JVM all the time, and what is it good for anyway? Go: 1. Wow, I can write stuff that previously could only be…

> 4. Who really cares about cross-platform code if all I do is on Linux? Deployment happens mostly on Linux, but development happens mostly on OS X and Windows. Having guaranteed behavior, compiling it only once, being able to deploy as a simple JAR file, the same JAR file that you tested locally, is awesome. > 5. Why does this program require 4GB of ram? Java is actually very memory efficient, all things considering…

>> 5. Why does this program require 4GB of ram?

> Java is actually very memory efficient, all things considering.

Huh? Considering what? Compared to what?

> There are Ruby developers choosing JRuby for deployment because of that efficiency.

Yeah, Java !=JVM, and Ruby is not Go so this is kind of moot.

>By the time Go's GC will reach the same maturity, it will behave similarly.

Says who? You can't just state that as a fact without backing it up somehow.

Post reply on HN