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

391–400 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#391

Post by usrusr »

dragonwriter wrote: post #316
garmaine wrote: post #314

Earlier quoted context omitted.

Nearly every big fix in an API is technically a breaking change if you want to be pedantic. This kind of collateral damage which requires multiple points of failure doesn’t usually count as a semantic major change.

> Nearly every big fix in an API is technically a breaking change if you want to be pedantic. A fix is not a breaking change in the API, because “breaking” refers to expected behavior (so, yes, code that relies on a bug can be broken by a fix; presumably, if you've coded to an observed behavior differing from the spec you are aware of having done so.)

Does an example of semver used in a non-pedantic way even exist?

The perfect simple world that a naive interpretation of semver dreams of leads to those endless streams of major.0.0 increments fueled by better safe than sorry. "You have been warned, your code might break, no promises". After all there could always be some xkcd 1172 "every change breaks someone's workflow". In an infinite universe of monkeys on typewriters someone would have set up mission critical infrastructure based on an elaborate log4jndi deploy mechanism.

On the other extreme you have something like Java that's in the process of dropping a frozen first digit ever since 1.2. Sure, this predates semver by quite some time but if we'd try to designate meaningful major.minor.patch names in hindsight we'd certainly not go exclusively by the occasional new keywords in the syntax like var but by new feature groups like generics, lambdas and the like, most of which have been introduced without invalidating any old syntax.

"We're awesome at backwards compatibility, but this change is noteworthy enough to warrant a major, better introduce some artificial incompatibility" is something that should never happen.

Re: Go Replaces Interface{} with 'Any'

#393

Post by absove »

kaba0 wrote: post #192
peoplefromibiza wrote: post #106

Earlier quoted context omitted.

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.

Not so much a nitpick because with checked exceptions your method signature can declare multiple types of exception whereas Result generalizes your specific exceptions to Throwable, which you can't pattern match with the compiler being able to enforce exhaustiveness.

So to achieve the same exhaustiveness as a method like

User createUser() throws IOException, BusinessException

you would need both a Result-like construct and union types

Either createuser()

which few mainstream languages offer. Otherwise you type is unable to express that only IOException and BusinessException are thrown and you don't need to handle a default Throwable case.

Re: Go Replaces Interface{} with 'Any'

#394

Post by codeflo »

BatteryMountain wrote: post #354
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 actually agree with you. I'm mostly a C# developer that uses a ton of generics and when I tried Go previously I was disappointed that it didn't have generics. But I continued on. And so I found a handful of other things that would irritate me or would be an inconvenience versus doing the same thing in C#. So generics alone is not the main problem here, it is going from a C#/Java mindset to a Go mindset. In some way…

I personally don’t get bored when a tool is “too simple”, but when it forces me to do things by hand that the machine should be able to do. Like manually specializing a generic concept. I didn’t become a programmer out of love for repetitive tasks!

Re: Go Replaces Interface{} with 'Any'

#395

Post by pawelmurias »

jshen wrote: post #233
pawelmurias wrote: post #163

Earlier quoted context omitted.

A language shouldnt be optimized towards doc avoiding newbies at the cost of making things verbose and ugly.

Go is the most readable language I’ve used in terms of understanding other peoples complex code bases, and I’ve been doing this a long time and have used a lot of languages. Edit: It’s also one of the most approachable languages.

This change is intended to be used to avoid using interface{} with generics which aren't used by existing code

Re: Go Replaces Interface{} with 'Any'

#396

Post by BatteryMountain »

codeflo wrote: post #394
BatteryMountain wrote: post #354

Earlier quoted context omitted.

I actually agree with you. I'm mostly a C# developer that uses a ton of generics and when I tried Go previously I was disappointed that it didn't have generics. But I continued on. And so I found a handful of other things that would irritate me or would be an inconvenience versus doing the same thing in C#. So generics alone is not the main problem here, it is going from a C#/Java mindset to a Go mindset. In some way…

I personally don’t get bored when a tool is “too simple”, but when it forces me to do things by hand that the machine should be able to do. Like manually specializing a generic concept. I didn’t become a programmer out of love for repetitive tasks!

For some people building "complex" things is how they attach sense of accomplishment to programming. If it is not complex, it is just boring or just a toy, hence not worthy of their attention.

Golang is waaay simpler than other languages, as some were designed to be arcane from the start and other became that way over time. So Go's stewards have been doing a good job of enforcing their philosophy so that it doesn't become a bloated monster.

Re: Go Replaces Interface{} with 'Any'

#397

Post by Intermernet »

eru wrote: post #293
ImprobableTruth wrote: post #248

Earlier quoted context omitted.

Go has lambdas https://go.dev/ref/spec#Function_literals

Yes, but without generics it's hard to do much useful with lambdas in your statically typed language. You can't even write a filter or map function. And eg Go's old workaround for polymorphic sorting functions was just atrocious: it was rather convoluted, and only really worked at all for in-place sorting.

"without generics it's hard to do much useful with lambdas in your statically typed language"

I challenge you to read the source for the Go standard library and maintain that position. Lambdas are orthogonal to generics in pretty much every aspect. You need to stop thinking in terms of "filter or map". Programming languages that didn't include these idioms existed long before Go, and will exist long after Go.

I welcome the introduction of generics, but I still don't have many places in many code-bases where they'll be used.

Re: Go Replaces Interface{} with 'Any'

#398

Post by pjmlp »

lanstin wrote: post #273
politician wrote: post #232

Earlier quoted context omitted.

Writing code for the happy path is 1/100th of programming. Maybe less.

There is a reason very robust software is written in C: no exceptions means you think about normal errors all the time and reason about what the difference bwtween an error openjng the file and an wrror writing the file. Sqlite, linux, cpython, all bullet proof and all C. The lack of exceptions more than makes up for memory unsafety issues.

Bullet proof you say, https://www.cvedetails.com/vulnerabilities-by-types.php

Re: Go Replaces Interface{} with 'Any'

#399

Post by Intermernet »

eweise wrote: post #35
mseepgood wrote: post #8

Earlier quoted context omitted.

Yes, it's not restricted to generics. But the reason the alias was introduced is generics. Because they use interfaces to specify bounds (constraints) for type parameters (bounded polymorphism): [T fmt.Stringer], [T io.Reader], ... So an unbounded type parameter is [T interface{}], or [T any] when using the shorter alias. It's a type alias / predeclared identifier defined in the universe scope: type any = interface{}

Couldn't unbounded just be [T]? Why the extra typing?

It's not really extra typing. It's just a syntactic convenience considered beneficial by the core team. It doesn't actually break compiler parsing in any way, but it may lead to human confusion in cases where a variable or constant has been named "any". This is probably very rare, and the code will still compile.

Re: Go Replaces Interface{} with 'Any'

#400

Post by Intermernet »

valenterry wrote: post #279
jshen wrote: post #233

Earlier quoted context omitted.

Go is the most readable language I’ve used in terms of understanding other peoples complex code bases, and I’ve been doing this a long time and have used a lot of languages. Edit: It’s also one of the most approachable languages.

Why don't you list the languages that you have used? Otherwise there isn't really any new information. For example for, having done Java, Scala, Python, Groovy, Haskell, Typescript and a couple others, Go reads extremely horrible. It feels as bad as enterprisey Java to me.

The readability of Go is intrinsically linked to the error handling in Go. If the spec started accepting "clever" rules to do with auto-magic return / assignment of error values instead of explicit handling, then the cognitive load of code review increases. If every error path is explicit, then the review becomes simple and self-explanatory (at least when it comes to error handling).
Post reply on HN