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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

171–180 of 318 posts

Re: Seven years of Go

#171

Post by stcredzero »

fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust.

Enums are so underrated. So many architecture problems introduced by bad coders in Smalltalk would have been entirely avoided with Swift style enums.

Re: Seven years of Go

#172

Post by aikah »

Matthias247 wrote: post #110
72deluxe wrote: post #64

Earlier quoted context omitted.

What is it being used for? HTTP servers? 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere?

IMHO Go is a good choice for lots of system daemons and commandline tools. If networking is involved it shines even more. > 7 years without proper penetration into the GUI market seems odd, unless it is aimed elsewhere? You could apply this criticism to nearly all languags, as there are currently only very few that are used for native GUIs: C and C++, because the operating systems and native toolkits are written in t…

Python has strong support for Gnome libraries, therefore GTK+ through GObject introspection. Go type system is too rigid to allow a tool like GObject introspection to interact with Go code. So no, this criticism doesn't apply to nearly all languages.

Re: Seven years of Go

#173

Post by weberc2 »

dbaupp wrote: post #155
weberc2 wrote: post #126

Earlier quoted context omitted.

You can also build enums by building a struct with a `Tag` field. This works well and generally has better performance characteristics than using interfaces.

That approach has its own problems, such as wasting memory (need to store any data for each tag value separately, rather than benefiting from overlapping storage ala Rust enums or C tagged unions), as well as losing type safety: one has to manually remember which (groups of) fields correspond to which tag values (although the Go loss of type safety is far better/more controlled than the one for C tagged unions). Usin…

> such as wasting memory

Granted, but I'll happily trade a few bytes of stack for zero allocs in many cases.

> rather than benefiting from overlapping storage ala Rust enums or C tagged unions

Of course, but we don't have those in Go, do we?

> as well as losing type safety

Tagged structs are not meaningfully less type safe than interfaces.

> one has to manually remember which (groups of) fields correspond to which tag values

Use an enum for the tag: https://play.golang.org/p/LI2Bh231W3

Re: Seven years of Go

#174

Post by weberc2 »

Manishearth wrote: post #151
weberc2 wrote: post #126

Earlier quoted context omitted.

You can also build enums by building a struct with a `Tag` field. This works well and generally has better performance characteristics than using interfaces.

That only works well if each "variant" holds the same kind of thing. If not, you have to store them one after the other (space wastage), or use interfaces to store them in the same place (tag isn't necessary anymore, extra boxing). Rust enums (ADTs) aren't like Java enums where each variant contains the same kind of data.

I understand. I don't mind wasting a few bytes of stack for zero allocs.

Re: Seven years of Go

#175

Post by weberc2 »

pcwalton wrote: post #153
weberc2 wrote: post #146

Earlier quoted context omitted.

In the context of the conversation, adopting Rust over Go is a mistake for the majority of applications primarily because of the difference in learning curve . Of course there are other factors, and not all applications are equal. I threw in my C++ background to demonstrate that I'm quite capable of thinking in the low-level terms demanded of Rust programmers, and my learning curve was still very large. You can disag…

I don't agree that the learning curve difference (which is a temporary cost that decreases over time) is high enough to outweigh the benefits in the "majority" of cases that could benefit from Rust (and reap those benefits long-term). I respect your experience, but it doesn't invalidate mine, which has held up with many people I've seen get up to speed with Rust.

I never claimed my experience invalidated yours; you asked for experience that was contrary to yours, so I offered mine.

Re: Seven years of Go

#176

Post by pcwalton »

weberc2 wrote: post #156
pcwalton wrote: post #129

Earlier quoted context omitted.

> Right, but I think those cases are few and far between. Basically where you need blistering performance and/or deterministic resource usage. No, there's a lot more. See my reply to your sibling comment. > I would throw "safety" in there, but many (most?) safety-critical applications are written in C, and Go is certainly safer than C. This argument doesn't make any sense to me. Why is being better than a language fr…

> No, there's a lot more. See my reply to your sibling comment. Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety? > Why is being better than a language from 1978 our sole criterion? I have no idea. Thankfully no one made any such argument. > Shouldn't we try to make our software as reliable as possible? No, we should make it sufficiently reliable. For example,…

> Which criteria from your post can't be rolled up into performance, deterministic resource usage, or safety?

Package management. Macros (Rust has a widely used ORM). Generics. Easier error handling. Pattern matching. Functional features, such as map(). A more flexible module system. Built-in FFI. Inline assembly. Etc, etc.

> By the by, I like Rust, I just think it's not well-suited for most applications.

I'm going to push back on this too. In terms of "all programs that anyone has ever written", scripting languages are overwhelmingly the most suitable choice. But in terms of usage, core infrastructure favors reliability, performance, and interoperability with other languages. Consider regex libraries, language runtimes, graphics libraries, codecs, text/internationalization support, windowing systems, UI libraries, browsers, and so forth. This is our core infrastructure, where performance and reliability are paramount, and these libraries have outsized importance.

> this isn't incompatible with my claim, that Go is at least as safe as C, and thus safety alone doesn't preclude Go from safety critical applications.

This assumes that C is OK for safety critical applications. It's not. The status quo is bad. The bar should be much higher.

Re: Seven years of Go

#177

Post by weberc2 »

wyager wrote: post #123
weberc2 wrote: post #102

Earlier quoted context omitted.

It's not safer than Java. The selling point over Java is developer friendliness (simpler language, tooling, dependency management, deployment, etc).

I was asking the GP why he cited safety as a feature of Go. I agree with you; that's not a good argument.

I can't speak for the GP, but my interpretation is that safety is a feature of Go, but it's not unique to Go. Go is more safe than some languages, but less safe than others.

Re: Seven years of Go

#178

Post by detaro »

stcredzero wrote: post #171
fizzbatter wrote: post #8

So, i was a Go developer for ~4 years, then for the last 4 months or so i've been learning and using Rust. The pure joy of some things with Rust was astounding. Now, i joined a new job and they're in need of a new language for some backend tasks - the choice was mine. Rust or Go? The backend tasks were heavy API servers - nothing amazing, we don't do groundbreaking work. Python was their existing language, but they w…

4. Enums. My god, Enums. Such a simple feature, but so insanely welcome and useful in Rust. Enums are so underrated. So many architecture problems introduced by bad coders in Smalltalk would have been entirely avoided with Swift style enums.

Can you give examples, assuming you are referring to patterns that still are somewhat common? I've seen a bunch of somewhat-connected Singletons used as enums with extra functionality in Smalltalk, is that the kind of thing you were thinking of?

Re: Seven years of Go

#179

Post by richard_todd »

stcredzero wrote: post #157
richard_todd wrote: post #70

Earlier quoted context omitted.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!

Having personally fallen into the trap of overusing C++ templates on a project, I understand the point. However, I did not go on to reject the idea that templates should be in the language.

Backing away from specific suggestions, I think it's healthy to recognize that Go has a boilerplate/DRY problem--not just with error handling!--, and it would be nice to address it in some way. If not with generics, then with something.

Re: Seven years of Go

#180

Post by pcwalton »

stcredzero wrote: post #157
richard_todd wrote: post #70

Earlier quoted context omitted.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code…

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically. The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!

I've also worked on codebases that have overused the && operator. Should we remove that in favor of nested if?
Post reply on HN