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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

71–80 of 235 posts

Re: A year with Go

#71

Post by SiVal »

skymt wrote: post #36
dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

It's typically not a good idea to choose technology based on fashion. If you like what Go has to offer, it's there for you to use, and don't let the hype backlash get you down. Maybe start with a small personal project, if you don't want to commit to working with it "in production."

The problem is that trying a language isn't like trying a new restaurant. At a new restaurant, I'll know within an hour almost all I would know after a year, and my chances of misjudging the restaurant that first hour are both low ("Hmm, none of these dishes taste very good to me, and I'm not wrong about that") and of minimal consequence (maybe there are better dishes I missed, or not, but I can just try a different new restaurant tomorrow.)

But my first project in a new language will take more than an hour (well, "hello, world", but that won't be enough of a test), and after I find something I don't like about the language in a first project, I've either found something bad about the language or something bad about me that this language is going to cure. Which is it? How will I know without an even bigger project...and pretty soon I'm the OP having spent a year giving the language a fair trial and now needing to start over with another language for another year.

I have a lot more hours left to investigate restaurants than years to investigate languages.

So, it's not a question of "fashion" per se, but trying to learn from the experiences of others. Of course, "others" vary, but you can still learn a lot about things that wouldn't be obvious to you in a first project by reading a lot of those varied opinions.

I read a lot about Go that interests me, but I just saw a survey of several thousand back-end mobile developers that showed that now, after several years of availability and the Google connection and all the talk about being a better Python and its explicit positioning as optimized for server-side apps, Go was not among the Top 8 most used languages for server-side apps. That interests me, too.

Re: A year with Go

#72

Post by twic »

mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit.

I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in the Java community, which suggests it's not a problem for other people.

When i see someone suggesting that Go has a significant advantage over Java in terms of deployment, i assume that they don't actually have experience of deploying Java apps, they're just regurgitating the standard Go talking points.

Re: A year with Go

#73

Post by andrepd »

twic wrote: post #72
mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…

I think you must agree that no matter how painless it is, binary < JAR + JRE, in terms of deployment effort.

Re: A year with Go

#74

Post by smegel »

RyanZAG wrote: post #40
smegel wrote: post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

Probably Java (or other JVM lang) running something like Disruptor for high performance, or actor based libraries like Akka for general use case. No numbers, but considering how it's used in nearly all the bigger tech and finance companies, I'm guessing it probably has more use as a highly concurrent platform than anything else discussed here.

The standard JVM's don't support lightweight threading (like Go's Goroutines)...so yeah while you can do concurrency with callbacks, or "actors" (callbacks with lipstick on), it's not quite the same thing.

Re: A year with Go

#75

Post by meowface »

nickysielicki wrote: post #42
meowface wrote: post #38

Earlier quoted context omitted.

> You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). You linked to someone intentionally trying to obfuscate Python as much as they can. Programmers are certainly not "almost expected to abuse the language internals". All dynamic languages provide various means for code obfuscation... it doesn't mean the language encoura…

Fair point. It does not encourage it. But it does allow it, and I think that means it inevitably creeps into a lot of code.

I have never once seen anything approaching obfuscation in any "serious" Python code.

Re: A year with Go

#76

Post by [deleted] »

felixgallo wrote: post #44
nickysielicki wrote: post #31

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is st…

> But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go. If there's any benchmark more pointless than the alioth benchmarks game, it's the 'what can a novice programmer do with the language in the course of 8 hours' benchmark. There are zero businesses that operate by giving novice programmers 8-hour tasks in unfamiliar l…

[deleted]

Re: A year with Go

#77

Post by twic »

xrstf wrote: post #70
baby wrote: post #33

Earlier quoted context omitted.

As I understand it, GO makes it so you can use both a pointer or the object itself to access it methods. And when you define an object method (or I don't know how it's called when you do this:) func (*string) uppercase(){ // make uppercase } Then by saying you use a pointer means you will modify the value when you do this: mystring.uppercase() So it's not really pointers, it's more an idea of pointers.

Things get ugly when your code grows. I had cases where I started with passing pointers to structs around directly, but at some decided that having dedicated interfaces would be better. But as soon as you're talking interface, pointers don't work as expected anymore, because Go (at least that's how I'm explaining it in my head) passes magic interface values to functions. So you can't just change `func foo(s MyStruct)…

One of the most unhelpful things about Go's pointer syntax is that it collides with HN's italics syntax. Hence, in your second paragraph, i see declarations which differ only in the slope of the type. Really, does nobody think of this when designing a language?

Re: A year with Go

#78

Post by istvan__ »

solarexplorer wrote: post #62
istvan__ wrote: post #48

Earlier quoted context omitted.

Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the stat…

Yes Clojure, sorry about the typo! The difference is that with Haskell or Erlang you get hard guarantees about side effects, but access to imperative libraries is very difficult. So you are kind of locked in a small ecosystem. With Clojure, Scala or F# you need to be disciplined and don't really get many guarantees, but you can reuse lots of imperative code. It kind of depends what your priorities are, if it's correc…

> The difference is that with Haskell or Erlang you get hard > guarantees about side effects, but access to imperative > libraries is very difficult.

Well yes, I can just live without imperative libraries because it is so natural to have single assignment (in the same scope) that I do it even in other languages. Accessing imperative libraries is possible though, just think about the C libs. What would you implement in Erlang the imperative way or which library do you miss exactly? The ecosystem is definitely smaller, but you can get support, some of the smartest software guys hang out on the mailing lists and IRc as well. I got absolutely amazing help from both when we worked on a Erlang project.

> It kind of depends what your priorities are, if > it's correctness or development speed.

Yeah and also how much fun you want to have. :)

Using Erlang is great but not many devs out there for hire, on the other side you have two seasoned Erlang devs they can do a lot. Contractors FTW!

Btw. what about using ASN.1 with Erlang? How does that change the correctness / development speed?

Re: A year with Go

#79

Post by kibwen »

sanderjd wrote: post #46
baudehlo wrote: post #29

Earlier quoted context omitted.

HN was the same about Node too. In a year we will see the same articles about Rust.

See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pa…

There's an entire Wikipedia article on this concept, in fact:

http://en.wikipedia.org/wiki/Hype_cycle

Post reply on HN