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

Things about programming I learned with Go

mjk.space

Post reply on HN
Print view View original

21–30 of 157 posts

Re: Things about programming I learned with Go

#21

Post by amelius »

masklinn wrote: post #3
amelius wrote: post #2

> Don’t communicate by sharing memory, share memory by communicating. Well, if you're using immutable data-structures, then structural sharing can be very useful. You can then pass large data-structures in constant time, and of course you can "modify" them efficiently using immutable techniques. As long as you don't perform any writes in a shared data-structure, the memory hierarchy should be perfectly happy and no d…

You're not "communicating by sharing memory" though, at least in the idiom's sense (in which "memory" is an alias for "mutable state"), the structural sharing is just an optimisation. Which may not even be desirable: despite being built entirely upon immutable data structures, Erlang only share large binaries between processes (AFAIK even the new maps are copied despite being HAMT) to ensure process heaps and thus ga…

> Erlang only shares large binaries between processes to ensure process heaps and thus garbage collections are completely independent.

That sounds unnecessarily restrictive. At least they should give developers a choice (e.g., "this process should receive integral data, and should not be disturbed by a GC cycle of other processes").

Also, concurrent (not stop-the-world) GC techniques could make this problem moot.

Re: Things about programming I learned with Go

#22

Post by jstimpfle »

brango wrote: post #12

"There is nothing exceptional in exceptions" No there's not, but it's a royal pain the arse to have to keep passing them up through your function calls to the level that actually cares about them and will do something about them. Try/catch eliminates boilerplate.

And even with exceptions, C++ is the only mainstream language I know that has a story how to undo any investments so far, including those that are not memory allocations.

In any other language, you have to at least write wrappers that execute commands and catch any exceptions to do specific cleanup actions (like aborting a database transaction).

And in C++, while it has a story how to do that, implementations must implement their own state to decide whether the reason for quitting is success or an exception. (this is more elegant in Haskell, which can do this with sum types, and for example monads on top).

Re: Things about programming I learned with Go

#23

Post by camus2 »

ordu wrote: post #19
brango wrote: post #12

"There is nothing exceptional in exceptions" No there's not, but it's a royal pain the arse to have to keep passing them up through your function calls to the level that actually cares about them and will do something about them. Try/catch eliminates boilerplate.

Doesn't Go have any syntactic sugar for pass errors out of function? Something like Rust's Carrier/From traits and try! or `?`.

No, go "errors" are just a convention, there is absolutely nothing special about them.

Go has panic/defer, which are exceptions, but done badly. They were probably retrofitted in the language when its creators realized they needed exceptions anyway, which makes the whole "error as value" a bit hypocritical. If they truly cared about error as value, then yes, Go would support some form of try! macro.

Re: Things about programming I learned with Go

#24

Post by nine_k »

pm215 wrote: post #18
rbehrends wrote: post #10

> It’s better to compose than inherit I know that this is just a restatement of the "composition, not inheritance" mantra in Go, but it still makes about as much sense as "product types, not sum types". A more meaningful statement would be: "use inheritance to express sum types, use composition to express product types." There's no "better" relation between the two concepts, each has its own distinct purpose. Yes, in…

'A more meaningful statement would be: "use inheritance to express sum types, use composition to express product types."' I'm not sure how well that works as a meaningful statement, because it assumes that the reader has a solid grasp of what a sum type and a product type are. If not (and I make the perhaps dubious assumption based on my own experience and knowledge that most programmers, especially most people using…

If you find yourself not knowing something apparently important, maybe it's worth spending half an hour with Wikipedia and the like to gain the understanding?

Among other things, the idea of a sum type helps understand the nature of the "billion dollar mistake" which is the inclusion of null in C, and why it pops up in other languages, and what more civilized methods of handling it might be. It will help you as a mainstream programmer, too.

Re: Things about programming I learned with Go

#25

Post by Ixiaus »

"Error theater" and zero initialized values, while understandable due to other design decisions, are the biggest source of frustration whenever I have to work on go code.

Off topic from the article, I think, but what go has taught me about programming is that some parts of our industry are stuck in time and intellectually stagnant.

Go is a better C. I would prefer Go over Python. But really, when the state of the art (and production ready!) is light years ahead of Go, it frustrates me to no end to see colleagues spending so much time on things in their day to day that are solved problems in other languages.

