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

381–390 of 402 posts

Re: The State of Go

#381

Post by IshKebab »

steveklabnik wrote: post #193
IshKebab wrote: post #82

Earlier quoted context omitted.

I think that's mostly because Go trivially generates static binaries, and cross-compiling is also trivial (as long as you don't use CGo). I can't actually think of a single other language that matches that. Rust might get there one day but cross-compiling still requires a C cross-compiler (ugh) and C dependencies (e.g. OpenSSL) are often dynamically linked.

Cross compiling shouldn't require a C compiler unless you have a dependency on C code. Most wrappers should at least provide an option to statically link the C; I know the OpenSSL ones do.

Not a C compiler, but you need a C linker, which is just as much hassle. Apparently there is work going on to use LLVM's lld linker, which I guess might support cross-compiling in a sane way but I haven't checked.

And yeah most wrappers provide a static linking option but there's not much consistency which is rather annoying.

Re: The State of Go

#382

Post by 4ad »

Hydraulix989 wrote: post #379
4ad wrote: post #377

Earlier quoted context omitted.

I did use that, but it is orders of magnitude too slow (not to mention unavailable for the Go team at large).

Generally, compiler development is the intended use case of these emulators. I'm pretty unsympathetic when you say that; yeah, it's slow, it's an emulator, and using it is part of your job description. I wasn't aware the Go team at large all had or needed hardware for all targets? I've done Linux kernel dev without a SPARC, Alpha, etc. Google and first-class contributors to the ARM6 target (I'm sure a relatively smal…

First of all, we do use emulators. Personally, as a Go compiler author I have written several emulators to develop (or debug) several Go ports, and I have used many emulators written by others, ranging from open source, to commercial, and even to secret emulators that have never left the hardware division department.

Yes, as a compiler writer I deal with how painfully slow these emulators are. Usually it's not a problem. When it's a problem, the payout is usually large enough so that modifying the tests is a good idea.

But all of this doesn't matter in general, we were discussing about the Go continuous integration builders. These tests run for every commit (and even before commit), for every change, from any contributor, and test everything. Emulators, even fast and inaccurate ones, and even most low-end hardware is simply too slow to allow for this.

Funny you mention ARM and "discounted licenses", because we've been under negotiations for several years to get something like that from them, and even though the arm64 Go port was commissioned by ARM, we still didn't get it yet. I've been promised we'd get what we need, but the bureaucracy and lawyers and approvals simply make any endeavour like this take literally years, and what we will get in the end is something that can be used by a select few, not by any potential Go contributor.

Yes, the Go project has access to all targets. It's all real hardware. It's a requirement for any new port. And every change is tested and must not break any target.

Re: The State of Go

#383

Post by AnimalMuppet »

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

Well, "idiomatic code" can often mean "for what you're trying to do, there is a way that works with the language better than any other way; do that". That is, it often means "working with the tool rather than fighting it". So, yeah, do it the idiomatic way unless another way is clearly better. (Idiomatic ought to win if evaluating "better" gives you a tie, because idiomatic will be more readable.)

Re: The State of Go

#384

Post by dilap »

Groxx wrote: post #181
dilap wrote: post #171

Earlier quoted context omitted.

There's no denying it's at least flirting with "too clever" territory. What saves it for me is (1) the analysis of a large body of code that seemed to show only positive impact (2) that the behavior is well-documented and (3) anytime you're converting between types, you should always be thinking, "what is the range of these types? what information might get lost?", which with (2), should leave you alright. But, I cou…

"Should", definitely :) Easier said than done. But I'm happy to wait and see, it's not like this would make Go the only language with weird time handling. As it stands they're probably in a better place than most people are used to. That code-corpus-analysis is pretty neat, I hadn't looked through in detail before. Thanks for pointing it out! --- Sorta as an aside, it seems the proposal can lead to: t1 = time.Now() .…

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.

Re: The State of Go

#385

Post by danellis »

