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

81–90 of 112 posts

Re: Leveraging the Go Type System

#81

Post by [deleted] »

mssundaram wrote: post #65
throwaway894345 wrote: post #47

Earlier quoted context omitted.

I don't mind that the compiler doesn't provide a default string implementation by default. I'm happy to use string values in my enums (in most cases const string vs int doesn't matter much for performance) for convenience; what I do wish for is full-blown ADTs. I want to be able to express `'Hello' | 'World' | 42 | struct{Name string, Age int} | []int` and know that the compiler will enforce. You can sort of get ther…

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

[deleted]

Re: Leveraging the Go Type System

#82

Post by tsimionescu »

throwaway894345 wrote: post #50
dmitriid wrote: post #26

Earlier quoted context omitted.

Go has so many `go generate` tools to overcome its shortcomings, it's ridiculous.

This is true, but I'll take these shortcomings over deficiencies in tooling, ecosystem, performance, learning curve, etc any day. In other words, I can ship software pretty easily with a suboptimal type system, but much less easily if I have to select for candidates with a decade of experience in a particular VM runtime or if the performant runtimes are incompatible with important parts of the ecosystem or if there i…

To be fair, Go's package management is far from sane (though better than nothing, of course). The tooling is also sub-par for modern languages, especially in terms of free development environments, though go-pls is slowly improving.

Re: Leveraging the Go Type System

#84

Post by bitwize »

We have a useful lower bound for type-system richness: if you're developing a new language in the 21st century and your type system is not at least as rich as Hindley-Milner, do not expect programmers to take your language seriously.

Re: Leveraging the Go Type System

#85

Post by tsimionescu »

dastx wrote: post #22
phyrex wrote: post #12

Frankly, this article has the opposite effect of convincing me. The author starts with a perfectly reasonable data model and munges it for some questionable space savings (that only apply in the dumbest of databases that don't do any sort of compression), for the price of a lot of boilerplate, and significantly less insight into the data if you look at it in serialized format (either directly in the database or on th…

That boiler plate usually can be generated for you. See Go's stringer which does all the magic for you. All you have to do is define the type and constants, and a go generate directive.

And install stringer in every dev env, and debug all the boilerplate anyway when things go wrong.

Code generation is always the last resort.

Re: Leveraging the Go Type System

#86

Post by mssundaram »

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.

Yeah, when I first came across TS, I didn't see the point, mostly because I didn't see how powerful Typescript's type system is - it gets more amazing by the day, too.

Re: Leveraging the Go Type System

#87

Post by mhh__ »

shadowgovt wrote: post #70
mhh__ wrote: post #23

Earlier quoted context omitted.

Is this compared to a good language or (say) server-side JavaScript because the languages I tend to use allow me to do that and Go looks looks very Algol-68-y from that perspective as opposed to some hyper abstract wonder-language.

What languages do you tend to use?

I work for the D foundation, so mainly D for things I get to choose.

Re: Leveraging the Go Type System

#88

Post by throwaway894345 »

tsimionescu wrote: post #82
throwaway894345 wrote: post #50

Earlier quoted context omitted.

This is true, but I'll take these shortcomings over deficiencies in tooling, ecosystem, performance, learning curve, etc any day. In other words, I can ship software pretty easily with a suboptimal type system, but much less easily if I have to select for candidates with a decade of experience in a particular VM runtime or if the performant runtimes are incompatible with important parts of the ecosystem or if there i…

To be fair, Go's package management is far from sane (though better than nothing, of course). The tooling is also sub-par for modern languages, especially in terms of free development environments, though go-pls is slowly improving.

> 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 before reverting back to MSBUILD but I might be wrong there. OCaml was also pretty terrible last I used it, but people swear to me that Dune has fixed everything (though those guys have been telling me for the decade that no one needs shared memory parallelism and also it's right around the corner, so maybe take that with a grain of salt).

> The tooling is also sub-par for modern languages, especially in terms of free development environments, though go-pls is slowly improving.

Go doesn't have great IDEs because it's always been more of a text-editor language, and few languages have editor plugins of comparable quality. It also doesn't have a great debugging story (there is Delve, but I've heard that it's not a great debugging experience). These don't really chafe me because I don't like IDEs and I'm the unpopular guy who hates debuggers. Those are the biggest "gaps".

For other things though, Go is great. Testing? Built in. Benchmarking? Built in. Profiling? Built in. Cross compilation? Built in. Static linkage? It's the default. Formatting? Built in. Documentation generation? Built in. Code and documentation packaging and publishing? Built in (to git). Not only are all of these things built in, but they're standard across the ecosystem so developers can onboard with minimal learning curve.

Re: Leveraging the Go Type System

#89

Post by pjmlp »

throwaway894345 wrote: post #88
tsimionescu wrote: post #82

Earlier quoted context omitted.

To be fair, Go's package management is far from sane (though better than nothing, of course). The tooling is also sub-par for modern languages, especially in terms of free development environments, though go-pls is slowly improving.

> 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…

Makes sense, after all it is catching up with Mac OS, OS/2 and Windows 95 IDEs.

Re: Leveraging the Go Type System

#90

Post by pjmlp »

morelisp wrote: post #59
stouset wrote: post #36

Earlier quoted context omitted.

This perspective ignores the fact that there is no shortage of typed languages that don’t have all the—in 2021—inexcusable downsides of golang.

There is unfortunately a shortage, still in 2021, of languages that have a null set of inexcusable downsides. I will trade - unhappily - ADTs for value types, automatic memory management, some language-level concurrency support, a compiler that builds our largest project in under two minutes, and a community large enough I can spend my time training new hires on fundamentals and business problems and not tool onboard…

.NET Native, OCaml, Eiffel, Common Lisp, D, Nim just for starters.
Post reply on HN