Re: Things about programming I learned with Go

#26

Post by nicpottier »

znq wrote: post #8

Don't want to hi-jack the article, but we've built Bugfender using Go. The problem is, we thought this is an internal (experimental) project and so Go (as a new language) would be fun to try out. But then Bugfender started to take off and we ran into serious problems making Go scale. Not because it is a bad language, but simply we were new to it ourselves. Today we're still running on go and we're more or less "ok" w…

I checked out those blogs and none of them really go into any depth about scaling issues. Do you guys plan to share your learnings there, I for one would find that interesting.

Re: Things about programming I learned with Go

#27

Post by gjem97 »

erikb wrote: post #20

I'm no Go expert, so the following may just come from having not used it enough. The two things that shocked me out of continuing with Go were exception handling and package management. Exception handling is basically not implemented. Instead the Go developers dediced to add half a step from return codes towards exceptions and work with that. And now the community seems to have decided to just reraise everything that…

The only time I miss exceptions is when I really need non-local return. Stack traces are available, see [1]. Needing non-local return really turns out to be the exception though (sorry). I find I want it when writing recursive descent parsers, and some other deeply nested control structures. In those cases, the panic/recover mechanism can be helpful. But for everything else, returning an error (using a standard error interface) works just fine.

As far as package versioning, what we ended up doing is vendoring everything into our source-control system. This fits our use better all around. For our production systems, we don't want inequality bounds on our library versions. We have tested our system with version X, we only want to ship with version X, not, X.1 or X.2. Vendoring allows us to pick a specific version. Admittedly, this makes more sense in the Go world, where executables tend do be statically compiled.

Vendoring makes it trivial to track local changes to code in our dependencies, and ship them upstream when appropriate. It makes new developer setup simpler. Finally, the Go toolchain has support for vendored code that makes the setup relatively painless. And near instant compilation means that you don't have to wait very long for your dependencies to compile.

[1] https://golang.org/pkg/runtime/debug/#PrintStack

Re: Things about programming I learned with Go

#28

Post by literallycancer »

leaveyou wrote: post #7
majewsky wrote: post #5

Earlier quoted context omitted.

I've never thought of that syntax as conveying a particular statement. They could also have done func *Receiver.method(arg int) instead of func (r *Receiver) method(arg int) The advantage is that you get to name the receiver instead of having to use a keyword name like `this` or `self`. I've come to like this design decision.

He speaks about non-local receivers. You can't have: func (r *otherPackage.Receiver) method(arg int)

What's the issue with composing a new type that has otherPackage.Receiver in it, and defining the new method on the new type?

Re: Things about programming I learned with Go

#29

Post by pjmlp »

ordu wrote: post #19
brango wrote: post #12

"There is nothing exceptional in exceptions" No there's not, but it's a royal pain the arse to have to keep passing them up through your function calls to the level that actually cares about them and will do something about them. Try/catch eliminates boilerplate.

Doesn't Go have any syntactic sugar for pass errors out of function? Something like Rust's Carrier/From traits and try! or `?`.

Not really, Go community tends to be very vocal against syntactic sugar.

Re: Things about programming I learned with Go

#30

Post by pm215 »

nine_k wrote: post #24
pm215 wrote: post #18

Earlier quoted context omitted.

'A more meaningful statement would be: "use inheritance to express sum types, use composition to express product types."' I'm not sure how well that works as a meaningful statement, because it assumes that the reader has a solid grasp of what a sum type and a product type are. If not (and I make the perhaps dubious assumption based on my own experience and knowledge that most programmers, especially most people using…

If you find yourself not knowing something apparently important, maybe it's worth spending half an hour with Wikipedia and the like to gain the understanding? Among other things, the idea of a sum type helps understand the nature of the "billion dollar mistake" which is the inclusion of null in C, and why it pops up in other languages, and what more civilized methods of handling it might be. It will help you as a mai…

I did look at wikipedia, yes, which gave me a page of type theory related stuff without any apparent grounding in practicalities, which gives the conclusion that it's apparently unimportant unless you particularly like mathematical theory. Yes, I could go and research functional programming languages and type theory; but my point is that if you're critiquing a blog post on a non-functional programming language then doing it in terms that only FP advocates will understand is missing the target audience.
Post reply on HN