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

111–120 of 235 posts

Re: A year with Go

#111

Post by rraawwrr »

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

Given an `type IBar interface { Bar() }`, if you implement all your member functions in the form `func (this \*Whatever) Bar() {...}`, then only a pointer-to-Whatever implements IBar, not values of type Whatever. However, since golang can call functions with pointer receivers on values, a member function in the form `func (this Whatever) Bar() {...}` implements IBar on both values and pointers of type Whatever.

See http://play.golang.org/p/ToRh0uK3zw for a demonstration.

Edit: Actually, you can call a function with a value receiver on a pointer value too, so this behavior is inconsistent =/

Re: A year with Go

#112

Post by istvan__ »

fixxer wrote: post #108

Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done…

Yes, correctly exposed concurrency is a pretty amazing thing. CSP ftw! You could as easily do it in Clojure, Erlang or any language that supports that.

Re: A year with Go

#113

Post by tptacek »

I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Write a better one!

Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undeniably impressive programming tool.

Re: A year with Go

#114

Post by ndesaulniers »

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…

I think you'll find that opinions that trash talk any given technology whether OS, browser, language, editor, hardware, etc and then take the easy way out by not posing the "correct" choice get heavily upvoted.

In general, it's much easier to spot defects and more difficult to see the good in things. People are much more likely to play into their own biases from the safety of online anonymity.

For instance, "I don't like this OS, browser, language, editor, hardware, etc or this person's/company's choice of OS, browser, language, editor, hardware, etc, therefor downvote/rant/complain/FUD."

It's really too bad. It never hurts to know more, and it shows new members of the community that it's acceptable to behave that way and to not try to learn new things.

Re: A year with Go

#115

Post by meddlepal »

istvan__ wrote: post #45
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 "…

I am not sure your definition of upgrade, but it is definitely a downgrade in terms of features even comparing it to Java. It has lean environment that makes it more attractive to systems programming and the CSP (channels, go routines etc.) make it great for concurrency. The trouble starts when you are shifting from systems projects to business logic projects. This is where Java runs circles around Go (or for that ma…

I get the feeling that the people who deride Java either have little experience with the language and ecosystem or had were the poor folks that had to maintain a legacy It has its quirks (what languages doesn't?) but it is a fantastic general purpose programming language.

Re: A year with Go

#116

Post by wtetzner »

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

As far as I know Erlang doesn't give you any guarantees about side effects. You can call side-effecting functions at any point in your program, just like in Clojure or OCaml.

Re: A year with Go

#117

Post by nly »

pcwalton wrote: post #54
nemothekid wrote: post #27

> Adding proper mutexes to some of our code in production slowed things down so much it was actually better to just run the service under daemontools and let the service crash/restart. Can the author explain this bit some more? If adding mutexes slows down your code to the point where you would rather just deal with data corruption/races it seems to me that there are issues with your code, not the language.

Yeah, that seems weird. A properly implemented mutex is one atomic instruction in the uncontended path to lock and one more to unlock. And if you remove the mutex, you're turning "the contended path" into "the path that blows up your program". Atomic instructions can be painful on, for example, ARM (where they turn into load linked/store conditional loop + memory barrier) but they shouldn't be too bad on x86 servers.…

I think the shitty ARM mutex problem you're describing was fixed in ARM8?

Re: A year with Go

#118

Post by wtetzner »

smegel wrote: post #74
RyanZAG wrote: post #40

Earlier quoted context omitted.

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.

You can use Quasar, which does bytecode instrumentation.

http://docs.paralleluniverse.co/quasar/

Re: A year with Go

#119

Post by echlebek »

meowface wrote: post #75
nickysielicki wrote: post #42

Earlier quoted context omitted.

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.

Depends on what you consider obfuscation. Consider the following python code:

  a.b = c
In isolation, there is really no way to tell what that line of code will do. Maybe it will simply assign c to a.b. But because Python has property setters, it might also update some rows in a database[1], write a file, or make an HTTP request.

One might call that abstraction, but I think it qualifies as obfuscation. A single line can invoke arbitrary behaviour.

[1] This is how SQLAlchemy's models work. As I write this, the library is nearing it's 10,000th commit. A serious piece of software!

Re: A year with Go

#120

Post by jballanc »

tptacek wrote: post #113

I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…

I completely agree. Some languages are written to adhere to an ideal (everything is lists), and make sacrifices in order to stick to that ideal. Some are written to be close to the metal, or to be as abstract and flowery as possible, and make different sacrifices. Every language has some primary goal, and all the rest must bend to accommodate that goal.

Go's primary goal is: excellent tooling.

Post reply on HN