181–190 of 264 posts
Earlier quoted context omitted.
Would it be fair to say that Go's concurrency support makes it a good match in the network services space? I see Go more often in Docker and cloud contexts.
Yes, Go is in many ways a DSL for writing servers. IMO it should be the default language you reach for when starting a new server project.
I like the way Go proceeds as a language, with features added very very slowly and the compiler and tools regularly improving. I hope Rust can settle down into a similar focus soon.
Sure, async needs to be shipped and polished, but then Rust needs to tell the world: "We have all you need and as stable as you need."
Earlier quoted context omitted.
It brought one of my favorite parts about writing numbers in languages such as Ruby over to Go. From 10000000 to 10_000_000 is such a readability improvement and should be no-cost.
> From 10000000 to 10_000_000 is such a readability improvement and should be no-cost. 1e7
Is a float literal.
Earlier quoted context omitted.
Personal opinion: no. Go's concurrency is hard to control or monitor, and it's hard to make higher level abstractions that are both safe and convenient. It's of course possible, but the tradeoffs are rather severe. Go's concurrency shines best in short-lived single-purpose processes, which is a near perfect fit for CLI tools. When you don't care if something gets abandoned or fails to make progress and can just ctrl-…
Could you expand on what you think is hard about the concurrency in Go? (And perhaps give an example of a language that makes it easy/easier?)
Go's concurrency is cheap[0] multithreading (shared-memory concurrency). It has a tagline that you should not share memory ("Do not communicate by sharing memory; instead, share memory by communicating"), however nothing prevents sharing memory (so it will eventually leak in) and channels are pretty slow[1] so it's not uncommon to go back to regular shared-memory primitives (with no safety net).
You've got no idea what your application state really is (even less so once things start falling over), and there are no built-in tools for reliability e.g. you can't get notified that a goroutine has keeled over or anything unless you implement that yourself.
> And perhaps give an example of a language that makes it easy/easier?
Erlang / elixir was built specifically with that in mind. It uses lightweight shared-nothing concurrency (non-OS processes) and the system builds-in ways for processes to have oversight over others (e.g. monitors & supervisors) or get killed alongside them (links) and provides behaviours which bundle known patterns, etc…
[0] as in "not expensive", as in uses quite a bit less memory & especially kernel resources than OS threads or processes[1]
[1] though this point should not be too overstated, people commonly misuse "the C stack is XMB" with "creating a thread consumes XMB of physical memory", a C stack is mostly a regular allocation and thus usually just VSS until actually exercised
[2] and not necessarily a huge gain in bug-freedom: https://songlh.github.io/paper/go-study.pdf
Earlier quoted context omitted.
> This is the first language in my 23 years programming that reports my usage back to the language authors I suppose that means you haven't used any of: 1. nodejs, which reports your usage back to npm Inc with the exact same amount of detail (names of dependencies, ip of caller) (and stores much more, since it publishes 'downloads per month', etc) 2. rust, which does the same with crates.io 3. perl, which does that w…
If I download something from a server, of course that server knows what I downloaded. This is different. It’s a proxy in front of others repositories. They want info on downloads from GitHub, gitlab, and anywhere else you get code from. They (google) are a 3rd party to the download.
Earlier quoted context omitted.
> This "feature" should have an option to disable it.. at the very least. You should be able to. It's not the ideal solution (or recommended for most use cases), but you can by setting GOPROXY=off. GOPROXY=direct will force it into its previous behavior. The same should be true for the checksum DB with GOSUMDB=off. I don't remember specifically and can't find the page its options were documented on. Also look at GOPR…
IMO, using an environment variable for that is not robust. If the environment variables have been cleared (for instance, due to "su -" or similar), or if they have never been set (for instance, because you just checked out the code on a new machine and forgot to configure the environment variables there, or because you did remember to configure the environment variables but forgot that startup scripts do not take eff…
But, it's still possible to disable these features, so it's not quite as bad as the OP suggested.
Earlier quoted context omitted.
I'm not sure what you're talking about. Map keys in Go can be strings, numbers, pointers, some structs, etc. And that was the case since at least Go 1.0.
I always have trouble explaining this limitation of Go maps. First, a string can point to an unlimited amount of data (i.e., it can be of arbitrary length) and all of its characters are taken into account when deciding string equality. Now, an array type in Go is not like that: the length of the array is part of the type. There is (or at least there wasn't when I last checked) no type of all arrays of ints, say, but…
[1]: https://go.googlesource.com/proposal/+/58566e5309365c84587ae...
Looking at the release notes: > Go 1.13 now requires macOS 10.11 El Capitan or later; support for previous versions has been discontinued. > Go 1.13 now requires FreeBSD 11.2 or later; support for previous versions has been discontinued. FreeBSD 12.0 or later requires a kernel with the COMPAT_FREEBSD11 option set (this is the default). Sounds like they're still using syscalls directly on those platforms. Is Google ev…
On macOS and iOS, the runtime now uses libSystem.dylib
instead of calling the kernel directly. This should make
Go binaries more compatible with future versions of
macOS and iOS. The syscall package still makes direct
system calls; fixing this is planned for a
future release.
FreeBSD looks deprecated not because of syscall difficulties, but because missing functionality and upstream EOL.[1]
[0]: https://golang.org/doc/go1.11#runtime [1]: https://github.com/golang/go/issues/27619
Earlier quoted context omitted.
> This "feature" should have an option to disable it.. at the very least. You should be able to. It's not the ideal solution (or recommended for most use cases), but you can by setting GOPROXY=off. GOPROXY=direct will force it into its previous behavior. The same should be true for the checksum DB with GOSUMDB=off. I don't remember specifically and can't find the page its options were documented on. Also look at GOPR…
IMO, using an environment variable for that is not robust. If the environment variables have been cleared (for instance, due to "su -" or similar), or if they have never been set (for instance, because you just checked out the code on a new machine and forgot to configure the environment variables there, or because you did remember to configure the environment variables but forgot that startup scripts do not take eff…