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

Leveraging the Go Type System

gopherguides.com

Post reply on HN
Print view View original

101–110 of 112 posts

Re: Leveraging the Go Type System

#101

Post by morelisp »

throwaway894345 wrote: post #78
mssundaram wrote: post #65

Earlier quoted context omitted.

Do you have any examples of how you would implement a makeshift sum type like your example?

Here's one such workaround: https://play.golang.org/p/4Fd7aKRtmvz It's not great for a number of reasons. First of all, `nil` is always a valid permutation even if we don't want it to be. Secondly, it's a lot of work to express the constraints we want. Thirdly, it's not perfectly type-safe; someone who was determined to shoot themselves in the foot could construct other instances of our "singleton types" if they real…

Fifth, and most critically for me why it’s not really any better than a comment on an interface{}: a user’s matches won’t be checked for exhaustiveness if you add a new type, let alone them poking around the internals. You can box them safely, but not unbox them.

Re: Leveraging the Go Type System

#102

Post by mssundaram »

pjmlp wrote: post #92
mssundaram wrote: post #66

Earlier quoted context omitted.

I hope you mean Golang's type system. It is indeed underwhelming. However it is arguably the poorest type system in popular usage. Therr exists much better, which I encourage you to explore - Typescript, Haskell, Rust

Oberon-07 is even smaller, as Wirth decided to revisit Oberon and pursue the path of the minimalist type safe systems programming language. If any language of Oberon family would ever become mainstream I would vote for Active Oberon instead.

Very interesting, thank you for sharing. Do you recommend any resources to explore?

Re: Leveraging the Go Type System

#103

Post by cube2222 »

tsimionescu wrote: post #99
throwaway894345 wrote: post #88

Earlier quoted context omitted.

> To be fair, Go's package management is far from sane (though better than nothing, of course) It's not perfect, but it's among the best. It's far better than the popular offerings for Python, C, C++, and Java. NPM was also pretty terrible last I used it (needed to regularly blow away node_modules and reinstall things, random ENOENT errors, etc) and I think the .net world almost adopted a sane project file structure…

> It's not perfect, but it's among the best. It's far better than the popular offerings for Python, C, C++, and Java. Maven is significantly better than Go modules: it doesn't require special support from your git server, it doesn't rely on magic tags with magic formats, it does strict dependencies by default, it handles branching any way you want, it works with binary artifacts not just source code, it has explicit…

To be honest, looking at your arguments for Maven being better, most of those are pros or cons, depending on where you stand. They're tradeoffs.

Also, as far as I know, Go doesn't require special support from your git (or whatever VCS you use) server, as is confirmed by the reference: https://golang.org/ref/mod#vcs

Though I mainly wanted to comment on the profiles part. Could you please provide links to tools which are in your opinion good for complex profiling use cases?

I'm asking because I myself really like both the web based profile viewer, as well as the go tool trace viewer, for more complex situations.

However, to address the other points: testing has good libraries for equality and mocking (I.e. testify); formatting is a trade-off, many people prefer one forced consistent code style, even if they don't like it

Overall, your conclusion of the Go ecosystem being "definitely worse" looks quite far fetched based on your arguments. Not to say it's wrong, the reasoning just isn't at all convincing.

Re: Leveraging the Go Type System

#104

Post by leetrout »

cube2222 wrote: post #103
tsimionescu wrote: post #99

Earlier quoted context omitted.

> It's not perfect, but it's among the best. It's far better than the popular offerings for Python, C, C++, and Java. Maven is significantly better than Go modules: it doesn't require special support from your git server, it doesn't rely on magic tags with magic formats, it does strict dependencies by default, it handles branching any way you want, it works with binary artifacts not just source code, it has explicit…

To be honest, looking at your arguments for Maven being better, most of those are pros or cons, depending on where you stand. They're tradeoffs. Also, as far as I know, Go doesn't require special support from your git (or whatever VCS you use) server, as is confirmed by the reference: https://golang.org/ref/mod#vcs Though I mainly wanted to comment on the profiles part. Could you please provide links to tools which a…

> Also, as far as I know, Go doesn't require special support from your git (or whatever VCS you use) server, as is confirmed by the reference: https://golang.org/ref/mod#vcs

One point of clarification- pretty much no one uses the VCS qualifier (.git in the module path) so the nicer looking import paths work by having a web server respond with the special meta tag. That could be what OP was referencing.

Also, tangentially, Drew DeVault found out that the docs hosted on pkg.go.dev only use a whitelisted set of domains for sources.

https://drewdevault.com/2020/08/01/pkg-go-dev-sucks.html

