Live data from Hacker News

Go best practices, six years in

peter.bourgon.org

161–170 of 207 posts

Re: Go best practices, six years in

#161

Earlier quoted context omitted.

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.

Of course, I'm aware that work on region systems dates back to the mid 90's, which is why I called Rust's borrow checker an “innovation” (the first time a product form factor or feature successfully makes it into a market) rather than an “invention” (coming up with a product concept that didn't exist before).

Re: Go best practices, six years in

#162
post #160

Earlier quoted context omitted.

> 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...

I don't think you can equate press coverage with hipster-ness.

Re: Go best practices, six years in

#163
post #148

Earlier quoted context omitted.

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.

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.

Re: Go best practices, six years in

#164

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…

>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.

Re: Go best practices, six years in

#165

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. 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!

Re: Go best practices, six years in

#166
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…

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

The biggest issue with Java IMHO , 6 not so much since deployment is automated.

> 1. Wow, I can write stuff that previously could only be done in C/C++

Not true, like at all. Every Go does can be done with Java.

Re: Go best practices, six years in

#167

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…

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

> What does Go have?

Go generate AKA C Macros but even worse since there is no macro syntax , you have to code you own code generator yourself .

Re: Go best practices, six years in

#168
post #160

Earlier quoted context omitted.

> 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...

How many articles a day about Rust on HN ? that's right, not as much as Go.

Re: Go best practices, six years in

#169

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.

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.

Re: Go best practices, six years in

#170
post #148

Earlier quoted context omitted.

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.

There are dozens of Java VMs some of which are optimised for embedded systems:

https://en.wikipedia.org/wiki/List_of_Java_virtual_machines

Post reply on HN