151–160 of 223 posts
I think Golang is awesome, but I have two major gripes that I hope can be fixed: Dependency management: Go mods is a dumpster fire. `go get` and `go install` is finicky and inconsistent across systems. It's difficult to import local code as a dependency. Using mods with replace feels like a shitty hack, and requires me to maintain a public repo for something I may not want to be public. I end up using ANOTHER hack th…
What would you need those for? For checking exhaustive type switches? Seems like an extra keyword on "interface" would do the trick.
Earlier quoted context omitted.
Have you considered elaborating? I am likewise unsure how a language could get enums wrong, even after reading your post.
> I am likewise unsure how a language could get enums wrong, even after reading your post. By allowing any value of the underlying type, even if they were not values of the enum. The language most famous for this is obviously C: enum foo { A, B, C }; int main() { enum foo x = A; printf("%d\n", x); enum foo y = 42; printf("%d\n", y); } This will print `0` and `42` ( https://godbolt.org/z/Yq8qq5bzW ), because C conside…
I think Golang is awesome, but I have two major gripes that I hope can be fixed: Dependency management: Go mods is a dumpster fire. `go get` and `go install` is finicky and inconsistent across systems. It's difficult to import local code as a dependency. Using mods with replace feels like a shitty hack, and requires me to maintain a public repo for something I may not want to be public. I end up using ANOTHER hack th…
With regards to this concern at least go 1.18 is adding workspaces, which should help (https://sebastian-holstein.de/post/2021-11-08-go-1.18-featur...).
Earlier quoted context omitted.
> Not vice versa (the current design). select { case: chan3_whichItreatTheSameAsChan2 }
Yes, as I have mentioned, there is performance loss, comparing to select { case: chan3_whichItreatTheSameAsChan2 }
2) What in the world do you need such code for?
I think Golang is awesome, but I have two major gripes that I hope can be fixed: Dependency management: Go mods is a dumpster fire. `go get` and `go install` is finicky and inconsistent across systems. It's difficult to import local code as a dependency. Using mods with replace feels like a shitty hack, and requires me to maintain a public repo for something I may not want to be public. I end up using ANOTHER hack th…
What you describe for JSON is already the case in Go; the stdlib json parser does simply throw out any extra fields on deserialisation.
From Rob Pike on reddit regarding this post[0]: The and and or functions in the template packages do short-circuit, so he's got one thing already. It was a relatively recent change, but it's there. Non-deterministic select is a critical detail of its design. If you depend on a deterministic order of completion of tasks, you're going to have problems. Now there are cases where determinism might be what you want, but t…
> but (deterministic-select cases) hey are peculiar. It looks for most select blocks in Go code, it doesn't matter whether or not they are non-deterministic or deterministic. But, if the default is deterministic, user code could simulate non-deterministic, without much performance loss. Not vice versa (the current design).
Austin Clements (of the Go runtime team) wrote a paper that explores this in detail [1]. That was before joining the Go team, but the concepts are universal.
[1] https://people.csail.mit.edu/nickolai/papers/clements-sc.pdf
I would add: an extended standard library for "common stuff". I don't want to import a third-party library nor write my own "utils.go" to do: func contains(s []int, e int) bool { for _, a := range s { if a == e { return true } } return false }