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

Go Replaces Interface{} with 'Any'

github.com

Post reply on HN
Print view View original

191–200 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#191

Post by wheybags »

geofft wrote: post #150
keithnz wrote: post #39

Earlier quoted context omitted.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

Semantic versioning solves one specific problem that's worth solving - whether you can (expect to) automatically upgrade. That is a problem people have with languages just as much as libraries, and it is a problem that affects both big changes and small just as much as it affects libraries. It is not the only way to solve this problem, but that problem very much needs to be addressed. When a language adds any feature…

Windows (and vs) version numbers are a pain in the ass though. Constantly need to check that the version you need to put in some config file actually corresponds to the version you really mean.

Re: Go Replaces Interface{} with 'Any'

#192

Post by kaba0 »

peoplefromibiza wrote: post #106
the_duke wrote: post #58

Earlier quoted context omitted.

Emulating sum types in languages without pattern matching is extremely awkward, to the point of being almost useless. type Result[T] struct { ok: *T err: error } Great, so how do you work with it? * You can have a `ok()` getter that returns `*T`. Now you you need an `if x != nil` * `isOk()` + `isErr()` * `unwrap() T`, which panics on errors * `split() (*T, err)` that splits into separate values, especially awkward si…

you can map on ok which is an alias for map_ok and then map_err for errors and or_else or_throw etc. that's similar to what Java does with the Optional type, not great, but not bad either the alternative is checking for nulls which is worse in any possibile way I usually implement something like Kotlin Result when I have to code in Java with a couple of static helpers to build the result: Result.success(T) Result.fai…

Nitpick, but I like to point out that Java’s exceptions are themselves a Result type/analog with them. You can unwrap it by a try catch, and can choose to rethrow it with minimal syntax. It even has a plus, it will auto-attach a stacktrace to the error case.

Re: Go Replaces Interface{} with 'Any'

#193

Post by kaba0 »

geodel wrote: post #180
linkdd wrote: post #88

Earlier quoted context omitted.

An exception has a stacktrace. This single piece of information is crucial when you debug and makes handling errors in Golang embarrassing. I rest my case.

Yea, I am not really fan of 1000 line stack trace for an error in single line. I like Go's error handling better. Also it is clear you like error handling in Rust/Java etc which is fine. Exaggerating over how bad error handling in Go is hardly productive when a) many people do like it b) people can switch language when error handling primary concern over everything else.

How will you fix that bug in production when you can’t reproduce it and only has logs? Stacktraces are godsend.

Re: Go Replaces Interface{} with 'Any'

#194

Post by geofft »

wheybags wrote: post #191
geofft wrote: post #150

Earlier quoted context omitted.

Semantic versioning solves one specific problem that's worth solving - whether you can (expect to) automatically upgrade. That is a problem people have with languages just as much as libraries, and it is a problem that affects both big changes and small just as much as it affects libraries. It is not the only way to solve this problem, but that problem very much needs to be addressed. When a language adds any feature…

Windows (and vs) version numbers are a pain in the ass though. Constantly need to check that the version you need to put in some config file actually corresponds to the version you really mean.

I haven't seen anyone do a good job of it, but it seems to me that if you wanted to try, the way to do it would be to make the marketing versions and compatibility versions so different that they can't be confused (like Windows 95 or better yet XP, not Windows 7) - and then make sure that your configuration files can accept marketing versions and silently transform them to compatibility versions.

Re: Go Replaces Interface{} with 'Any'

#195

Post by kubb »

rp1 wrote: post #164
kubb wrote: post #159

Earlier quoted context omitted.

I would also like discriminated unions, and a more sane approach to code generation than go generate and writing your own binary that parses source and spits out source code.

The Go code parsing libraries are quite good though. Not sure what else you could want re. code generation.

Basically macros, like in Rust, not like in C. Rust can do stuff like the serde serialization library while Go has to rely on reflection with its obvious performance drawbacks.

Re: Go Replaces Interface{} with 'Any'

#196

Post by zemo »

hamburglar wrote: post #42
mseepgood wrote: post #23

Earlier quoted context omitted.

Modules don't require any particular directory structure, just a go.mod at the root of your project.

That’s “a particular directory structure” that conflicts with many already-existing projects. What if I have a mostly-java project that has a couple bits of go code buried in it that I want to use as modules? Break it up into multiple repos for no good reason? No single tool should be acting like it owns the root directory of my repo.

I hate this pattern too but there's not "no good reason", there's a specific reason why it's like this, and it's a conscious design choice.

When you call `go get somedomain.com/whatever/thing`, what it does is makes an HTTP request to that URL, then looks for a `` tag on the page telling it where to download the module. Check out the source of any Go project on github and you'll find the relevant `` tag. Here's the meta tag for the gorilla router, a common http routing library:
The tool is designed so that you can serve modules directly from version control repositories, because the goals were to avoid having any central authority on modules. It turns out this is a huge win in terms of making it dramatically easy to empower people to release modules, AND a huge win for decentralization: if you can host a git repository, the git repository is the module source, and that's the entire system. Just use Go as normal and make a public github repo and it's automatically importable through `go get`. No central registry required.

It's a tradeoff. In making it "one module per repo", it dramatically lowered the barrier to entry for producing modules that other people could adopt right away, but it requires that you have one module per repo, because the versioning scheme is based on tags having semver version strings in them.

Could they have made it something like "a tag can specify a directory and a version"? Hahha, yeahhhhhhhhhhh probably. But they didn't.

In any case, you can also serve modules out of a go module proxy directly, but then you have to set that up yourself. That would free you of the "one module per repo" thing, but now you don't get "a repo is automatically accessible as a Go module". You'd have to implement the Go module proxy protocol yourself. I'm ... doing this now in my spare time but it's not really ready to share yet.

The protocol is actually super easy to implement. It's described here: https://go.dev/ref/mod#goproxy-protocol

Re: Go Replaces Interface{} with 'Any'

#197

Post by halfmatthalfcat »

jchw wrote: post #84
welder wrote: post #70

Good, now we just need the ability to declare function parameters and return values non-nullable (Forbid passing nil into a function, and declare a function will never return nil). That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors. https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...

I’d kill for union types as well. … and pattern matching. Maybe just some extensions for `switch`. … and one of the `try` proposals. That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great toget…

At that point, let's just write Scala.

Re: Go Replaces Interface{} with 'Any'

#199

Post by xh-dude »

AtNightWeCode wrote: post #82
jjice wrote: post #67

Earlier quoted context omitted.

Doesn't 'for' work as 'while' if you only give it a condition in go? I haven't written much, so correct me if I'm wrong.

Does not Interface{} work as well as Any? I mean, most languages have while-statements cause it is more clear what the intention is.

OTOH there’s no ‘while true’ or do-while or while-do, none of which are particularly fluent.

Re: Go Replaces Interface{} with 'Any'

#200

Post by DarylZero »

keithnz wrote: post #39
philwelch wrote: post #7

Earlier quoted context omitted.

In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.

Sure, but semantic versioning really is the wrong kind of versioning to use for a language. The major version should represent major language changes, not whether its a breaking change or not, semantic versioning isn't somehow magically a "good" way to version. It's useful for libraries / dependencies where you are dealing with many different libraries and just want to know you can upgrade without having to deal with…

I agree.

Also they may have sneaked it in because they're implicitly acknowledging fault in their previous design decision to exclude it.

Post reply on HN