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

The Go Programming Language and Environment

cacm.acm.org

Post reply on HN
Print view View original

231–240 of 250 posts

Re: The Go Programming Language and Environment

#231

Post by morelisp »

pjmlp wrote: post #226
coldtea wrote: post #222

Earlier quoted context omitted.

Which is neither here nor there. It'a runtime that's run from the statically combined binary.

Great, Java is doing the same since the first commercial JDKs started supporting AOT compilation around 2000. Or if you prefer free beer recipes, gcj which got dropped when most developers eventually moved into hacking into OpenJDK around 2009.

What other people actually use matters a lot though. Hell, a greater proportion of Java devs ca. 2002 probably knew how to AOT-compile their programs than do today. Using minority tooling in a popular language is often just as painful as using a minority language.

Re: The Go Programming Language and Environment

#232

Post by morelisp »

CraigJPerry wrote: post #106
ampersandy wrote: post #83

Earlier quoted context omitted.

I really dislike this meme of pointing out that Google has deprecated a lot of projects. Do people actually expect Google to staff people & resources running every project they've released forever? A more interesting comparison would be open source projects that Google has abandoned or failed to properly hand over control of to the community, especially if we're talking about Go.

It’s not clear to me that Go would survive Google giving up its continued investment. Go has the fundamentals to survive - it’s open source, it has a healthy amount of contribution from non-google employees, the compiler is written in Go (that’s important when you consider an alternative situation like a python or js developer who wants to contribute a change to their compiler (they need to learn c / c++ respectively…

I think we have some models of what would happen to Go without Google, it's probably similar to what happened to Java under the weaker period of Oracle's stewardship.

The tool as-it-is keeps chugging along pretty well and even improving in small ways, but it stops reacting to larger trends and misses the boat at critical moments. Some new language in the same space comes up and finds it easy to shear off a massive portion of its user base by doing "the same thing, but modern".

(Less obvious models would be PHP to backend JS, and PHP and Python to Go, which had similar community development arcs.)

Re: The Go Programming Language and Environment

#233

Post by divan »

noisy_boy wrote: post #230
divan wrote: post #212

Earlier quoted context omitted.

Obviously Go code shown here doesn't show string enums. It's an integer enum with function that converts integer value to the string representation (by implementing Stringer interface). Which makes total sense (not every int enum needs String conversion). I assume your Java example has some magic (aka conventions) in how to convert values into string. Without reading Java manuals, how do I know what's the magic's con…

> Obviously Go code shown here doesn't show string enums. It's an integer enum with function that converts integer value to the string representation (by implementing Stringer interface). Which makes total sense (not every int enum needs String conversion). Considering your robust defence of Go, maybe you can demonstrate the simplicity of Go's string enums? > I assume your Java example has some magic (aka conventions…

I think people mean different things by enums. Is it just a set of constants of a given type or a sum type (aka variant type)?

Go doesn't have sum types at all.

`iota` is just a syntax sugar for enumerating integer constants/variables.

But as you're talking about string enums, the Go equivalent would be:

   type Season string

   const (
       Summer Season = "Summer"
       Autumn      = "Autumn"
       Winter      = "Winter"
       Spring      = "Spring"
   )
But, again, that's not a variant type, so you can still assign a different value to the variable of the type Season. Which is rarely a problem in practice (there are other ways to validate data rather than by type system constraints).

So just to clarify, many of the use cases for enumerated values do not need string representation. Go has no magical way to translate varibale/const name into the string.

Re: The Go Programming Language and Environment

#234

Post by anthk »

pjmlp wrote: post #219
anthk wrote: post #124

Earlier quoted context omitted.

Well, Plan9 was the cloud (networked) OS simplyfing C and making Unix even more ubiquitous, so it has sense. Go is the legacy of Plan9 "ported" back to Unixlikes and C.

Go is the legacy of Limbo (Inferno), not Plan 9.

Limbo was built around Plan9, and the static binary (cross) compiling comes from plan9's C.

Re: The Go Programming Language and Environment

#235

Post by pjmlp »

morelisp wrote: post #231
pjmlp wrote: post #226

Earlier quoted context omitted.

Great, Java is doing the same since the first commercial JDKs started supporting AOT compilation around 2000. Or if you prefer free beer recipes, gcj which got dropped when most developers eventually moved into hacking into OpenJDK around 2009.

What other people actually use matters a lot though. Hell, a greater proportion of Java devs ca. 2002 probably knew how to AOT-compile their programs than do today. Using minority tooling in a popular language is often just as painful as using a minority language.

That is orthogonal to what language implementations can do, failure to education doesn't change what tools are available.

Re: The Go Programming Language and Environment

#236

Post by noisy_boy »

divan wrote: post #233
noisy_boy wrote: post #230

Earlier quoted context omitted.

> Obviously Go code shown here doesn't show string enums. It's an integer enum with function that converts integer value to the string representation (by implementing Stringer interface). Which makes total sense (not every int enum needs String conversion). Considering your robust defence of Go, maybe you can demonstrate the simplicity of Go's string enums? > I assume your Java example has some magic (aka conventions…

I think people mean different things by enums. Is it just a set of constants of a given type or a sum type (aka variant type)? Go doesn't have sum types at all. `iota` is just a syntax sugar for enumerating integer constants/variables. But as you're talking about string enums, the Go equivalent would be: type Season string const ( Summer Season = "Summer" Autumn = "Autumn" Winter = "Winter" Spring = "Spring" ) But, a…

By enum I mean this:

> An enum type is a special data type that enables for a variable to be a set of predefined constants. The variable must be equal to one of the values that have been predefined for it. [0]

> Is it just a set of constants of a given type or a sum type (aka variant type)?

So by above definition, it is a set of predefined constants.

> But, again, that's not a variant type, so you can still assign a different value to the variable of the type Season.

Which kinda defeats the purpose doesn't it?

> Which is rarely a problem in practice (there are other ways to validate data rather than by type system constraints).

I'm not sure I agree that it is a rare problem - if I can't rely on the type system to do a check that something belongs to a set of predefined constants, that is a pretty basic part missing. Of course there would be other ways but being able to lean on the type system would be a pretty reasonable expectation.

> So just to clarify, many of the use cases for enumerated values do not need string representation.

Sure - just like many of the use cases do require string representation. It is not unreasonable to expect that enumerations as defined above should be able handle cases that do and don't require string representation.

> Go has no magical way to translate varibale/const name into the string.

You keep using this word magical when it comes to addressing the limitations of the language. Java isn't doing "magic" when it is able to return a string representation of the enum value - it is part of the language. Credit where credit is due etc.

[0]: https://docs.oracle.com/javase/tutorial/java/javaOO/enum.htm...

Re: The Go Programming Language and Environment

#237

Post by pjmlp »

anthk wrote: post #234
pjmlp wrote: post #219

Earlier quoted context omitted.

Go is the legacy of Limbo (Inferno), not Plan 9.

Limbo was built around Plan9, and the static binary (cross) compiling comes from plan9's C.

Inferno isn't Plan 9.

As for that cross compiling feature, Amsterdam Compiler toolkit did it before Plan 9 was even an idea.

Re: The Go Programming Language and Environment

#238

Post by pjmlp »

nwsm wrote: post #126
pjmlp wrote: post #33

Easy, - Backed by Google - Plan 9 and UNIX people as designers - Docker migrated from Python to Go - Kubernetes migrated from Java to Go - After Docker and Kubernetes explosion, all Cloud Native Foundation projects start using the same language, thus adoption

esbuild [0], a JavaScript bundler, has made waves in the frontend community over the past couple years for being orders of magnitude faster than alternatives and written in Go (as opposed to Node.js which is the usual choice for obvious reasons). [0] https://esbuild.github.io/

What a surprise, even QuickBasic would have managed such feat.

Re: The Go Programming Language and Environment

#239

Post by morelisp »

pjmlp wrote: post #235
morelisp wrote: post #231

Earlier quoted context omitted.

What other people actually use matters a lot though. Hell, a greater proportion of Java devs ca. 2002 probably knew how to AOT-compile their programs than do today. Using minority tooling in a popular language is often just as painful as using a minority language.

That is orthogonal to what language implementations can do, failure to education doesn't change what tools are available.

Only in a vapid purely existential sense of "available".

Re: The Go Programming Language and Environment

#240

Post by divan »

noisy_boy wrote: post #236
divan wrote: post #233

Earlier quoted context omitted.

I think people mean different things by enums. Is it just a set of constants of a given type or a sum type (aka variant type)? Go doesn't have sum types at all. `iota` is just a syntax sugar for enumerating integer constants/variables. But as you're talking about string enums, the Go equivalent would be: type Season string const ( Summer Season = "Summer" Autumn = "Autumn" Winter = "Winter" Spring = "Spring" ) But, a…

By enum I mean this: > An enum type is a special data type that enables for a variable to be a set of predefined constants. The variable must be equal to one of the values that have been predefined for it. [0] > Is it just a set of constants of a given type or a sum type (aka variant type)? So by above definition, it is a set of predefined constants. > But, again, that's not a variant type, so you can still assign a…

> Which kinda defeats the purpose doesn't it?

Have you actually tried it or you just ranting that Go is not Java?

Take `time.Weekday` type, for example from Go stdlib. It's a typical use of kinda enums in Go. [1]

It serves the purpose to effectively use Weekday whenever it's needed – in literals, in tests, in debug output, etc. Internally it's just an int, but for humans it's better to work with named predefined constants. Instead of creating yet another language feature that will automagically (yes, I keep repeating it, because it matters) convert variable names into strings, Weekday type leverages other Go features to achieve it in a more appropriate way, implementing proper string conversion for long and short forms for English and leaving room for proper i18n handling (it's still a named int constant). [2] Having it as a separate named type makes it handy for proper type checking (so you can't pass some integer with incorrect value to the function expecting time.Weekday).

And now you're saying that it's all useless and wrong, because compiler is not enforcing range of values that varaible of this type can have. But I tell you that it's useful and helping code readability enormously even without being a sum type.

And I hope it's clear that when you switch to another language, the worst thing you can do is to complain that it's different from your previous favourite language. You not just switching use another syntax, but you changing the ways to do things and even philosophy. It's like moving to another country - you not just changing a language, you switching to a different culture and economy. You adopt their social norms, follow the rules of that country and pay taxes even if in your country it was all different.

So yeah, in Go there are no sum types aka enums. And you know what, Go is extremely effective at what it was designed to despite of this. And "Go enums" work just fine, until they may be improved in the future when community is in consensus on how implement it, respecting backward-compatibility rule.

[1] https://cs.opensource.google/go/go/+/refs/tags/go1.18.2:src/... [2] https://cs.opensource.google/go/go/+/refs/tags/go1.18.2:src/...

Post reply on HN