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

61–70 of 157 posts

Re: Things about programming I learned with Go

#61

Post by brightball »

krylon wrote: post #56
brightball wrote: post #37

Earlier quoted context omitted.

In my experience, I've found that inheritance becomes a significant burden on projects, especially when using 3rd party libraries. If you need to modify something up in a base object in a 3rd party library, you essentially have to fork the project creating a new maintenance burden and breaking the upgrade path OR rebuild the entire inheritance tree. It's one of the things that makes Ruby so useful as an object orient…

> In my experience, I've found that inheritance becomes a significant burden on projects, especially when using 3rd party libraries. I think inheritance is like any sufficiently powerful programming technique - with great power comes great potential for shooting yourself (and others) in the foot. But there are situations where inheritance is an elegant and natural approach. They just are not very frequent. Python's s…

Oh, I'm definitely not condemning it. Honestly, I think it makes more sense when you are dealing with a GUI or desktop application where an object can be more representative of elements that a user is interacting with.

For server side projects is where I've experienced it causing problems over project lifetimes. The maintainability complexity is where I've been bitten the worst.

Re: Things about programming I learned with Go

#62

Post by amelius »

masklinn wrote: post #48
amelius wrote: post #21

Earlier quoted context omitted.

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

> Also, concurrent (not stop-the-world) GC techniques could make this problem moot. It would mostly introduce insane additional complexity. Erlang GC works per-process (each process has its own private heap and stack) and you'd normally create lots of small processes, so the GC is concurrent as an emergent effect of the system construction. Not to mention processes can be distributed across nodes for which your schem…

> It would mostly introduce insane additional complexity.

GoLang has a concurrent garbage collector.

> what's supposed to happen if you ask for memory sharing across the network

Yeap, I mentioned that. Again, as a developer you want the choice. You don't want your language telling you "sorry, that's too complicated for your brain, so you can't do that".

Re: Things about programming I learned with Go

#63

Post by s_ngularity »

yen223 wrote: post #50
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…

That's ... sad. Sum types and product types are simultaneously easier to understand and are more useful to know about than inheritance. Sum types are simply types whose values can be one of several choices - surely that's something a child can reasonably understand! Product types might be a little harder to grok - they're essentially structs - but surely no harder to understand than inheritance and the whole IS_A/HAS…

Inheritance is not a way to express sum types, it's a form of subtyping. A sum type is like a discriminated union, it can only be one thing at a time. Subtyping allows a value to have multiple (related) types simultaneously, which is much more expressive. I suppose you can use one level of single inheritance to emulate a sum type, but you could just as well emulate it with a discriminated union in Go, e.g. a struct with a type identifier and an interface{} holding the value.

Re: Things about programming I learned with Go

#64

Post by unscaled »

treehau5 wrote: post #57
Cthulhu_ wrote: post #42

Earlier quoted context omitted.

There's a lot of languages that can make that claim, and lots of developers that would pick up a new C-like language in a week or so. The challenge is that companies that picked Go or $uncommon_language need to provide the space and training opportunity. Go may be easy to learn, but mastering it is a thing on its own, just like the other languages.

