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

161–170 of 280 posts

Re: Go's Sweet 16

#161

Post by kccqzy »

kermatt wrote: post #36
roncesvalles wrote: post #23

Earlier quoted context omitted.

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "part…

> 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?

Rust is very advanced, with things like higher-ranked trait bounds (https://doc.rust-lang.org/nomicon/hrtb.html) and generic associated types (https://www.ncameron.org/rfcs/1598) that are difficult because they are essential complexity not accidental complexity.

Re: Go's Sweet 16

#162

Post by HL33tibCe7 »

culebron21 wrote: post #111
Mawr wrote: post #107

Earlier quoted context omitted.

> it lacks iterators -- every time you must write a big cycle instead It has iterators - https://pkg.go.dev/iter . > It lacks simple things like check if a key exists in a map. What? `value, keyExists := myMap[someKey]` > Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is…

> `value, keyExists := myMap[someKey]` If I don't need the value, I have to do awkward tricks with this construct. like `if _, key_exists := my_may[key]; key_exists { ... }`. Also, you can do `value := myMap[someKey]`, and it will just return a value or nil. Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. This construct (assigning from map subscript) is pure magic, de…

> But it's not easier at all, and learning curve just moves to another place.

Hard disagree. Go has its sharp corners, but they don’t even approach the complexity of the borrow checker of Rust alone, let alone all of the other complexity of the Rust ecosystem.

Re: Go's Sweet 16

#163

Post by zimpenfish »

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.

I may have misunderstood "you can't just concatenate different slices (e.g. to remove one item from the middle" but does [0] not do what you're talking about?

(with the caveat that anything else sharing `a` will be mangled, obvs.)

[0] https://go.dev/play/p/uQdoa3mUF00

Re: Go's Sweet 16

#164

Post by klooney »

stackghost wrote: post #77
throwaway894345 wrote: post #75

Earlier quoted context omitted.

When Go was new, having better package management than Python and C++ was saying a lot. I’m sure Go wasn’t the first, but there weren’t many mainstream languages that didn’t make you learn some imperative DSL just to add dependencies.

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.

Re: Go's Sweet 16

#165

Post by HL33tibCe7 »

culebron21 wrote: post #159
lenkite wrote: post #148

Earlier quoted context omitted.

> Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. Err, no Go doesn't do that. No insertion happens unless you explicitly assign to the key.

You're right. But it will return something: https://go.dev/play/p/Cz6aeGpURgo my_map := make(map[int32][]int64) val := my_map[123] val = append(val, 456) my_map[123] = val fmt.Println(my_map) prints `map[123:[456]]` I guess it's convenient compared to Rust's strict approach with entry API. But also, what I found is that golang's subscript returns nil in one case: if the value type is a nested map. my_map := make(map[…

It returns the zero value for all types, including arrays (which is nil).

nil is equivalent to the empty array, which is why the rest of the code works as it does.

Re: Go's Sweet 16

#166

Post by HL33tibCe7 »

kellpossible2 wrote: post #72
MichaelNolan wrote: post #6

Go would probably be my favorite language if it just had a few more features around functional programming. Specifically around immutability and nullness, and maybe exhaustive switch statements. Then it just might be perfect. At work we use Uber’s NillAway, so that helps bit. https://github.com/uber-go/nilaway Though actually having the type system handle it would be nicer.

Go with Sum types and no nil pointers would be fantastic! Is it too much to dream of? It feels like Gleam gets pretty close but it flies off in a bunch of other directions.

vlang is pretty much this

Re: Go's Sweet 16

#167

Post by zimpenfish »

culebron21 wrote: post #111
Mawr wrote: post #107

Earlier quoted context omitted.

> it lacks iterators -- every time you must write a big cycle instead It has iterators - https://pkg.go.dev/iter . > It lacks simple things like check if a key exists in a map. What? `value, keyExists := myMap[someKey]` > Try removing an element from an array - you must rely on some magic and awkward syntax, and there's no clear explanation what actually happens under the hood (all docs just show you that a slice is…

> `value, keyExists := myMap[someKey]` If I don't need the value, I have to do awkward tricks with this construct. like `if _, key_exists := my_may[key]; key_exists { ... }`. Also, you can do `value := myMap[someKey]`, and it will just return a value or nil. Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. This construct (assigning from map subscript) is pure magic, de…

> Also, you can do `value := myMap[someKey]`, and it will just return a value or nil.

It might if your map is a `map[typeA]*typeB` but it definitely won't return a `nil` if your map is anything like `map[typeA]typeC` (where `typeC` is non-nillable; i.e. int, float, string, bool, rune, byte, time.Time, etc.) - you'll get a compile error: "mismatched types typeC and untyped nil".

Re: Go's Sweet 16

#168

Post by tiltowait »

culebron21 wrote: post #159
lenkite wrote: post #148

Earlier quoted context omitted.

> Also, if the map has arrays as elements, it will magically create one, like Python's defaultdict. Err, no Go doesn't do that. No insertion happens unless you explicitly assign to the key.

You're right. But it will return something: https://go.dev/play/p/Cz6aeGpURgo my_map := make(map[int32][]int64) val := my_map[123] val = append(val, 456) my_map[123] = val fmt.Println(my_map) prints `map[123:[456]]` I guess it's convenient compared to Rust's strict approach with entry API. But also, what I found is that golang's subscript returns nil in one case: if the value type is a nested map. my_map := make(map[…

You can test for existence:

    val, ok := my_map[123]
    if ok {
        ...
    }
https://go.dev/blog/maps#working-with-maps

Re: Go's Sweet 16

#169

Post by linhns »

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…

Agreed. This use case is not mentioned enough.

Re: Go's Sweet 16

#170

Post by bobbylarrybobby »

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.

I mean, it is as easy as you think in a GC language
Post reply on HN