Live data from Hacker News

Why Go is my favorite programming language

michael.stapelberg.de

201–210 of 256 posts

Re: Why Go is my favorite programming language

#201
post #198

Earlier quoted context omitted.

Here is an even better way of putting this; I believe Go hasn't been used for any of these areas: game engines; scientific simulations; military usages; planning, logistics and operations; space exploration; embedded systems and industrial software; robotics; etc. etc. etc. Go is great for one thing, mainly: highly concurrent problems with large 99th percentile latency permissions, which mostly means web development…

You keep mixing up what languages are currently used for and what they are suitable for. There are very few projects for which you couldn't use Go, JVM and .NET languages equally well purely on the basis of language and runtime features (ignoring hiring, library availability and other cultural aspects)

The entire category of "you need non-standard datastructures" works perfectly well on the JVM and .NET CLR, but is entirely useless in Go (thanks to missing generics).

Re: Why Go is my favorite programming language

#202

Its the best, but I'm sad and shamed it is owned by google.

Why are you sad? It is backed up by on the biggest Software companies in the world and the amount of free stuff Google is throwing around is mind boggling.

It is backed up by on the biggest Software companies in the world and the amount of stuff Google has their hands in is mind boggling.

Re: Why Go is my favorite programming language

#203
post #102

Earlier quoted context omitted.

People just end up inventing idioms to handle those, anyway. Go's nil-check error handling is a prime example. That's a beautifully solved problem with ADTs, but it's impossible without generic support, for starters. Runtime errors, abound!

Go can handle errors in a very deterministic way, and it can easily recover from a weird panicked state. If someone's Go code has "runtime errors abound" then they probably didn't RTFM ;)

Ah, so when I think of deterministic error handling, I think of compile-time enforcement, like that provided by a Result or Option type. Those can be ignored too, though, although the effort to do so is a little bit more explicit. :)

Re: Why Go is my favorite programming language

#204

Earlier quoted context omitted.

Go has functions with multiple return values. That's not at all the same.

I didn't talk about multiple return values, did I? Every language has error handling support, some languages hijack an exception mechanism as a control flow path for non-exceptional error states. Returning error values is more ergonomic than exceptions, but Go's lack of sum types makes this slightly tedious (still better than exceptions).

Right, I jumped ahead; multiple return values is the how Go returns error values, it's not error handling itself. I don't like exceptions much either, but sum types / ADTs are just so nice for this sort of thing.

Re: Why Go is my favorite programming language

#205

Earlier quoted context omitted.

Two weeks is a tiny investment to properly evaluate a language. Haskell is tripping you up because you're likely new to proper FP and very strongly typed languages. Pushing past two weeks, even if you don't use it, will make you a better developer, and the next FP or strongly typed language will come more easily.

You probably mean statically typed, not strongly typed. The distinction is clarified in "What To Know Before Debating Type Systems" : https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr...

I didn't, actually! I don't know how else I'd express it, but I'm thinking of Rust, Haskell, etc's "step beyond" plain static typing with sum/ADTs, pattern matching, and exlusion of null. A seemingly small detail, but it does feel like it makes the type system more deterministic and "stronger", in a sense.

Re: Why Go is my favorite programming language

#206
post #48

Earlier quoted context omitted.

"for all the deficiencies Go has, it is somehow highly compatible with the way my brain works." I have been tempted to write a blog post about "Why People Actually Can Write Real Programs In Go." To listen to HN complain about the language you'd think that it must be clearly impossible to ever write a program of any kind without massively copying and pasting everywhere, when in reality I find it's actually quite plea…

As somebody who likes it for work, how do you deal with lack of generics? My team is starting several new projects in go, where in the past we used either java (and I actually liked java typesystem) or nodejs (and I liked that one as well). I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language witho…

"As somebody who likes it for work, how do you deal with lack of generics?"

By using it in its core domain, network servers, where you don't tend to use generics very much. I've observed that generics seem to be less useful when you're almost always only one transformation away from your data even having just been or being just about to be a simple []byte buffer.

"I especialy got used to the functional style of using map/reduce/filter everywhere, and I am not sure if I would be able to continue in this style in staticly typed language without generics?"

Even if Go had generics it would probably still be a language where you write for loops.

I'm exceedingly iconoclastic on this point relative to the rest of the world: I don't believe "declarative" languages exist. As far as I'm concerned,

    reduce(func(x, y) -> x + y, 0, [1, 2, 3, 4])
