Hacker News Reader

> Golang is like Python [...] Fast to implement, easy to read

I disagree. Python is often described as "executable pseudocode" - for example, to delete the `i`th element from a list `a` you use `del a[i]`.

In Go, it's much more convoluted: `a = append(a[:i], a[i+1:]...)`. Plus, without generics, you can't even easily hide that inside a function! There's a whole page of these "tricks" that are necessary to perform basic operations on slices: https://github.com/golang/go/wiki/SliceTricks

Interesting. I didn’t know you could do that in python with a list.

It would be trivial for Go to support the delete keyword on slices (mapping to the statement you noted), but I think it would be a bad idea. Sometimes you want an operation to be awkward intentionally because it’s fundamentally costly. Hiding that cost by making everything look the same doesn’t always help the programmer. Languages should be powerful, but there should be an intuitive relationship between the code the computational complexity (not exact, but intuitive).

I’m sure there are counter examples, but I think Go generally does a good job at this. Plain loops are standard, make, append, new, delete, etc. have obvious costs. Error handling is explicit.

Yeah, Python is much much more readable than Go. I feel like performance focused languages are always less readable because the language needs to give you more control and I think Golang lets you work at a pretty high level of abstraction while still having plenty of control on performance. Once you know Go, it's pretty easy to read someone else's code, which I think is really nice. But "easy to read" might have been a little bit of a stretch.

> `a = append(a[:i], a[i+1:]...)`

Not only is this ugly and unintuitive (“what function do I call to delete an element?”; “append”), according to the linked page it can also cause a memory leak?!

On the other hand, it's very clear about what's actually happening when you delete an element of an array.

I'm not a C guy, but I figure doing this in C would involve several lines of mmemove, with loads of error checking[1]. So the Go version is about as ergonomic as you can get without obscuring what's going on.

[1] - I guess you'd do something like: memmove(a+i+1, a+i, sizeof(element) * (a->len - i)) with a whole load of checks to make sure everything's in order. I think C has the advantage of being utterly explicit about what is actually happening, but I think a higher level thing like append() is kind of nice when you don't want to think hard about, say, inserting an element in the middle of an array.

IMO Go's biggest issue is its lack of the functional features which have trickled into most languages (although arguably without generics, this is impossible to implement).

I dont particularly want Haskell with semi colons and braces, but a functional style definitely has its place.

Just like Go has a subset of the traditional object oriented style, i think there is a place for a subset of functional.

What do you miss? All I've ever really needed is the ability to pass around functions as first class primitives which Golang has.

I always cringe when people proclaim that they need to "get shit done". It often pays to be mindful of what is getting done as a result.

Are you suggesting that Golang leads to to poor quality software? That hasn't been my experience.

No, I specifically quote words from the comment to which I'm replying.

The problem is language-independent, but is more pronounced among adepts of "practical" languages and tools.

I think some people feel productive when they write out a big loop, but to me it’s wasted effort. I want to write

  col.filter(_.isReady).map(convertToX).any(_.color == BLUE)

and generate whatever fused loops make that work. I don’t want to write and review loop boilerplate by hand for the same reason that I don’t want to customize the stack frame layout when I call a function.

It really doesn't matter day to day once you're in the loop (cough). I agree, it's an ugly language on the face of it, but you get over that quickly. You come to appreciate the language as a whole.

A bigger concern when I started out with Go was the imports/lack of versioning, and at the time the lack of official package manager.

I've never found it much more painful to write:

  for i, c in range col {
    if c.isReady && convertToX(c).color == "BLUE":
      return True
  }

(which is not to say I don't miss the map/filter syntax - although I don't miss the bugs related to lazy execution in stuff like LINQ or Spark)

That’s actually pretty good. Most people would use three more lines to create a temporary and break after setting it, and three to nine more depending on how many steps require idiomatic Go error handling.

Would most people actually do that? That example seems like pretty idiomatic Go. I imagine junior developers would write that.