Re: Leveraging the Go Type System

#105

Post by int_19h »

denysvitali wrote: post #20

I'm a Go fan and I love the language, but what I can't really stand is the fact that enums do not really exist, and it's representation (stringification, for example) is not implemented by default. So far I still haven't found a clean way to have proper enums, and this article shows us that unfortunately neither the author has :(

If generics are a representative example, Go will eventually get enums, and probably ones that look very much like what C# or Java have, after years of insisting that you don't actually need them, and that everybody is doing them wrong. ~

Re: Leveraging the Go Type System

#106

Post by throwaway894345 »

morelisp wrote: post #101
throwaway894345 wrote: post #78

Earlier quoted context omitted.

Here's one such workaround: https://play.golang.org/p/4Fd7aKRtmvz It's not great for a number of reasons. First of all, `nil` is always a valid permutation even if we don't want it to be. Secondly, it's a lot of work to express the constraints we want. Thirdly, it's not perfectly type-safe; someone who was determined to shoot themselves in the foot could construct other instances of our "singleton types" if they real…

Fifth, and most critically for me why it’s not really any better than a comment on an interface{}: a user’s matches won’t be checked for exhaustiveness if you add a new type, let alone them poking around the internals. You can box them safely, but not unbox them.

Yes, that’s an important point; thanks for noting.

Re: Leveraging the Go Type System

#107

Post by pjmlp »

mssundaram wrote: post #102
pjmlp wrote: post #92

Earlier quoted context omitted.

Oberon-07 is even smaller, as Wirth decided to revisit Oberon and pursue the path of the minimalist type safe systems programming language. If any language of Oberon family would ever become mainstream I would vote for Active Oberon instead.

Very interesting, thank you for sharing. Do you recommend any resources to explore?

A couple, you can start here to see how the Active Oberon based OS looked like,

https://www.progtools.org/article.php?name=oberon&section=co...

Some links are broken now, because ETHZ no longer hosts the A2 site, however you can get the latest language report at http://cas.inf.ethz.ch/boards/2/topics/1

And the source code and old documents for the original A2 OS at github, https://github.com/metacore/A2OS

Re: Leveraging the Go Type System

#108

Post by mdtusz »

christiansakai wrote: post #49
mssundaram wrote: post #35

It doesn't take much "leveraging" to do this in a language with ADTs. E.g. Typescript type Book = { id: number; name: string; genre: Genre; }; type Genre = | "Adventure" | "Comic" | "Crime" | "Fiction" | "Fantasy" | "Historical" | "Horror" | "Magic" | "Mystery" | "Philosophical" | "Political" | "Romance" | "Science" | "Superhero" | "Thriller" | "Western";

As a JavaScript developer I once abhorred TypeScript, until I realized TypeScript's type system is really powerful, it can do something like > and >. Mind. Blown.

While typescript typing is extremely powerful and expressive, I sometimes find that code written with it overuses some of the features in order to make types and interfaces align, rather than rethinking the design altogether. Especially with generics, things can get overly complex precisely because of the ability to extract return types, use partial types, omit fields, etc.

My biggest typescript gripe is the fact that interface and type are _nearly_ interchangable, and many codebases just use interface wholemeal where it isn't really appropriate.

Re: Leveraging the Go Type System

#109

Post by christiansakai »

mdtusz wrote: post #108
christiansakai wrote: post #49

Earlier quoted context omitted.

As a JavaScript developer I once abhorred TypeScript, until I realized TypeScript's type system is really powerful, it can do something like > and >. Mind. Blown.

While typescript typing is extremely powerful and expressive, I sometimes find that code written with it overuses some of the features in order to make types and interfaces align, rather than rethinking the design altogether. Especially with generics, things can get overly complex precisely because of the ability to extract return types, use partial types, omit fields, etc. My biggest typescript gripe is the fact tha…

I tried to refactor a big code base without these special helper types, it was a massive amount of duplication, to the point I just copy paste it or just aggregate it into one folder and making it leak everywhere on my layers.

The type and interface is just because they are structural typing. It's attempting to stay faithful to JavaScript after all. Without that then the intuition breaks and not consistent.

Re: Leveraging the Go Type System

#110

Post by LordHeini »

Honestly i miss the Java enums. Those can have constructors implement interfaces and what not.

In Go i actually revert to the old C custom of adding a private length value at the end so i can iterate over all values.

Like so

  type Color int
  
  const (
        Blue Color = iota
        Green
        Red
        limit
  )

  for i := Blue; i
Go really needs proper enums...
Post reply on HN