241–250 of 264 posts
Earlier quoted context omitted.
Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.
When did Java get versioned modules, value types, installable binaries, dynamic heap size?
Earlier quoted context omitted.
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.
They're offering a cryptographically signed mirror - the first mainstream one available. You can either run your own personal mirror, run one for your company, or turn it off.
But why? Who asked for this??
Contrary to what someone else has said, this is my least favorite release of Go ever. I'm salty about how the proxy, which is enabled by default, makes it so much more difficult to pull private modules by having to set environment variables on everyone's individual machines. I've got an issue being discussed on GitHub about it https://github.com/golang/go/issues/33985
go env -w GOPROXY=direct go env -w GOSUMDB=off
Earlier quoted context omitted.
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.
Do you include web development in that ?
Something different than that? Yes.
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…
This has probably been the case since Go 1.11 (2018/08/24)[0] 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. I'm not an expert in Darwin, but looking at the implementation of the syscall and…
That they don't run into issues with this constantly on BSD is not surprising - it didn't always break in macOS, either. Syscalls just don't change that much, usually, so you can get away with it more often than not. The problem is that when they do change eventually, every precompiled Go app that used one stops working.
Earlier quoted context omitted.
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?)
> Could you expand on what you think is hard about the concurrency in Go? 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 re…
I haven’t really benchmarked channels since the bottlenecks in code I write tend to be I/O, but I’ll play around a bit to understand that better.
Earlier quoted context omitted.
The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. Perhaps I’m old and grumpy but I feel that at this point I’ve had every language discussion before and if people start to moan about lack of metaprogramming support I just leave. I have yet to see a project that failed due to lack of high order abstractions
I have yet to see a project that failed due to being written in Assembly, yet we moved on to better abstractions.
I’ve also abandoned a few paths during projects because of libraries that were overly abstract, didn’t work and were thus hard to understand and maintain.
A product at a company I used to work for had to reimplement a huge chunk of code because the original designer left and the metaprogramming behemoth he wrote was too hard to understand, extend and debug. That one chunk of code cost about $500k and 6 months to replace. I’m unsure of the total cost of that effort as it delayed the next release at a critical time.
Abstraction levels need to be appropriate. Enough to make things simple - not so much that it makes life harder.
Earlier quoted context omitted.
The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. Perhaps I’m old and grumpy but I feel that at this point I’ve had every language discussion before and if people start to moan about lack of metaprogramming support I just leave. I have yet to see a project that failed due to lack of high order abstractions
> The way I view it is that Go is for people who write software while Rust is for those who like to think about how to write software. More accurately speaking, Rust forces people writing software in a specified way. You need to think about how to write software much less in Rust than in Go. In Go, you really need to think more to choose a better solution from many potentials.
And mind you: I manage quite a few projects where Rust would be a great fit because it would replace C/C++, but for embedded projects Rust just isn’t getting the traction it needs to convince key industry players.
Earlier quoted context omitted.
I have yet to see a project that failed due to being written in Assembly, yet we moved on to better abstractions.
I’ve worked on two projects (in early x86 assembler) that ran out of steam because they took too long to do and it was hard to onboard new developers. I’ve also abandoned a few paths during projects because of libraries that were overly abstract, didn’t work and were thus hard to understand and maintain. A product at a company I used to work for had to reimplement a huge chunk of code because the original designer le…
Earlier quoted context omitted.
Compatible with what exactly. No one uses octal. Here is a link to Pike fucking it up 10 years ago. https://github.com/golang/go/issues/151#issuecomment-6604830...
Lots of code uses octal. Its still the standard way of notating file permission bits on unix: os.Chmod(filename, 0777). You would break so much code if you just threw that away.
Nice example of something else that should have been depreciated about 35 years ago.