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

I want off Mr. Golang's Wild Ride (2020)

fasterthanli.me

Post reply on HN
Print view View original

21–30 of 38 posts

Re: I want off Mr. Golang's Wild Ride (2020)

#21

Post by EdSchouten »

The situation around alignment of integers for atomic operations is unfortunate. I think the cause for it is that they need to use a 4-byte alignment of int64 on 32-bit platforms to remain compatible with C when using cgo. Using an 8-byte alignment is also wasteful, considering that 4 bytes are sufficient and 64-bit atomic operations are relatively rare on 32-bit platforms.

One way to fix this would be to add a special language keyword to increase the alignment, but that feature doesn't really carry its own weight in a language like Go. In my opinion, life would be better if the atomic package didn't allow you to apply atomic operations against raw integers, but had its own boxed integer types that were guaranteed to be properly aligned. I implemented exactly this, because I also got bitten by this more often than I would like:

https://pkg.go.dev/github.com/buildbarn/bb-storage/pkg/atomi...

Now I don't need to worry about that problem anymore. It's annoying that the Go developers focus on stability so much, that the standard library hasn't really evolved a lot since 1.0, which seems to be main source of frustration for the author of this blog post.

What I do appreciate about Go is that cross compilation is pretty good, and the runtime environment also works pretty well. Some time ago I wanted to mmap() some file and also deal with page faults properly (e.g., in case of I/O errors, truncations of the file that's mapped). It turns out that Go can do that really well. Sure, you can install a signal handler for SIGSEGV in C and Rust, but the mechanics behind tend to be confusing.

Re: I want off Mr. Golang's Wild Ride (2020)

#22

Post by 37ef_ced3 »

brundolf wrote: post #6

The most insightful way I've ever heard Go described is as a "C fanfic". It's like a bunch of C programmers, writing software for web infrastructure, got together and made a wish-list of things they wanted to be different about C (specifically in the context of writing web infrastructure). And then they made a new language, taking the most direct path toward that wish-list, and inheriting most of C's other traits as…

Exactly

Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection

Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.)

Go puts essential C idioms directly into the language (pointer/length is formalized as slices, packages are part of the language instead of just being naming convention, etc.)

The longer I used C++, the more I despised it. I used C++ for 11 years and I literally hate the language. But C has always remained a pleasure, and Go is a continuation/modernization/enhancement of that

If you like C, you will love Go

Re: I want off Mr. Golang's Wild Ride (2020)

#23

Post by _y5hn »

37ef_ced3 wrote: post #22
brundolf wrote: post #6

The most insightful way I've ever heard Go described is as a "C fanfic". It's like a bunch of C programmers, writing software for web infrastructure, got together and made a wish-list of things they wanted to be different about C (specifically in the context of writing web infrastructure). And then they made a new language, taking the most direct path toward that wish-list, and inheriting most of C's other traits as…

Exactly Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized…

It's a feature for sure. The article was a refreshing read too! Of course, hiding and abstracting away much of what is available in C, will have issues when you have special needs. But it beats "make configure" any day, and works well when you just need something with decent speed and memory footprint to get the job done.

I'm enjoying all of what you mentioned above, and dislike languages that are more C/C++ like now, as you often get "un-bit" by these snags using Go. However, Go has some snags on its own (hello slices!), so it's good to make sure one learns the fundamentals and what works well. A bit sad when repos import hundreds of other packages, I just turn away from such offers. It's been the state of IT for past 20 years that everything is essentially garbage. This is nothing new, and one just need to pick one's poison as you go along.

Nothing is ever simple either. All the "better solutions" in Rust, is sure to need refactoring and updates, while Go-code can mostly continue to run as-is. That's a good aim for its niche. Though, we all know the underlying platforms are very diverse, complex and come with snags of their own. I don't think the aim of Go is to tackle them all like "make configure" attempt to though.

I'll be happy to learn Rust for some herculean effort sometime.

Re: I want off Mr. Golang's Wild Ride (2020)

#24

Post by 37ef_ced3 »

_y5hn wrote: post #23
37ef_ced3 wrote: post #22

Earlier quoted context omitted.

