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

151–160 of 207 posts

Re: Go best practices, six years in

#151

Post by sagichmal »

curun1r wrote: post #130
wtbob wrote: post #64

Earlier quoted context omitted.

> For instance, there's a ton of Go repositories out there that are not go gettable because the author wanted to put source code under a src directory and hacked that together using make. Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him … > And good luck with organizing any repository that contains multiple languages where go is one of them...go's "code liv…

> Are there? If someone's that ignorant of the language, I don't think I'd want to run something written by him … Yes, there are. I don't know any off the top of my head, but I see them all the time. So, just for fun, how about a little test: Step 1: Google 'notable applications written in golang' >> first result: http://www.infoworld.com/article/2843821/application-develop... Step 2: Click through to github repos >>…

The etcd binaries are go gettable. The others are large enough to easily justify their own build process.

Re: Go best practices, six years in

#152

Post by pjmlp »

catnaroek wrote: post #147
valarauca1 wrote: post #86

Earlier quoted context omitted.

>I feel like I'm relearning C++ Because you are. You likely wrote widly unsafe things which are perfectly legal in C++. Rust is really just enforcing RAII which C++14 already has, and you've likely avoided.

C++has had RAII for decades already. Actual Rust innovations are the borrow checker and dynamically sized types.

Yes, we were already using it on Windows to program COM in the mid-90's.

Re: Go best practices, six years in

#153

Post by catnaroek »

gtrubetskoy wrote: post #92
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…

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…

> threads and locks are so easy to do!

I don't think concurrent programming was ever particularly easy in Java. If you're talking about `synchronized` methods, well, they are of limited usefulness (to put it mildly) when you need to lock objects in an interleaved fashion: "lock A, lock B, unlock A, lock C, unlock B, lock D, unlock C, etc.", which isn't too uncommon a user case.

> stuff that previously could only be done in C/C++ (...) almost as easily as writing Python or Ruby

Metaprogramming, any? C++ has templates. Python and Ruby have metaclasses. What does Go have?

Re: Go best practices, six years in

#154

Post by Hydraulix989 »

nixusg wrote: post #148
throwaway_exer wrote: post #142

Earlier quoted context omitted.

> Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that? 4 GB per program absolutely destroys VM consolidation. I love the look on managers' faces when they ask for a 1 GB VM and I ask them, "Is this for a Java program?" :)

Just adding some ram is also not so easy in an embedded system.

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

Re: Go best practices, six years in

#155

Post by learc83 »

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…

Here's a reply from the creator. https://www.reddit.com/r/elixir/comments/48ke69/any_reason_w...

Re: Go best practices, six years in

#156

Post by incepted »

viraptor wrote: post #145
incepted wrote: post #133

Earlier quoted context omitted.

> 4. Who really cares about cross-platform code if all I do is on Linux? Most developers write their code on Windows and MacOS and then deploy on Linux. I'd say this "Write once run anywhere" thing was and still is a pretty big deal. > 5. Why does this program require 4GB of ram? Oh no! I need to buy a $5 piece of hardware to run this Java code? What kind of nonsense is that? > 6. Must I really download and install t…

> Once or twice a year, if you really want to. I really hope you actually mean 7+ times a year. https://en.wikipedia.org/wiki/Java_version_history#Java_8_up... - most versions contained security updates.

None of these updates are mandatory. You don't have to upgrade anything if you don't want to.

Re: Go best practices, six years in

#157

Post by bad_user »

gtrubetskoy wrote: post #92
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…

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. There are Ruby developers choosing JRuby for deployment because of that efficiency. By the time Go's GC will reach the same maturity, it will behave similarly.

> 6. Must I really download and install the JVM all the time, and what is it good for anyway?

The JVM ensures consistent behavior across all platforms and is able to do optimizations based on runtime profiling, with JVM bytecode acting as a very efficient ABI, making the JVM an efficient target for multiple languages, including Scala, Clojure, Groovy, Ruby, Kotlin, Ceylon and others, languages that have been able to bootstrap easily and have a huge ecosystem at disposal because of the JVM.

> 1. Wow, I can write stuff that previously could only be done in C/C++, and I can do it almost as easily as writing Python or Ruby.

Go is not a replacement for C/C++ because it has a GC. In fact it's impossible to use Go for the same use-cases where C/C++ is required. And if you can use Go, then you can use Java as well. And in fact, because Java is more mature and has alternatives like Azul's pauseless GC, it's more amenable for projects with soft real-time constraints.

> 2. Wow, I don't need anything installed for my program to run, it just runs!

That's cool sometimes, but Java is almost as ubiquitous as POSIX and HTML5. On Linux it's basically one "apt-get install" away, just like everything else. So the advantage of not requiring a runtime for me is, you know, meh.

Re: Go best practices, six years in

#158

Post by viraptor »

incepted wrote: post #156
viraptor wrote: post #145

Earlier quoted context omitted.

> Once or twice a year, if you really want to. I really hope you actually mean 7+ times a year. https://en.wikipedia.org/wiki/Java_version_history#Java_8_up... - most versions contained security updates.

None of these updates are mandatory. You don't have to upgrade anything if you don't want to.

If you looked at the issues and verified they're either not applicable in your case or don't affect your application, you already spent a lot of time on it. If you do install, you should verify your app still works. If not, you already spent time on analysis. The actual installation time is next to nothing compared to everything else around the "new jre came out" event.

What I'm saying is - you should care 7+ times a year. Doesn't matter if you only update twice.

Re: Go best practices, six years in

#159

Post by cwzwarich »

catnaroek wrote: post #147
valarauca1 wrote: post #86

Earlier quoted context omitted.

>I feel like I'm relearning C++ Because you are. You likely wrote widly unsafe things which are perfectly legal in C++. Rust is really just enforcing RAII which C++14 already has, and you've likely avoided.

C++has had RAII for decades already. Actual Rust innovations are the borrow checker and dynamically sized types.

The borrow checker is predated by Cyclone and other work on region systems. Rust added more polish, but none of the basic ideas are new.

Re: Go best practices, six years in

#160

Post by cikey »

daurnimator wrote: post #97
askyourmother wrote: post #48

Earlier quoted context omitted.

Appreciate it was written as tongue in cheek, but I am glad that today a developer can start with Go, test, write code, build, deploy all with Go, whereas nearly every other ecosystem requires additional tools, often external competing tools. Then life becomes about having to learn whole new toolbekt before even coding. Go still keeps it lean, and is great. The fact it does not have hipster dev approved status is als…

> The fact it does not have hipster dev approved status is also an added bonus Huh? In my experience Go is the most hipster dev language around at the moment.

Seems more like Rust is the new hipster target if i count the recent hn posts about it...
Post reply on HN