is not very different than

    for _, val := range [1, 2, 3, 4] {
        sum += val
    }
Reduce is not any sort of "declaration" of how you want it to be done, it's just an alternate spelling for what may very well be identical machine code.

I am aware of the compositional arguments; my counterargument is that the only language I've used that is slick enough for the composition to end up being useful is Haskell, where the example I gave is

    foldl (+) 0 [1, 2, 3, 4]
where this is fluid enough that composition and factoring out bits of the pipeline is actually worth it. In languages like Javascript, due to the fact it is roughly an order of magnitude more noisy in the syntax, all the code I've seen that is using maps and reduces and folds could be trivially converted to for loops without loss of much more than vertical lines. (Sometimes I even would do the true FP thing and factor out bits of the pipeline, I found it confused people.)

(You can "win" in Javascript by using that sort of style to compose promises together or whathaveyou, but then, in Go, you're always writing at the promise level, so that doesn't matter.)

Basically, when composing two functions together is any harder than x . y, it's just not something people do.

However, your mileage may vary.

Re: Why Go is my favorite programming language

#207
post #110
post #48

Earlier quoted context omitted.

"for all the deficiencies Go has, it is somehow highly compatible with the way my brain works." I have been tempted to write a blog post about "Why People Actually Can Write Real Programs In Go." To listen to HN complain about the language you'd think that it must be clearly impossible to ever write a program of any kind without massively copying and pasting everywhere, when in reality I find it's actually quite plea…

> I wrote some code that takes a list of servers to query for some particular thing, and it was easy to write it to do them all simultaneously In javascript that would be: Promise.all(list_of_servers.map(query_server)) Other mainstream languages with similar concurrency primitives (pretty much all of them that either is dynamic or has generics) is similar. I don't think this is an area where Go shines.

That is not what I wrote. You need something smarter to deal with the fact I want the first server returned that replied with a successful response, which is, in general, not expected to be the first server that replied. If you want parity you'll also need to cancel the remaining requests once the successful one has returned.

You still won't have to add very much more stuff, but you're not going to be that much shorter than my Go in the end, either.

Re: Why Go is my favorite programming language

#208

Earlier quoted context omitted.

> It is way safer than void * I said "it's unsafe", not "it's not safer than void*". > (i.e. exit cleanly without corrupting memory). This makes no sense. If it exits, who cares if the memory of the process is corrupted? Also, this is the point: it exits instead of the compiler telling you this code will crash before you ship it. That's the point of static type safety (which Go doesn't provide in this case): it lets…

> If it exits, who cares if the memory of the process is corrupted? People care when memory is corrupted without the process exiting. It is usually better for a program to crash than for it to continue having corrupted its data. The former gives you x-ray machines which sometimes won't start, whilst the latter gives you x-ray machines which sometimes give the patient cancer. I say better, not best. Best, obviously, i…

> It is usually better for a program to crash than for it to continue having corrupted its data

And it's even better to no let this program get corrupted data in the first place, which languages with a weak type system (such as Go) allow to happen whenever you use `interface{}`.

Re: Why Go is my favorite programming language

#209
post #43
post #35

Earlier quoted context omitted.

> It doesn't add things, it takes them away, notably exceptions, inheritance, generics. s/exceptions/error handling/ What Go proposes is awful for a modern language.

Go has error handling, it doesn't have exceptions for non-exceptional error cases.

I'm starting to find it weird that things like "error while passing string as int" trigger an exception rather than return an error.

There are always error cases to check when handling user input. It's a natural part of the program flow, not really an exception.

I would expect an 'exception' to be something like out of memory or disk corruption.

Re: Why Go is my favorite programming language

#210

Earlier quoted context omitted.

Surely you could have used interfaces for this case, no?

And how do I get the same type out that I put in? I'd end up with Java 1 style programming, no generics, and having to cast atuff from Object/interface{} everywhere. interface{} is like Object, if it even exists once in your code, it's broken.

> And how do I get the same type out that I put in?

You can only get out the same type you put in. Presumably in your code you know that collection of Foo objects contains Foos, so you can just do:

    if foo, ok = collection.get().(Foo); !ok {
      return errors.New("expected a Foo")
    }
Write a few wrapper functions and you're done.
Post reply on HN