Exactly Go can be understood as an improved C that keeps much of C's simplicity but adds small, powerful features like interfaces and channels and garbage collection Go fixes C's well-understood flaws (declaration resembling use, unintuitive operator precedence, unrestricted address math, silent casting, zero-terminated strings, etc.) Go puts essential C idioms directly into the language (pointer/length is formalized…

It's a feature for sure. The article was a refreshing read too! Of course, hiding and abstracting away much of what is available in C, will have issues when you have special needs. But it beats "make configure" any day, and works well when you just need something with decent speed and memory footprint to get the job done. I'm enjoying all of what you mentioned above, and dislike languages that are more C/C++ like now…

Thanks for your comment

Picking up on one of your snags, Go's slices will "click" for you once you start thinking of it as a pointer and a length (and a capacity), but nothing more.

Realize it's just a C struct like this, passed by value:

  struct intSlice {
      int* addr;
      int len;
      int cap;
  };
The memory at addr is not owned by the slice. All the slice operations are simply notation for manipulating the struct. Go's garbage collection makes the whole thing work brilliantly

This can be confusing if you're used to std::vector (which owns the memory) or python's slices. Go's slices are a shallow pointer/length system exactly like is used in C all the time. For example:

  void sort(int* addr, int len);
becomes

  func sort(a []int)
A Go slice is just a pointer/length, with terse notation

Re: I want off Mr. Golang's Wild Ride (2020)

#26

Post by _y5hn »

37ef_ced3 wrote: post #24
_y5hn wrote: post #23

Earlier quoted context omitted.

It's a feature for sure. The article was a refreshing read too! Of course, hiding and abstracting away much of what is available in C, will have issues when you have special needs. But it beats "make configure" any day, and works well when you just need something with decent speed and memory footprint to get the job done. I'm enjoying all of what you mentioned above, and dislike languages that are more C/C++ like now…

Thanks for your comment Picking up on one of your snags, Go's slices will "click" for you once you start thinking of it as a pointer and a length (and a capacity), but nothing more. Realize it's just a C struct like this, passed by value: struct intSlice { int* addr; int len; int cap; }; The memory at addr is not owned by the slice. All the slice operations are simply notation for manipulating the struct. Go's garbag…

For me I just use what's available and do not go into too much detail beyond what I need. However, slices can be confusing at first, and your above example could help think of them the right way. Although, until you get "bit", you might not deduct the consequences of slices right away. Especially when accustomed to other languages.

The latest thing that made me go "hmm" last time, was this one (I didn't get "bit", just went "hmm" reading it):

https://play.golang.org/p/2bTvXr6WLNN

  package main
  
  import (
   "fmt"
  )
  
  func main() {
   b := []byte{'g', 'o', 'l', 'a', 'n', 'g'}
   fmt.Println(string(b[1:4]))
   // Output:
   // ola
  }
I'm sure everyone expected this output when using b[1:4], right? All languages do these things a bit differently, so is why I always forget the detailed syntax required. I'm sure there's a valid pragmatic explanation and there's lots of ways to do this (ie. allow negative values etc.). Just a thing that while speedtyping, one could easily miss this little detail.

This one is a good intro, but doesn't explain this I believe:

https://blog.golang.org/slices-intro

Re: I want off Mr. Golang's Wild Ride (2020)

#27

Post by magicman420 »

akvadrako wrote: post #12
gurjeet wrote: post #2

I have turned this comment into a blog post: https://news.ycombinator.com/item?id=25618264 It is a well written and in-depth look at the rot inside the Golang ecosystem. Make sure to read to the end and notice that the rot started at the core contributors level. Golang's tagline, from their [repository][0], is "Go is an open source programming language that makes it easy to build simple, reliable, and efficient softw…

As a systems developer with 20 years of experience in a variety of languages, I share your general frustration with Go. But I don't agree with any of the changes you suggested in GoFY.

Hey I saw a post you made about dmt and tinnitus. Same thing happened to me a few weeks back so I was researching to see if it gets better. Does it ever get quieter or will I have to hear through a ringing forever???

Re: I want off Mr. Golang's Wild Ride (2020)

#28

Post by hnarn »

mdtusz wrote: post #9
gnur wrote: post #7

I don’t think this should surprise anyone. Go is an excellent language for quick prototyping and easy distribution. The investment to become fluent in Go might literally be an order of magnitude less than becoming fluent in rust. Rust might be the perfect language in terms of capabilities and safety, but it is far from a simple language. The function signatures from even some simple methods have become ridiculous. I’…

Anecdotal, but I've found rust much easier to grok and become comfortable to work in than I have with Go - partially due to the docs, but largely because of the perceived complexity in explicitly typing and handling of options and results. With rust, I very rarely feel like the code I'm writing might not be correct for a technical reason, whereas with Go, I find myself very often having to think too much about how be…

Isn’t having to check for integer overflows in rust an example of the exact opposite of your example, or is this something that requires extra effort in go as well?

Re: I want off Mr. Golang's Wild Ride (2020)

#29

Post by sally1620 »

I don't think Go lies about what it is. It is just a victim of its popularity.

The authors clearly say that is designed for writing scalable networked services. And they definitely don't care about GUIs, Windows, embedded, etc.

Overzealous programmers are constantly taking Go where it is not meant to be and complain about its shortcomings. Go's simplicity means that it makes a lot of assumptions about the system. I think authors should have been more upfront and explicit about this.

Re: I want off Mr. Golang's Wild Ride (2020)

#30

Post by sally1620 »

brundolf wrote: post #6

The most insightful way I've ever heard Go described is as a "C fanfic". It's like a bunch of C programmers, writing software for web infrastructure, got together and made a wish-list of things they wanted to be different about C (specifically in the context of writing web infrastructure). And then they made a new language, taking the most direct path toward that wish-list, and inheriting most of C's other traits as…

I honestly think of Go as Java with an appeal to C programmers. And of course much better performance/memory usage than Java.

Go is a high-level language. It is not meant for low-level programming. and yet the authors keep claiming that it is.

Post reply on HN