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

The State of Go

talks.golang.org

Post reply on HN
Print view View original

391–400 of 402 posts

Re: The State of Go

#391

Post by enneff »

4ad wrote: post #370
enneff wrote: post #250

Earlier quoted context omitted.

Well Apple stopped supporting 10.8, so why should Go continue to support it? ARM6 support is a lot of work, actually, as IIUC a lot of stuff that the chip doesn't support needs to be done in software, and we don't have a reliable platform for testing against ARM6.

> Well Apple stopped supporting 10.8, so why should Go continue to support it? I don't know, but Microsoft stopped supporting Windows XP many years ago, and it's still supported by Go. (Not that I care about Go on Darwin 10.8; just making an observation...)

Microsoft puts more effort into keeping things working than Apple does. Go works on XP as a result of the work Microsoft has done, not the Go project. Apple change subtle things in each OS X release making it onerous to support the older ones.

Re: The State of Go

#392

Post by 4ad »

enneff wrote: post #391
4ad wrote: post #370

Earlier quoted context omitted.

> Well Apple stopped supporting 10.8, so why should Go continue to support it? I don't know, but Microsoft stopped supporting Windows XP many years ago, and it's still supported by Go. (Not that I care about Go on Darwin 10.8; just making an observation...)

Microsoft puts more effort into keeping things working than Apple does. Go works on XP as a result of the work Microsoft has done, not the Go project. Apple change subtle things in each OS X release making it onerous to support the older ones.

This is not true, Go "keeps working" on Windows because on Windows Go is ABI compliant and uses stable interfaces. In particular, on Windows Go interacts with the system through kernel32.dll and uses the standard Windows ABI.

Same is true for Solaris, where Go interacts with the system only through libc.so.1, and uses the System V ABI for the calling convention and thread-local storage.

