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

Go's Sweet 16

go.dev

Post reply on HN
Print view View original

181–190 of 280 posts

Re: Go's Sweet 16

#181

Post by anal_reactor »

LexiMax wrote: post #70
MagicMoonlight wrote: post #62

I just can’t get over the idiotic syntax. Instead of “int x” You have “var x int” Which obscures the type, making it harder to read the code. The only justification is that 16 years ago, some guy thought he was being clever. For 99.99% of code, it’s a worse syntax. Nobody does eight levels of pointer redirection in typical everyday code.

16 years is a bit of an under-estimate. I think the first popular language with this form of declaration was Pascal. var foo: char; Go was developed by many of the minds behind C, and inertia would have led them to C-style declaration. I don't know if they've ever told anybody why they went with the Pascal style, but I would bet money on the fact that Pascal-style declarations are simply easier and faster for compute…

Golang exists in this weird place where it's similar enough to C so that intuition connects it with C, but at the same time different enough that you keep tripping over.

Re: Go's Sweet 16

#182

Post by stackghost »

klooney wrote: post #164
stackghost wrote: post #77

Earlier quoted context omitted.

Sure, but all those languages didn't have the psychotic design that mandated all your code lives under $GOPATH for the first several versions. I'm not saying it's awful, it's just a pretty mid language, is all.

I never understood the GOPATH freakout, coming from Python it seemed really natural- it's a mandatory virtualenv.

The fact that virtualenv exists at all should be viewed by the python community as a source of profound shame.

The idea that it's natural and accepted that we just have python v3.11, 3.12, 3.13 etc all coexisting, each with their own incompatible package ecosystems, and in use on an ad-hoc, per-directory basis just seems fundamentally insane to me.

Re: Go's Sweet 16

#183

Post by jrpelkonen »

pclmulqdq wrote: post #128
kermatt wrote: post #36

Earlier quoted context omitted.

> I'm convinced no more than a handful of humans understand all of C# or C++ How would the proportion of humans that understand all of Rust compare?

I'm pretty convinced that nobody has a full picture of Rust in their head. There isn't even a spec to read.

There is, in fact, a spec to read[1], as of earlier this year.

[1] https://rustfoundation.org/media/ferrous-systems-donates-fer...

Re: Go's Sweet 16

#184

Post by 9rx »

culebron21 wrote: post #110
9rx wrote: post #98

Earlier quoted context omitted.

> Well, then they look awkward and have give a feel like it's a syntax abuse. So nothing to worry about? > how do I insert an element in the middle of an array? Same as in C. If the array allocation is large enough, you can move the right hand side to the next memory location, and then replace the middle value. Something like: replaceWith := 3 replaceAt := 2 array := [5]int{1, 2, 4, 5} size := 4 for i := size; i > re…

Ok, so mostly we agree. And I was right that you can't just concatenate different slices (e.g. to remove one item from the middle), hence Go has to do a lot of work under the hood to do that. I count this as magic.

> Ok, so mostly we agree.

I don't follow. Information isn't agreeable or disagreeable, it just is.

> And I was right that you can't just concatenate different slices

That's right. You would have to physically move the capacitors in your RAM around (while remaining powered!) in order to do that. Given the limits of our current understanding of science, that's impossible.

> hence Go has to do a lot of work under the hood to do that.

Do what? You can't actually do that. It cannot be done at the hardware level. There is nothing a programming language can do to enable it.

All a programming language can do is what we earlier demonstrated for arrays, or as slices allow dynamic allocation, if the original slice is not large enough you can also copy smaller slices into a new slice using a similar technique to the for loop above.

Go does offer a copy function and an append function that do the same kind of thing as the for loop above so you do not have to write the loop yourself every time. I guess that's what you think is magic? If you are suggesting that calling a function is magic, well, uh... You're not going to like this whole modern programming thing. Even Rust has functions, I'm afraid.

The Go standard library also provides a function for inserting into the middle of a slice, but, again, that's just a plain old boring function that adds some conditional logic around the use of the append and copy functions. It is really no different to how you'd write the code yourself. So, unless function are still deemed magic...

Re: Go's Sweet 16

#185

Post by insurancesucks »

Every Go thread on this site is the same.

"Man I love Go, it's so simple, plenty fast, really easy to pick up, read, and write. I really love that it doesn't have dozens of esoteric features for my colleagues to big brain into the codebase"

"Oh yeah? Well Go sucks, it doesn't have dozens of esoteric features for me to big brain into the codebase"

Repeat

Re: Go's Sweet 16

#186

Post by ErroneousBosh »

throw1111221 wrote: post #50
Xeoncross wrote: post #3

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm…

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduc…

> This is why unused dependencies are a compile time error.

I think my favourite bit of Go opinionatedness is the code formatting.

K&R or GTFO.

Oh you don't like your opening bracket on the same line? Tough shit, syntax error.

Re: Go's Sweet 16

#187

Post by wredcoll »

liveoneggs wrote: post #173
liampulles wrote: post #133

I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily. This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin…

I don't understand how this isn't also true for practically every other language?

The distinction, I believe, is between "possible" and "easy". Go makes a lot of very specific things easy via some of its design choices with language and tooling.

As a counter example, it seems like e.g. c++ is mostly concerned about making things possible and rarely about easy.

Re: Go's Sweet 16

#189

Post by 9rx »

callc wrote: post #136
pekim wrote: post #101

Earlier quoted context omitted.

Inserting elements in to a slice can be done quite easily since the introduction of the slices package to the standard library. https://pkg.go.dev/slices#Insert

You shouldn’t need a library to do this simple operation. I’m guessing the go language design went too far into “simplicity” at the expense of reasonableness. For example, we can make a “simpler” language by not supporting multiplication, just use addition and write your own!

The operation is simple in concept, but can be costly from a compute standpoint when n is large. Multiplication has predicable performance. Insert does not. It being a function indicates that it is doing a lot of things and thus offers pause to make sure that the operation is acceptably within your operational bounds.

It could have been a builtin function, I suppose, but why not place it in the standard library? It's not a foundational operation. If you look at the implementation, you'll notice it simply rolls up several foundation operations into one function. That is exactly the kind of thing you'd expect to find in a standard library.

Re: Go's Sweet 16

#190

Post by dilyevsky »

EnergyAmy wrote: post #147
tptacek wrote: post #141

Earlier quoted context omitted.

I wish Go had sum types too. But I like being able to write a mutable tree structure without first having to read a whole book on the subject and inventing a new system of pointers. Every language is tradeoffs.

I like the language saying "it's not as easy as you think" when I'm about to do something ill-advised like roll my own mutable tree structure.

It is in fact not that hard when your memory is automatically managed
Post reply on HN