41–50 of 51 posts
"Go programs currently compile to one WebAssembly module that includes the Go runtime for goroutine scheduling, garbage collection, maps, etc. As a result, the resulting size is at minimum around 2 MB, or 500 KB compressed." considering it includes the runtime, this isn't a large file compared to images / videos you find on the web today
You can’t compare images with code. 500kb is a ton of code.
I wonder when Go is planning to stop using the kernel ABI on BSDs and macOS directly - in direct contradiction to stability guarantees (or lack thereof) by those platforms - and start using the appropriate APIs, such as libc. Or is it going to be stuff like this or https://github.com/golang/go/issues/16606 forever? Right now, I stay away from Go partly because of this - it feels like a bad idea to use a software stack that is guaranteed to be broken on future OS releases by design. Especially when that stack is advertised specifically for system programming...
> Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4. I wonder when Go is planning to stop using the kernel ABI on BSDs and macOS directly - in direct contradiction to stability guarantees (or lack thereof) by those platforms - and start using the appropriate APIs, such as libc. Or is it going to be stuff like this or https://gith…
"On macOS and iOS, the runtime now uses libSystem.so instead of calling the kernel directly. This should make Go binaries more compatible with future versions of macOS and iOS."
> Go 1.11 supports the upcoming OpenBSD 6.4 release. Due to changes in the OpenBSD kernel, older versions of Go will not work on OpenBSD 6.4. I wonder when Go is planning to stop using the kernel ABI on BSDs and macOS directly - in direct contradiction to stability guarantees (or lack thereof) by those platforms - and start using the appropriate APIs, such as libc. Or is it going to be stuff like this or https://gith…
https://golang.org/doc/go1.11#runtime "On macOS and iOS, the runtime now uses libSystem.so instead of calling the kernel directly. This should make Go binaries more compatible with future versions of macOS and iOS."
Earlier quoted context omitted.
I vaguely recall wanting relative imports back when I first started dabbling with Go. Then I moved on and really have completely forgotten it was an issue. If you want to fork a project, I'm pretty sure there's a program (gorename maybe?) that rewrites these import paths for you, but I've always just used `sed`. I haven't used Elm, but Node's `node_modules` folder has always been a hassle. Grepping for anything is a…
Either "git grep" or configuring your ack/ag/... properly solves the search issue.
Earlier quoted context omitted.
Eh, it wasn’t the best, but it was still better than any other language’s equivalent except for Rust’s. In any case, modules have worked wonderfully for me so far.
> Eh, it wasn’t the best, but it was still better than any other language’s equivalent except for Rust’s. I disagree. Gopath was the most brain-dead idea being implemented in a current programming language. It handled the problem in a far worse manner than any other programming language in current use. This problem was then made far worse by the way the language developers insisted in forcing it upon go users in spit…
Of possible interest, I gave a talk about "Go 1.11 & Beyond" (read: "Go 2") a couple weeks ago: https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj... (See speaker notes for more context)
Thank you very much!
Of possible interest, I gave a talk about "Go 1.11 & Beyond" (read: "Go 2") a couple weeks ago: https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj... (See speaker notes for more context)
Brad, is this presentation available anywhere else (say, exported to PDF)? Our company blocks all sharing sites, so docs.google.com is no go for me (and I cannot reshare it with my team). Would it be possible for you to drop it on golang.org somewhere? Thank you very much!
Of possible interest, I gave a talk about "Go 1.11 & Beyond" (read: "Go 2") a couple weeks ago: https://docs.google.com/presentation/d/1EwuJhEHR5Trr2aXBPQaj... (See speaker notes for more context)
Brad, is this presentation available anywhere else (say, exported to PDF)? Our company blocks all sharing sites, so docs.google.com is no go for me (and I cannot reshare it with my team). Would it be possible for you to drop it on golang.org somewhere? Thank you very much!
Earlier quoted context omitted.
You can write `import "./util"` Also, it's really not that bad considering that go works (`go get` grabs git repo) with git repos. So you can go into your GOPATH (or vendor dir) and checkout your fork in place of the origin. In the end, a little pain to get started to get used to it, then it's second nature.... but I suppose if you primarily work in other languages it is likely tiresome.
All three replies to me suggest that you can do relative imports in Go. Can you link me to documentation that demonstrates them? I don't understand. Either relative imports are not supported or they only work in some context that nobody uses. BTW I'm not a Go beginner, and my issues with Go aren't just an issue with "getting started" as you suggested. I just tried them in an existing Go project and I get the usual "c…
----
Yes, it is easy to forget that we use vendoring to get around these issues (and for other reasons).