On Linux the system call interface is stable (unlike Windows and Solaris), so on Linux Go "keeps working" too (albeit I will note that we don't use an ABI-compliant method for determining the current time...).

Darwin is just like Windows and Solaris, and unlike Linux. The system call interface is not stable, but unlike Windows and Solaris we use it anyway, and the method we use for thread-local storage is unportable and system-dependent. However, Darwin still has a stable interface through its own libc, and there's an ABI-compatible method to do thread-local storage as well. If Go would use the standard system interfaces on Darwin (like it does on Windows and Solaris), Go would just "keep working" on Darwin too and would not require changes each time a new macOS release is made.

It is true that Microsoft is very committed to forward and backwards compatibility, but only for its stable and documented interfaces (which Go uses), undocumented interfaces break all the time; Darwin's forward and backwards compatibility guarantees might not be as strong as Microsoft's over large periods of time, but they are still pretty good as long as you use the supported interfaces.

Re: The State of Go

#393

Post by dilap »

Groxx wrote: post #390
dilap wrote: post #384

Earlier quoted context omitted.

I think that should be fine. t1.Add(diff).Equal(t2) would still hold, because Now gets monontonic time, Add and Sub maintain it, and Equal checks it.

It's entirely possible I'm wrong since I didn't read through things in great detail, but this is what I'm thinking. // time = [wall, mono], just ints for simplicity t1 = time.Now() = [10, 10] t2 = time.Now() = [19, 20] // wall clock lags slightly on second measure diff = t2.Sub(t1) = (20 - 10) == 10 // Sub only operates on mono-time t1.Add(diff) == [20, 20] // Add adds `diff` to both wall and mono [20, 20] ==?== [19,…

If both times have mono time, then Equal() compares that, and ignores wall time.

So t2.Equal(t1) is true.

You are right that "t1 == t2" (comparing the raw bytes of the time structures) is false, but that was already broken anyway (because time-zones break raw byte equality).

(Whether you think it's OK to have a language that doesn't overload == and makes you know that for complex structures you've got to call a method like Equal() probably correlates pretty highly with your opinion of Go.)

There will of course be other weird things, like:

    print(t1) // "20 [20]"
    print(t2) // "19 [20]"
But you could argue that's basically the least-surprising possible result in the face of the surprising fact time having gone backwards one second. :)

By the way, worth mentioning that while this is all implemented in HEAD in Go, it's not a done deal yet -- it'll have a 3-month window for people to try it out in the real world, and if it's found to be problematic, it'll get backed out before becoming part of the official release.

Re: The State of Go

#394

Post by spion »

reikonomusha wrote: post #183
spion wrote: post #84

Earlier quoted context omitted.

Thats not a strength of Go. Structural interfaces, channels and performant M:N green threads are its main strengths, and AFAIK there is no other language that provides a similar combination in a familiar C/ALGOL-like packaging. If such a language existed and had generics and Swift or Rust style error handling as well as some backing by a large-ish corporation / organization, I think that language would be preferred t…

I feel like maybe 10 years ago no one would utter something like "C# needs ADTs" because they didn't have mainstream appeal, despite computer scientists' understanding of them.

Yes, things are moving forward, even if slowly :)

Re: The State of Go

#395

Post by Groxx »

dilap wrote: post #393
Groxx wrote: post #390

Earlier quoted context omitted.

It's entirely possible I'm wrong since I didn't read through things in great detail, but this is what I'm thinking. // time = [wall, mono], just ints for simplicity t1 = time.Now() = [10, 10] t2 = time.Now() = [19, 20] // wall clock lags slightly on second measure diff = t2.Sub(t1) = (20 - 10) == 10 // Sub only operates on mono-time t1.Add(diff) == [20, 20] // Add adds `diff` to both wall and mono [20, 20] ==?== [19,…

If both times have mono time, then Equal() compares that, and ignores wall time. So t2.Equal(t1) is true. You are right that "t1 == t2" (comparing the raw bytes of the time structures) is false, but that was already broken anyway (because time-zones break raw byte equality). (Whether you think it's OK to have a language that doesn't overload == and makes you know that for complex structures you've got to call a metho…

>If both times have mono time, then Equal() compares that, and ignores wall time.

Gotcha, I missed that somewhere. That's essentially fine - then the only real surprises are when you deserialize a Time (so it doesn't have a mono time), which should in principle have no interactions with this proposal.

And yeah, Equal vs ==, the meaning was clear enough that I didn't bother to be specific :) Thanks for the infos!

Re: The State of Go

#396

Post by dilap »

Groxx wrote: post #395
dilap wrote: post #393

Earlier quoted context omitted.

If both times have mono time, then Equal() compares that, and ignores wall time. So t2.Equal(t1) is true. You are right that "t1 == t2" (comparing the raw bytes of the time structures) is false, but that was already broken anyway (because time-zones break raw byte equality). (Whether you think it's OK to have a language that doesn't overload == and makes you know that for complex structures you've got to call a metho…

> If both times have mono time, then Equal() compares that, and ignores wall time. Gotcha, I missed that somewhere. That's essentially fine - then the only real surprises are when you deserialize a Time (so it doesn't have a mono time), which should in principle have no interactions with this proposal. And yeah, Equal vs ==, the meaning was clear enough that I didn't bother to be specific :) Thanks for the infos!

Cheers!

Re: The State of Go

#397

Post by vorg »

zirtec wrote: post #90

Definitely the talk I enjoyed the most at FOSDEM today. Both instructive, relevant and pleasant to listen to. Glad to see things like sort.Slice or JSON rendering. When you're spoiled with python or groovy, you miss them them badly.

Always good to see features from the likes of Python and Apache Groovy make it into Go.

Re: The State of Go

#398

Post by sjellis »

fnl wrote: post #267
Strom wrote: post #223

Earlier quoted context omitted.

It's even easier to mishandle errors and get deadlocks in C++. That is in addition to all sorts of other fun like buffer overruns. If the team is capable of not messing these things up in C++, then they are more than capable of not messing up in Go.

Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety". But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that…

If you want examples of "industrial-sized" Go projects right now, you may have to look at case studies for proprietary cloud infrastructure, e.g. CloudFlare, Fastly, DigitalOcean, SoundCloud, and SendGrid. These companies obviously don't open up their product code, but they've been happy to share some information about their use of Go.

Re: The State of Go

#399

Post by jgrahamc »

sjellis wrote: post #398
fnl wrote: post #267

Earlier quoted context omitted.

Modern C++14 provides quite good support on those fronts, and modern Java8 has lost most of its "code notoriety". But that's just arguing back and forth. Here's the real argument: What popular OSS projects of noteworthy scale are being developed in Go? I know a few dozens in either Java or C++, and even a few fairly noticable Scala projects (Spark, Flink, Play, ...), but I yet have to see anything written in Go that…

If you want examples of "industrial-sized" Go projects right now, you may have to look at case studies for proprietary cloud infrastructure, e.g. CloudFlare, Fastly, DigitalOcean, SoundCloud, and SendGrid. These companies obviously don't open up their product code, but they've been happy to share some information about their use of Go.

We share quite a lot of code: https://cloudflare.github.io/#cat-Go

Re: The State of Go

#400

Post by Zancarius »

dvirsky wrote: post #361
MichaelRenor wrote: post #276

Earlier quoted context omitted.

Not only that, but rarely am I supporting a library that I'm the sole developer on. Go takes away so much "individuality" of code. On most teams I've been on with Python and Java I can open up a file and immediate tell who wrote the library based on various style and other such. It's a lot harder with Go and that's a very good thing.

Yeah, at times the obsession of gophers with "idiomatic code" is annoying. But when you read someone else's code and it's idiomatic, you almost immediately have an intuitive sense how it works and can understand and modify it easily. Compared to Java OO code where you have to start chasing inheritance layers to find out where the piece of logic you're actually interested in resides...

I never really stopped to think about it until I read your comment, but I just realized the same applies to old Go code. As some of mine is approaching probably close to 2-3 years (and few things I haven't touched or looked at since!), and while it certainly could be rewritten to be better, it's interesting that Go's partial enforcement of idiomatic authorship appears to reduce the number of WTFs generated as a consequence of atrophy over time, to say nothing about how much less time is spent understanding the code.

Perhaps it's psychosomatic, but it sure seems easier to pick up something written in Go--long since forgotten--than it is in other languages. Then again, maybe it's also that Go taught me to substitute cleverness with terseness. The advantage here is that I've never been especially clever.

Interesting!

Post reply on HN