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

431–440 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#431

Post by mariusor »

linkdd wrote: post #86
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…

The Rust Result type has: - map / map_err - and_then / or_else - unwrap / unwrap_or And countless of other functions making it very practical to chain computations without having to pattern match anything. I do the same in Erlang/Elixir. In Golang, I need to check every function call, and if I want to know where an error come from, I need to wrap it in an errors.New() because no exceptions = no stacktrace

Stack traces exist in go[1], I'm not sure why you consider exceptions to be the only way of getting a stack representation.

Not to mention that traditional exception handling advice I've been handed down from the gray beards is to always handle exceptions as early as possible, which is exactly what go forces you to do with their approach.

[1] https://pkg.go.dev/runtime/debug#Stack

Re: Go Replaces Interface{} with 'Any'

#432

Post by cortesoft »

MereInterest wrote: post #303
cortesoft wrote: post #91

Earlier quoted context omitted.

Wait, why wouldn’t it matter for a language? I want to know if I can compile my existing project with the new version… isn’t that an important thing to know?

Because in most languages, maintaining backwards compatibility is absolutely sacrosanct. It's not that you check the version number to know if your code will still compile. You check the name of the language to know if your code will still compile. (Yes, there are exceptions to this, but those tend to be cautionary tales. Python 3 is a better language than Python 2, but took a decade to gain adoption because it broke…

I dont know if backwards compatibility is absolutely sacrosanct in most languages... for C/C++, sure... but I know Rust has broken backwards compatibility before, as has Python as you mention, and Ruby, too. I don't think it is as sacrosanct as you think it is, especially for relatively new languages under heavy development.

Re: Go Replaces Interface{} with 'Any'

#433

Post by stormbrew »

msbarnett wrote: post #424
stormbrew wrote: post #363

Earlier quoted context omitted.

I did not in any way shape or form "propose a scheme." I pointed out what I perceive to be a limitation in semver to describe some kinds of changes in some kinds of things in practical terms. These replies are incredibly and bizarrely dogmatic. I never knew it'd be so hard to have a discussion about semver without people just going "semver is semver" as if that means something.

> These replies are incredibly and bizarrely dogmatic. I never knew it'd be so hard to have a discussion about semver without people just going "semver is semver" as if that means something. You seem to have misunderstood. We're not pointing out that "semver is semver", we're pointing out that semver as defined with respect to compilers, which is to say, the ability of existing code to run with a new version of the c…

The dogmatism I'm perceiving here is at least in part that you're applying an extremely black and white approach to this. There are many possibilities between semver and "the opposite of semver", and there are options that exist along other axes from semver as well. The only way what you're saying here makes much sense to me is if you define "opposite of X" to be "anything that is not X", which is.. weird.

And again, I did not propose "the opposite of semver" or anything else. I said "some changes are poorly described by semver". It's a big leap from that to "I know exactly what you have in mind and it is every change is a major change." Which I... did not say anywhere?

Though, I do think that, as I mentioned elsewhere, this is approximately the net practical effect of using semver for things that have a principled opposition to breaking of backwards compatibility. If you never go to '2.0.0' then the '1.' part of '1.234234.0' is meaningless. Your version is just 234234.0 and you're playing the same game of pretend that '0.x' does in semver only with a bigger number. Again though, this is not me proposing that, it is me observing that the thing you're arguing against is possibly what's really happening anyways.

Re: Go Replaces Interface{} with 'Any'

#434

Post by skybrian »

tgv wrote: post #327
skybrian wrote: post #298

Earlier quoted context omitted.

Go has function literals, which are basically lambdas but a bit more verbose. Typical Go style doesn’t use them as often as other languages. You might assign one to a variable, giving you an inner function. But loops are usually written as for loops, not map calls. One API call that comes to mind where you might use one is ast.Inspect. [1] Go often works well for replacing shell scripts, even without generics. [1] ht…

> Go often works well for replacing shell scripts, even without generics. That’s selling the language short. Way too short.

Understatement is easier than making a stronger case for it, and my Go experience is somewhat out of date.

Re: Go Replaces Interface{} with 'Any'

#435

Post by skybrian »

Aeolun wrote: post #283
bearcherian wrote: post #236

Earlier quoted context omitted.

If you're main problem with a new language is that it's not written like the language you are used to, you're not going to be happy with the new language.

Hence I’m not happy with anything that doesn’t look like Java. Go seems amazing otherwise, but I cannot get over the fact that it forces me to capitalize or not capitalize my variables, and has types in the wrong order.