Go's spec is much smaller than most mainstream languages. Seriously, it's a weekend read to understand the entire language specification (and it's actually readable)

Mastering a language is not the same as reading the entire spec, or even internalizing that spec. Scheme or Forth or Io are all probably smaller than Go. Perhaps even smalltalk is (the Smalltalk 80 spec is larger, but contains some of the library, tutorials, examples, and the entire spec for compiler and the VM).

If you really want an extreme example language with the tiniest spec, you can always take Brainfuck. The entire spec probably fits in a few paragraphs, but it's not easy to master.

Re: Things about programming I learned with Go

#65

Post by treehau5 »

unscaled wrote: post #64
treehau5 wrote: post #57

Earlier quoted context omitted.

Go's spec is much smaller than most mainstream languages. Seriously, it's a weekend read to understand the entire language specification (and it's actually readable)

Mastering a language is not the same as reading the entire spec, or even internalizing that spec. Scheme or Forth or Io are all probably smaller than Go. Perhaps even smalltalk is (the Smalltalk 80 spec is larger, but contains some of the library, tutorials, examples, and the entire spec for compiler and the VM). If you really want an extreme example language with the tiniest spec, you can always take Brainfuck. The…

My comment mentioned mainstream languages. To my knowledge, Brainfuck is not a mainstream language used at any small, medium, or large corporation.

The point about the spec was the language is small enough to master.

Scheme (Lisps in general) is different because it is homoionic. Forth is not mainstream, and neither is it's paradigm. And well, I never heard of Io so I will check it out, looks neat.

Re: Things about programming I learned with Go

#66

Post by masklinn »

amelius wrote: post #62
masklinn wrote: post #48

Earlier quoted context omitted.

> Also, concurrent (not stop-the-world) GC techniques could make this problem moot. It would mostly introduce insane additional complexity. Erlang GC works per-process (each process has its own private heap and stack) and you'd normally create lots of small processes, so the GC is concurrent as an emergent effect of the system construction. Not to mention processes can be distributed across nodes for which your schem…

> It would mostly introduce insane additional complexity. GoLang has a concurrent garbage collector. > what's supposed to happen if you ask for memory sharing across the network Yeap, I mentioned that. Again, as a developer you want the choice. You don't want your language telling you "sorry, that's too complicated for your brain, so you can't do that".

> GoLang has a concurrent garbage collector.

Golang also has a single, shared, mutable heap, it does not have tens or hundreds of thousands of individual heaps.

> Yeap, I mentioned that.

No, you did not.

> Again, as a developer you want the choice.

Er… no?

Re: Things about programming I learned with Go

#67

Post by eweise »

nicpottier wrote: post #33
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…

I'm about 8 months in to using Go for a few largish projects and I'd say these are probably the two biggest things I still struggle a bit with. (not generics as others seem to obsess about) On errors, I'm really of two minds. In a way, it is a lot like how Java started with checked exceptions, it forced you to deal with the error. But at some point most people decided that was annoying and switched to runtime excepti…

Checked exceptions suck. Every method has to explicitly throw them up to a higher level where they can be handled causing tons of useless boilerplate. Its much better to just let unchecked exception bubble to a higher level of the app. This is a best practice in java so letting the exception bubble all the way back to the user is just poor programming.

Re: Things about programming I learned with Go

#68

Post by mpd »

andreareina wrote: post #14

> Thanks to goroutines and channels Go programmers can take a different approach. Instead of using locks to control access to a shared resource, they can simply use channels to pass around its pointer. Then only a goroutine that holds the pointer can use it and make modifications to the shared structure. How does this prevent data races if more than one goroutine holds a pointer to the shard structure and they're run…

As others have said, the scenario you describe wouldn't prevent data races at all.

Under the channels model, you wouldn't want more than one goroutine to be accessing the shared structure. One routine would hold the reference to the resource, and other routines talk with the first routine via channels (i.e. share memory by communicating).

Re: Things about programming I learned with Go

#69

Post by vram22 »

rbehrends wrote: post #46
pm215 wrote: post #30

Earlier quoted context omitted.

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

A sum type `T = A | B` means that a value of type `T` can be either of type `A` or of type `B`. Such a type is used to express polymorphism. A product type (from "Cartesian product", i.e tuples) `T = A * B` means that a value of type `T` has a component that is of type `A` and another component that is of type `B`. It is used to aggregate parts into a whole. > Yes, I could go and research functional programming langu…

>A sum type `T = A | B` means that a value of type `T` can be either of type `A` or of type `B`. Such a type is used to express polymorphism.

Taking this example (in English / pseudocode):

Define a class Animal.

Define Dog as a subclass of Animal.

Define Cat as a subclass of Animal.

Case 1) Now if we have a variable a1 that can, at runtime, contain (or refer to) either a Dog or an Animal instance.

Case 2) And if we have a variable a2 that can, at runtime, contain (or refer to) either a Dog or a Cat instance.

Referring to your quoted sentences above, would you say that Case 1, Case 2 or both, are about sum types?

Just trying to understand the terminology.

Re: Things about programming I learned with Go

#70

Post by vram22 »

_ph_ wrote: post #55
erikb wrote: post #40

Earlier quoted context omitted.

Yes, exactly. That's what one would assume. I don't understand why a whole language community decided to not handle any errors and instead just bubble them up without filtering, without adding more notifications about the context like log messages, without trying to recover. Why would they expect a user to know their whole dependency tree and all their error messages.

I am not aware that they did. Most good Go code does not do this. That there exist some badly written Go programs does not contradict this. Go functions that can fail, should return an error as part of the function returns. Like with exceptions, you can decide to ignore any error or properly handle it. Even with checked exceptions, you can have an empty "catch", which means you are just ignoring it. So the difference…

>The Go version of error handling requires less typing overall

Do you mean as compared to using exceptions in a language like Python or Java? If so, can you give an example of code that does the same task, in both types of languages, to make this more clear? Thanks.

Post reply on HN