I would typically expect

  anyBlue := false
  for _, c in range col {
          ready, err := c.IsReady()
          if err != nil {
                  return nil, fmt.Errorf("isReady failed: %v", err)
          }
          if !ready {
                  continue
          }
          x, err := ConvertToX(c)
          if err != nil {
                  return nil, fmt.Errorf("convertToX failed: %v", err)
          }
          color, err := x.GetColor()
          if err != nil {
                  return nil, fmt.Errorf("getColor failed: %v", err)
          }
          if color == BLUE {
                  anyBlue = true
                  break
          }
  }

which badly obscures what’s going on but demands no cleverness at all (except that some might forget the “break” and still get the right answer).

If IsReady, ConvertToX, and GetColor can return errors then this isn't that far off. But then you're not making an apples to apples comparison. You would have to extend your functional example so that it also handles errors. Unless it already does, and I am missing something.

What I wrote should be pretty close to valid Scala, which handles exceptions. I can imagine wanting to skip an isReady failure, which looks like

  col.filter(c => Try(c.isReady).getOrElse(false))
  .map(convertToX).any(_.color == BLUE)

I see. Then in part the comparison is showing off exception handling, not FP.

Rust is a good example of functional lang without exceptions (panics aside).

In Rust there are many cases where I could use FP but opt not to because it can make error handling more awkward. For example to collect the result of a map operation to a vector, and if there is an error along the way you want to abort the entire operation. In functional this means collecting to a Result<Vec<T>>. Not sure if I'm just tired today but I can think of how to do it in 5 seconds with a loop. I suspect functional solution would be uglier.

Rust’s collect will do this for you. It’s even an example in the documentation.

Thanks! I learned something new.:)

https://doc.rust-lang.org/stable/rust-by-example/error/iter_...

This is easy to miss if you are mainly reading reference docs. I probably read the getting started guide at a time before there was a section on it.

My other comment in this thread comes to mind https://news.ycombinator.com/item?id=24300057

I was thinking of the final example in https://doc.rust-lang.org/stable/std/iter/trait.Iterator.htm... , glad we have it in both places!

I don’t personally really agree with what you’ve said, but that’s fine. Different people perceive things differently.

No problems. There are enough dimensions involved in what makes a language good that Im pretty sure I could rationalize why any language is better than another, measured along only one of them.

Robustness. Speed. Simplicity. Easiness. Conciseness. Writability. Readability.

Hard to tell which are independent vs correlated, let alone how they factor into productivity. And productivity is also a function of the kind of problem you work on.

This style makes developer forget the underlying costs though. It feels productive but it is harder to understand what work computer will do. Go is designed to be imperative, so is a complementary language.

That's true and we should embrace it. Higher-level languages should empower us. We should use profilers to measure actual bottlenecks when necessary, not make every potential bottleneck more painful to write and read forever.

I'm also majorly turned off by this attitude. We're knowledge workers - ostensibly paid nice salaries to think deeply and find reasonable solutions to hard problems, not just to turn a crank and shit out code as fast as possible. Sure, this is not your job 24/7, and there will always be boring code to write, but still, have some pride in your craft, you know?

The point of code is readability and runtime, not ego-stroking. Fast compile times are a bonus!

You can get a ton done in Typescript or Python or Ruby. And in addition to type systems being developed to assure type safety in the most dynamic of languages, you also can write tests and draw on the community knowledge of countless programmers who know your language. Obviously if performance & certain performance first libraries are first priority for you, choose a very computationally efficient lang. But it’s a toothless argument in 2020 to say when following best practices you are inevitably going to write flawed, incorrect code because you’re starting in a dynamic language.

Maybe you are not really taking full advantage of the powerful type system in typescript if you don’t see any lacks in go type system and if you think that using ‘any’ or the empty interface is perfectly normal?

>Golang was designed for getting shit done

That's indeed a good way to explain the utility driven nature of Go. I've been predominantly using OOP languages before and Go's deliberate lack of OOP features was although uncomfortable at first, the advantages of getting things done fast far outweighed it later when I released production applications with it.

>For me, Golang is like Python but with static typing and high performance. Fast to implement, easy to read, and focused on getting code out the door.

I was tired of adding disclaimer when teaching Python, that when you want to extract performance out of it you should also learn 'C/C++'. Go serves as a perfect replacement to Python where performance is a necessity, I don't see where that would be false in a production environment where 'code performance == capital efficiency'.