Hacker News Reader

Comment by stiff | Hacker News Reader

Once you understand the space of possible programming languages you can often learn a new one in just a week or two, I learnt Go over the last two weeks and it is so similar to C there wasn't much friction involved and I am already getting things done pretty comfortably. As always on such occasion I must recommend the book "Programming Language Pragmatics" for getting a good understanding of various possible language semantics.

What is harder and crucial for productivity is remembering a wide subset of the standard (at least) library, and this is much harder. I wrote non-trivial software in C, C++, Java, Python, Ruby and Lisp/Scheme, but I only really know by heart the standard library in Ruby, because I do it for a living currently, and a fair bit of the Java one, in other languages I have to look up things all the time.

View on HN

> Once you understand the space of possible programming languages you can often learn a new one in just a week or two,

This is only true if that new one is closely related to the ones you already know.

Learning, say, Haskell, in the period of week for the person with knowledge of “standard set” like C,Python,JS,Go will be somewhat painful exercise include some brain explosions.

What I meant by the "space of possible languages" is the set of design choices involved in making a programming language, and this obviously includes deciding on the imperative, logical or functional (or yet another) paradigm. A good general programming languages book like the one I mentioned, or a general programming languages course at the university, will teach you things like dynamic vs. static typing, lazy vs. eager evaluation, different possible type systems etc. Once you learn those things in a general setting it is much easier to learn a new language, by identifying it as a point in this space (e.g. strongly typed, lazily evaluated, functional language with pattern matching ...), unless it's a total outlier from all the current major streams of thought.

Although having put a bunch of effort into Haskell, I encounterd golang and thought "Oh cool - C with typeclasses!".

The problem is it's not that simple though because interviewers like to ask really language specific questions for example a C interviewer favorite: what are the different uses of 'static' in C.

C is a pretty core language to know, that spawned several others.

It's a special case IMO.

Go is similar to C in the sense that for every decision C made, Go made the opposite.

Go: no headers. C: headers.

Go: no pointer math. C: pointer math.

Go: multiple return values. C: one return value.

Go: no parens for if/for. C: parens for if/for.

Go: interfaces. C: no interfaces.

etc.

For any two points in N-space, you can draw an (N-1)-sphere around them such that the line between them forms the sphere's diameter. Then they appear to be opposites, within the artificially-limited domain you're talking about.

> Go: no parens for if/for. C: parens for if/for.

If the if/for constructs are sufficiently alike that you can meaningfully compare their parentheses usage, then I think that's evidence they're pretty damn similar.

Ha yes, I just looked at that and thought: How would I explain the difference in method calls in Obj-C and JS in 7 words. i.e. Something thats actually quite different...

He seems to be comparing it to his wheelhouse: Ruby. Syntactically C & Go are very similar in comparison.

I don't think multiple return values or interfaces were considered at the time when C was made.

Also, the cost and gain of various features (for example headers) was completely different then.

I didn't claim those are identical, but you are cherry-picking facts, what about:

- syntax (curly braces, star for pointers and dereferencing, ampersand for getting the address etc., cleaned up for faster parsing and with some genuinely new things)

- iteration via for loops (no iterators, no map/fold/...)

- structs for data abstraction

- layout of variables in structs corresponding directly to memory layout

- argument passing by value or via pointers

- very weak typing

Look at it from the other side, what new things has a C programmer coming to Go learn, besides the syntax? Slices, goroutines, make/new, and some little bits related to packages/runtime, all hardly difficult concepts. Some old habits do not work anymore, mostly minor things. Finally both authors (Thompson and Pike) were C coders for decades...

Yeah, the only gotcha I've ever had with Go was being confused about why I couldn't pass a pointer to an interface. Then I grokked what interfaces are in Go (a pointer to an implementation satisfies an interface, a pointer to an interface is nonsensical), and was good to go.

I wouldn't call Go's typing "very weak". It's not Haskell, but it's still a fairly typical manifestly-typed language like C# or Java (minus contra- and/or covariance), and you certainly can't just slop values around without thinking about their type. "Very weak" I'd reserve for Perl, Javascript, or (I think) PHP, with their propensity to turn "anything" into a string or a number out from underneath you.

It is generally stronger than C's, in that C lets you be quite... creative... in how you cast values. Go qua Go does not let you do that, though it does have an escape hatch via the unsafe package that lets you do anything C can, mostly used for interfacing with C.

Go does indeed add some nice checks over C. For example, given:

    type foo int

    var (
	    A foo = iota
	    B
	    C
	    D
    )

    func bar(x foo) ...

It's an error to write:

   bar(2)

That's enough typing to prevent many types of annoying mistakes.

Reply on news.ycombinator.com