pvg wrote: post #368
coldtea wrote: post #362

Earlier quoted context omitted.

If Apache is "systems programming" then why not one of the various web servers written in Lua or Python or whatever? Are those then "systems programming languages" too?

Nope.

But is the activity of writing a web server in Lua or Python system programming?

Re: The State of Go

#386

Post by [deleted] »

4ad wrote: post #382
Hydraulix989 wrote: post #379

Earlier quoted context omitted.

Generally, compiler development is the intended use case of these emulators. I'm pretty unsympathetic when you say that; yeah, it's slow, it's an emulator, and using it is part of your job description. I wasn't aware the Go team at large all had or needed hardware for all targets? I've done Linux kernel dev without a SPARC, Alpha, etc. Google and first-class contributors to the ARM6 target (I'm sure a relatively smal…

First of all, we do use emulators. Personally, as a Go compiler author I have written several emulators to develop (or debug) several Go ports, and I have used many emulators written by others, ranging from open source, to commercial, and even to secret emulators that have never left the hardware division department. Yes, as a compiler writer I deal with how painfully slow these emulators are. Usually it's not a prob…

[deleted]

Re: The State of Go

#387

Post by solidsnack9000 »

geoka9 wrote: post #371
josteink wrote: post #356

Earlier quoted context omitted.

Typescript has thee same. Ditto with C#. Python is pretty close. Same with most LISPs. In Emacs too. I'd hardly say this is a unique selling point of Go.

Do they do static analysis of code? The problem is that with other languages they all work "sort of". For example, for Elpy: "the backends can not always identify what kind of symbol is at point. Especially after a few indirections, they have basically no hope of guessing right, so they don’t" With go guru it just works, always, no matter how deep you drill into the graph (that's what I meant by "first class").

The issue there is that Python is a dynamic language. Syntactic resolution of what a "thing" is in, in some sense, not supposed to always work -- otherwise it would be a static language!

Being able to recognize what a syntactic entity represents -- type or value or whatever -- has been supported by the editor plugins for static languages for a very long time.

Re: The State of Go

#388

Post by ice109 »

shard972 wrote: post #349
ice109 wrote: post #270

Earlier quoted context omitted.

I'm starting a backend job tomorrow that's all Haskell. what are people's complaints?

The main one I see is that it is too hard for programmers who don't fully understand haskell/functional programming. I see people complain at times about it's performance but there is always someone there to rebut that it's fast at some things but not others.

yea compile times are killing my ability to iterate.

Re: The State of Go

#389

Post by geoka9 »

solidsnack9000 wrote: post #387
geoka9 wrote: post #371

Earlier quoted context omitted.

Do they do static analysis of code? The problem is that with other languages they all work "sort of". For example, for Elpy: "the backends can not always identify what kind of symbol is at point. Especially after a few indirections, they have basically no hope of guessing right, so they don’t" With go guru it just works, always, no matter how deep you drill into the graph (that's what I meant by "first class").

The issue there is that Python is a dynamic language. Syntactic resolution of what a "thing" is in, in some sense, not supposed to always work -- otherwise it would be a static language! Being able to recognize what a syntactic entity represents -- type or value or whatever -- has been supported by the editor plugins for static languages for a very long time.

For sure, but then there are mainstream static languages like Java/Scala which still lack that kind of support (e.g. ensime and friends, which work unpredictably, if at all).

Re: The State of Go

#390

Post by Groxx »

dilap wrote: post #384
Groxx wrote: post #181

Earlier quoted context omitted.

"Should", definitely :) Easier said than done. But I'm happy to wait and see, it's not like this would make Go the only language with weird time handling. As it stands they're probably in a better place than most people are used to. That code-corpus-analysis is pretty neat, I hadn't looked through in detail before. Thanks for pointing it out! --- Sorta as an aside, it seems the proposal can lead to: t1 = time.Now() .…

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, 20]
I'd expect those to be different, since they represent different wall-clock times.
Post reply on HN