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

301–310 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#301

Post by eru »

DarylZero wrote: post #204
linkdd wrote: post #86

Earlier quoted context omitted.

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

In general, you can replace pattern matching with a function that takes one function for each constructor of the sum type. However, doing this kind of ... sucks.

It sucks when you have to use it for everything, but it's a useful enough technique that most Haskell datatypes come with functions that provide exactly this conversion to church encoding.

See eg 'maybe' (https://www.stackage.org/haddock/lts-18.18/base-4.14.3.0/Pre... on stackage) or foldr for lists.

'foldr' is interesting, because it encapsulates a recursive pattern matching on lists. For the non-recursive version, see 'uncons' composed with 'maybe'.

Re: Go Replaces Interface{} with 'Any'

#302

Post by eru »

johnisgood wrote: post #215
linkdd wrote: post #86

Earlier quoted context omitted.

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

Huge no to anything that will require .unwrap() noise everywhere in the codebase. I use Erlang, my code does not have ".unwrap().unwrap()"[1] anywhere. [1] https://github.com/SeaQL/sea-orm/blob/64c54f8ad603df0c1d9da8...

That's actually a problem in Erlang.

In Haskell, 'Maybe (Maybe Int)' is a different type from 'Maybe Int'.

That means that when you use eg a hash table that returns some kind null value like 'Nothing' on lookup when a key is not found, you can still stick exactly that kind of null value as a normal value into the table and everything will turn out fine.

Re: Go Replaces Interface{} with 'Any'

#303

Post by MereInterest »

cortesoft wrote: post #91
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…

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 backwards compatibility.)

Since backwards compatibility is already a given for languages, you can then have the major version number indicate feature additions, rather than always being a constant value as semantic versioning would require.

Re: Go Replaces Interface{} with 'Any'

#304

Post by eru »

imron wrote: post #240
johnisgood wrote: post #215

Earlier quoted context omitted.

Huge no to anything that will require .unwrap() noise everywhere in the codebase. I use Erlang, my code does not have ".unwrap().unwrap()"[1] anywhere. [1] https://github.com/SeaQL/sea-orm/blob/64c54f8ad603df0c1d9da8...

I use rust and my code does not have .unwrap() (and definitely not .unwrap().unwrap()) in it either. That's what the ? operator is for.

The '?' is not a conceptual advance over .unwrap(), it's "just" a major syntactic convenience.

Re: Go Replaces Interface{} with 'Any'

#305

Post by rob74 »

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.

Well then I guess it's Java for you until retirement. Go can feel a bit alien if you only know "C-style" languages, because its creators took inspiration from a wide array of languages, including Pascal. Actually Pascal-style declarations are easier to read, but you have to keep an open mind and not just go "doesn't look like what I'm used to, so it must be bad"...

Re: Go Replaces Interface{} with 'Any'

#306

Post by eru »

egeozcan wrote: post #97
linkdd wrote: post #86

Earlier quoted context omitted.

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

I don't see why that wouldn't be possible to implement now that the generics are here.

Depends on how generic you want this.

In Haskell, you can have functions that work generically over option-types, error-able types, lists, functions, tuples, etc.

In Rust, you have to specifically implement functionality for all of these.

But eg your 'map' function in Rust still works for all lists, no matter what item type. In Go before this change, you had to write a different map function for each item type that could be in your list.

In Haskell, the same 'map' function works for lists, functions, error-able types etc.

Re: Go Replaces Interface{} with 'Any'

#307

Post by eru »

kortex wrote: post #206
dragonwriter wrote: post #155

Earlier quoted context omitted.

> Java (and Javascript in its attempt to copy it) are about the only languages that actually promote using exceptions for errors Python does. Ruby does. It's not just Java and JS. Go is very open about its approach being a departure. > And actually, many APIs in the wild do represent errors as integers. Many, many APIs in the wild are implemented in (or meant to be consumed from) C, which doesn't even have exceptions…

> Python does And it's awful. I use EAFP locally (to avoid TOCTOU and the like) at low level interfaces but I don't let it bubble up out of a function scope, because it is a goto in all but name. I've also been increasingly using the `result` library/data structure. It's incredibly liberating to return an error as an object you can compose into other functions, vs try/catch, which does not compose. Yes I write python…

I find, that the problem with exceptions in Python is not so much that it is a goto, but that they are a bit like dynamic scoping (vs static scoping of variables), so you can not reason about them statically.

An example: suppose you have a function that does some work with the filesystem, and also calls some user-supplied code. (Perhaps because the user can subclass something etc, or because you are getting a callback, the details don't matter.)

Naturally your function might have some idea how to handle its own filesystem trouble, but you have no clue how to handle any filesystem exceptions that come from user provided code.

It's rather awkward to get this exactly right.

Re: Go Replaces Interface{} with 'Any'

#308

Post by garmaine »

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.

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

Re: Go Replaces Interface{} with 'Any'

#309

Post by loo »

garmaine wrote: post #308
notfed wrote: post #295

Earlier quoted context omitted.

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

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

python2 -> python3 was just a handful of things like that.

Re: Go Replaces Interface{} with 'Any'

#310

Post by joebob42 »

pawelmurias wrote: post #163
hbn wrote: post #62

Earlier quoted context omitted.

It's definitely more streamlined, but my concern would be that newcomers might not understand that it's just an alias. Learning Go really reframed my concept of what an interface is, and I thought that using an empty interface to represent "any type" was kind of ingenious, and helps reinforce its ethos. An empty interface can represent any type because every type inherently implements an interface with no methods. An…

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

I agree, and I think this mistake is at the root of most of what are (at least to my biased point of view) the big mistakes made by go. Syntactical niceties and simplicity / obviousness are sometimes a tradeoff, but go 1.0 felt like the designers just folded their arms and refused to consider any niceness. I still don't understand why anyone would use go when there are so many better choices, but at least they're fixing some stuff now :)
Post reply on HN