You might like Dart better then.

Re: Go Replaces Interface{} with 'Any'

#436

Post by msbarnett »

stormbrew wrote: post #433
msbarnett wrote: post #424

Earlier quoted context omitted.

> These replies are incredibly and bizarrely dogmatic. I never knew it'd be so hard to have a discussion about semver without people just going "semver is semver" as if that means something. You seem to have misunderstood. We're not pointing out that "semver is semver", we're pointing out that semver as defined with respect to compilers, which is to say, the ability of existing code to run with a new version of the c…

The dogmatism I'm perceiving here is at least in part that you're applying an extremely black and white approach to this. There are many possibilities between semver and "the opposite of semver", and there are options that exist along other axes from semver as well. The only way what you're saying here makes much sense to me is if you define "opposite of X" to be "anything that is not X", which is.. weird. And again,…

My observation is merely that every additive change breaks the ability of new code to work with old compilers, and that it would be really, really weird to have a system in which you bump a major version because old code continues to work, but bump a minor when it would break or something.

If you "aren't proposing" that, then all you seem to be saying is "I think sometimes major versions should signal that they break compatibility with old code and sometimes they should signal that they maintain compatibility with old code because of some never-promised loss of reverse compatibility with new code on old compilers" which ... sounds uninteresting, unreliable, and frankly terrible from the standpoint of anyone who wants automated tooling to be able to make decisions based on signals in the version numbers (which, while not 100% reliable, is still a huge win over the old days of "versions can just be whatever, man" imo)

Re: Go Replaces Interface{} with 'Any'

#437

Post by echlebek »

hamburglar wrote: post #115
mseepgood wrote: post #89

Earlier quoted context omitted.

As far as I know this was always possible since modules were introduced. You just have to prefix the version tags for Go with the subdirectory in the repo: "my/sub/directory/vX.Y.Z"

I swear it didn’t always work this way, but I’m happy to be wrong.

The only difference is that you are expected to tag differently. For instance if you had reporoot/hello/go.mod, you would create tags like hello/v1.2.3

Re: Go Replaces Interface{} with 'Any'

#438

Post by int_19h »

notfed wrote: post #295
garmaine wrote: post #285

Earlier quoted context omitted.

Arguably a language should NEVER have breaking changes large enough to warrant a SemVer major version update. Rename or fork the language if you want to do that. Such major language overhauls in the past have been a huge waste of developer time as they go back to rewrite affected code.

Java 10 introduced "var", which broke code with variables named "var". I'm glad they did not introduce a new language JavaWithVar.

It's not the only two choices available. C# also introduced var back in version 3 (2008), but it did it as a "contextual keyword" - meaning that it remains a valid identifier in any position where it used to be one, even to this day. Pretty much all new C# keywords since the very first version are of this nature:

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

Re: Go Replaces Interface{} with 'Any'

#439

Post by int_19h »

dragonwriter wrote: post #311
garmaine wrote: post #308

Earlier quoted context omitted.

That wouldn't be large enough a change to warrant a new major SemVer. I'm talking about things like python2 -> python3.

> That wouldn't be large enough a change to warrant a new major SemVer. Yes, it would. Breaking is breaking.

Whether something is breaking or not is not always clear-cut. For one thing, changes can become breaking in retrospect sometimes. For example, in C#, renaming a method argument wasn't breaking until the language introduced named arguments in calls.

There are also changes which are breaking in a very non-obvious way, to put it mildly. For example, in C# again, adding any new member to a class can break existing code that happens to pass implicitly typed lambdas to overloaded methods, because overload resolution involves checking whether the lambda body is valid for a given candidate - thus, adding a member can make a lambda ambiguous. I'm not aware of anyone actually treating this as a breaking change for semver purposes, though.

Re: Go Replaces Interface{} with 'Any'

#440

Post by lolive »

zerocount wrote: post #371
drvd wrote: post #329

Earlier quoted context omitted.

> I am [...] quite experienced in Java and Js/Ts. > I never jumped the Go bandwagon because of the lack of generics. > Can I now try Go? Probably no. You still would be very disappointed. Go's take at writing and maintaining software often is pretty repugnant to people with a strong Java or JavaScript mindset. If missing user defined parametric polymorphism ("generics") was a reason to not even _try_ it you will be o…

I don't understand why you're lumping JavaScript in with Java. These are very different languages and are likely to produce very different mindsets.

I think here JavaScript is a misnomer for Typescript. [At least that's how I did read the parent post]
Post reply on HN