171–180 of 264 posts
Earlier quoted context omitted.
Mysterious hacker news downvoting! This my preferred way of writing numbers with lots of 0s as well.
But underscores also work for numbers that don't have lot of zeros. Compare: 12_345_678 1.2345678e7
Kind of realising how much of my daily work could use bytes as the main numeric type
Earlier quoted context omitted.
Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, m…
> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.
Earlier quoted context omitted.
Can you explain why they're wrong?
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.
Earlier quoted context omitted.
When did Java get versioned modules, value types, installable binaries, dynamic heap size?
Installable binaries, around 2000, when the first commercial JDKs started having AOT compilation to native code. Currently available on PTC, Aicas, IBM, OpenJDK AppCDS (originally from BEA J/Rockit), GradleVM native images, Android ART AOT compilation. Dynamic heap size, since ever. Every JDK vendor had their own specific switches to configure it. Versioned modules, since Java 9 alongside Maven/Gradle. Value types, y…
Honestly, and I don't think I'm snarking (but would have to reflect a bit on it), "0b", "_", and signed shifts are probably going to make Go more pleasant for me than generics would have. This is my favorite release in years.
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.
O_o
Earlier quoted context omitted.
The reason cgo is (relatively) slow is small stacks, not M:N threading. Small stacks (and M:N threading) are needed to efficiently implement tens of thousands of goroutines. CGO is slow mostly because it needs to switch to a larger stack when calling a C function. It's a trade-off. A different Go implementation could make Goroutines map 1:1 to threads and have fast cgo calls at the expense of slow goroutines. Rust is…
> Small stacks (and M:N threading) are needed to efficiently implement tens of thousands of goroutines. Tens of thousands of threads are no problem with 1:1 threading on Linux. > They paid with slow threads. I would not call 1:1 threads "slow threads". If they were slow, then the 1:1 NPTL would have not defeated the M:N NGPT back in the day when this was being debated in the open source OS community. > complex rewrit…
Yes it's a problem, even on modern kernel, memory, context switch ... there is a reason why high performance code uses small thread pool.
I started poking around and noticed that Go 1.13 now defaults to the Golang Proxy to fetch modules. This means a proxy, governed by the Google Privacy Policy, is now capturing everyone's module usage by default. Unless you change settings this includes proprietary/corp stuff. https://codeengineered.com/blog/2019/go-mod-proxy-psa/
While opt-out for this not ideal, this seems like a minor privacy risk relative to the security risks ameliorated by enforcing checksums by default.
I guess an option which solves would be a mandatory prompt about proxy usage unless there is an explicit environment variable set?
Earlier quoted context omitted.
If you commit and push your credentials, they have been compromised, full stop. This proxy should make no difference to how you handle such a compromise.
Actually it does make a difference. If an employee accidentally commits a CSV file with customer private data, are you actually suggesting that it should not be possible to remove it? I disagree. The quicker that the personal data can be taken down, the less chance there is for someone to discover that personal data. I can't imagine any large company being comfortable with developers choosing technology that makes th…
On the other hand, proxy.golang.org re-hosts your module, and you can know that the proxy isn't serving you maliciously or differently than anyone else by verifying it via the public checksum database at sum.golang.org.
I don't believe proxy.golang.org, or any proxy for that matter, is required to host all of the modules and versions listed. It's a dumb caching proxy, and must deal with all of the real world complexities of hosting user content, including taking it down if deemed necessary. So if they need to take something down from the proxy they can, and the checksum database will only permanently retain the hash of the content that makes up the module.
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…
Oh my god why?