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

181–190 of 207 posts

Re: Go best practices, six years in

#181

Post by gizzlon »

jkarneges wrote: post #165
spriggan3 wrote: post #53

Earlier quoted context omitted.

> The fact it does not have hipster dev approved status is also an added bonus. What are you talking about ? the hype is strong with Go. So strong devs are persuaded they need to use Go at all cost then complain Go has a garbage collector ( just go go-nuts mailing list). So strong there are countless articles on the net about "How we moved from X to Go..." just like in 2007/8 with Rails. > The minute we see a bloated…

> So strong there are countless articles on the net about "How we moved from X to Go..." Writing about Go is a great way to hit the front page of HN. I once saw 5 articles about Go on the HN front page at the same time!

I don't think that's true anymore (?). HN has a well defined, very short, hype cycle.

Re: Go best practices, six years in

#182

Post by pjmlp »

fauigerzigerk wrote: post #177
pjmlp wrote: post #173

Earlier quoted context omitted.

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.

Which is the point of IBM and Azul's research.

Re: Go best practices, six years in

#183

Post by tptacek »

nvarsj wrote: post #38

The stages of go enlightenment: 1. Holy crap, this is like coding in early Java days, what the heck were the language designers smoking?! They just ignored everything! Where's my testing framework! DI?! Build system, dependency management?! WTF. 2. Holy crap, this is like coding in the early Java days! This is awesome! I can understand all golang code I read! Everything is so simple and easy. I finally get "less is m…

I'm sure this comment was written in good faith, but it doesn't belong at the top of this thread. It could be attached to virtually any post about Go. It barely engages with the actual post at all. Practically every other top-level comment below it is better.

And, of course, it spawned a completely useless thread litigating Java vs. Go. Perhaps that's why it's at the top of the thread --- which means voting had a perverse effect for this topic.

I don't know what to do about this tendency in language threads on HN, but it's a real problem.

Re: Go best practices, six years in

#184

Post by geodel »

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.

With >3 years release cycle by mid 2017 we are hoping to get Java 9 so to me Java 10 seams 2020 at the earliest.

Re: Go best practices, six years in

#185

Post by geodel »

pjmlp wrote: post #175
dig1 wrote: post #163

Earlier quoted context omitted.

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.

Well 2 thing stand out for me from links you mentioned:

> The applications use a combination of Thales proprietary middleware written in C combined with Java code enabled by the Java™ Native Interface (JNI).

> AONIX has additionally delivered professional services to help PERC Ultra users at Thales optimize their applications and improve execution performance including, a customer-specific training course handled the needs of coding in Java™ with hard real time constraints.

Seems like with helping of C and Consulting on 'How to do Java right' they made it work.

> End-to-end distributed thread timing constraints measured from stimulus to response are typically under 100 ms.

Since it is slightly faster than typical (per char) typing speed on keyboard. It appears nice but terribly impressive real time Java use case.

Re: Go best practices, six years in

#186

Post by frankzinger »

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.

> Imagine, Java is run on your phone's SIM card. Enough?

Not Java, not even close. JavaCard is an extremely stripped-down version of Java. I've used it and it feels like C.

From https://en.wikipedia.org/wiki/Java_Card#Java_Card_vs._Java:

> However, many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).

[EDIT] But I am not arguing with the overarching argument that Java proper can run efficiently on very constrained devices. It all depends on the implementation.

Re: Go best practices, six years in

#187

Post by pjmlp »

geodel wrote: post #185
pjmlp wrote: post #175

Earlier quoted context omitted.

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.

Well 2 thing stand out for me from links you mentioned: > The applications use a combination of Thales proprietary middleware written in C combined with Java code enabled by the Java™ Native Interface (JNI). > AONIX has additionally delivered professional services to help PERC Ultra users at Thales optimize their applications and improve execution performance including, a customer-specific training course handled the…

For me it is impressive, because if the system doesn't work, the wrong guys die.

Re: Go best practices, six years in

#188

Post by alexellisuk »

alexellisuk wrote: post #21

After working with .NET/Java/Node.js/Ruby/Python etc the move to Go involved a larger investment in time. I found this really informative and it's great to have the learnings condensed down.

I have run a coding-dojo type project internally at work at ADP. We had two PRs in Go, so while we are on this topic, are there any improvements that can be made to the Go submissions?

Does anyone want to submit a best-practice Go solution?

https://github.com/alexellis/xservedbyfinder

Re: Go best practices, six years in

#189

Post by hesdeadjim »

Libraries using log.Printf are incredibly tough to work with in a production environment if you want anything more interesting than looking at stderr. Libraries that let you provide a logger API at time of construction are better than log.Printf, but they still fail at letting you include contextual information inside method calls.

We inject a logging interface into all our methods that take a context.Context object [1]. This allows us to push contextual information onto the stack of context objects, and then when we log we can do it at the point of failure and have access to an immense amount of useful information. Check the attached gist to see an example of how this works in practice [2].

Given that the context library originated out of Google and is now part of the stdlib in 1.7, I would love to see other libraries embrace it instead of relying on much less flexible solutions.

[1] https://godoc.org/golang.org/x/net/context

[2] https://gist.github.com/justonia/f81eead323d2b23eca1c485ed8e...

Re: Go best practices, six years in

#190

Post by alexellisuk »

Hates_ wrote: post #66
Philipp__ wrote: post #55

Earlier quoted context omitted.

Could you please provide the link?

I'm assuming they are the ones listed here: https://peter.bourgon.org/talks/

Checking these out now. I use SoundCloud.. cool to hear about their infrastructure. It is a bit weird how you can't see his hands in the shot:

http://www.infoq.com/interviews/bourgon-crdt-go

Post reply on HN