Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go 1.13 Release Notes

golang.org

Post reply on HN
Print view View original

131–140 of 264 posts

Re: Go 1.13 Release Notes

#131

Post by littlestymaar »

sime2009 wrote: post #79
pcwalton wrote: post #35

Earlier quoted context omitted.

Rust has broadly the same concurrency support, with a more powerful compile-time race detector (but one that also comes with a learning curve). The main difference is that Go uses M:N threading, while Rust uses 1:1 threading with optional explicit async/await constructs.

For the threading difference, do you mean that Rust needs 'normal' threads plus async/await support, but Go can just lean on its built in concurrency support for both cases? i.e. Go threads instead of explicit async style code.

Your sentence implies that Go green threads can do both of what 1:1 threading and async/await can, but it's more complex than that: there's a tradeoff between the simplicity (only one concurrency primitive) and the capability of the said primitive:

- with it's M:N model, Go cannot really do FFI efficiently, while both 1:1 async/await have no problem with that in Rust.

- goroutines are cooperatively scheduled, while OS thread are preemptively scheduled. If you have hot loops, Go's model won't be able yo guarantee fairness between goroutines, which may be a problem depending on your usage. OS threads don't have this problem.

- with goroutines you won't achieve the level of performance you can reach with async/await.

Go and Rust fills a different niche of programming and take a different stand on this tradeoff: Rust gives you more power at a complexity cost. Go offers you more simplicity, with less power.

Re: Go 1.13 Release Notes

#132

Post by omaranto »

nemo1618 wrote: post #86
omaranto wrote: post #74

I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?

Strings are fixed-size, though. A string is a pointer and a length. It's true that you can't use a slice as a map key, though, even though slices are also fixed-size (pointer, length, and capacity). As I recall, the argument is that the equality rules for slices are unclear. (maps and funcs can't be used as keys either, for the same reason: they're not comparable.) Is a 0-length slice equal to a nil slice? Is a slice…

Maybe "fixed size" was the wrong way to phrase it. What I meant is that a string points to an unlimited amount of data and all of that unlimited amount of data is taken into account when deciding equality of strings. And my question should have been, is string the only datatype with that feature?

If it is, it means Go is like Lua, where if you want to use any compound data structure as a key in a map, you either marshall it to a string or you implement your own hashtable.

In Python you are allowed to use tuples of immutable objects as keys, for example. Much nicer than serializing everything to strings.

As for "in practice this is rarely a problem", I agree, but prefer languages where the standard library doesn't have these arbitrary limitations. For example I might want to implement multivariate sparse polynomials as maps from exponent tuples to coefficients (the polynomial 3 x^2 y^3 z + 7 x y z^4 corresponds to the map {(2,3,1): 3, (1,1,4): 7}). That's straightforward in Python but awkward in Go (in Go I might be tempted to just set a maximum number of variables and use arrays or exponents as keys).

Re: Go 1.13 Release Notes

#133

Post by burntsushi »

pcwalton wrote: post #93
est31 wrote: post #92

Earlier quoted context omitted.

One example where Rust is moving faster than Go is the compiler: * Excluding patch releases, Go has a release twice each year [1], while Rust has a release every six weeks (about 9 times per year) [2]. * For minor (patch) releases (security updates, etc), Rust only cares about the latest version released. Go provides patch releases for the last two releases [3]. * The latest release of the Go compiler (1.13, Sept 201…

Does the compiler bootstrap version matter though? Taking the principle that compilers should compile on the most easily accessible toolchain, writing the compiler in C++ would be the best option of all. But nobody wants to do that.

According to the notes here[1], it sounds like companies care enough about bootstrapping Rust that they are doing it via mrustc. Which seems pretty extreme and suggests they care... a lot. (This was surprising to me to find out, at least, the degree to which they care. I understand why bootstrapping is itself an important ideal.)

[1] - https://users.rust-lang.org/t/rust-in-large-organizations-me...

Re: Go 1.13 Release Notes

#134

Post by est31 »

pjmlp wrote: post #130
est31 wrote: post #104

Earlier quoted context omitted.

Yeah, if you take the principle further it would be even better to write it in C89 because this language is comparatively easy to write compilers for. But the principle is not absolute and it doesn't stand above everything else. There are major differences in how easy it is to write compilers in C++ vs C89. There are major differences between C++ and Rust with its ADTs and pattern matching. But are there major differ…

Why the odd one? D has been replacing the C++ code with D, .NET made a major reboot with Rosyln where VB.NET and C# got bootstraped (F# was already bootstrapped), OCaml and Haskell have only the runtime in C due to convinience with everything else bootstraped, FreePascal is bootstraped, OpenJDK has the long term goal of replacing C++ with Java/Graal, Jikes was bootstraped in Java, ...

You are misunderstanding me. I don't have problems with the fact that Rust is bootstrapped, but with the high rate this bootstrapping is happening. That a 12 week old compiler is already considered as too old to compile the newest rustc. This seems wrong.

Re: Go 1.13 Release Notes

#135

Post by kissgyorgy »

timothycrosley wrote: post #103
axaxs wrote: post #14

Earlier quoted context omitted.

> is it's much more verbose/harder to handle edge cases - it feels like I'm less productive writing the program, but end up building something much more stable than the Python equivalent This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. > I really need the performance for my worklo…

> This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. Luckily, you don't have to choose between those two outcomes: https://github.com/python/mypy

Python's optional type hints even with mypy are nowhere near strict/expressive than a statically typed language like Go. Type hints in Python are an afterthought and it shows in a lot of cases.

Re: Go 1.13 Release Notes

#136

Post by xvector »

zadokshi wrote: post #127
xvector wrote: post #116

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…

Hmm, you definitely have a point. I was thinking more API tokens and private keys, but confidential data itself falls into a separate category, it cannot be revoked or rolled.

Re: Go 1.13 Release Notes

#137

Post by ben_jones »

mfer wrote: post #52

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/

I think this is a perfect example of a completely rational implementation that given all the facts almost all developers would agree to - except because of Google's reputation for pervasive tracking, abruptly sunsetting popular products, and general we-know-better approach to software, will become a point of flak for the core Go team.

To be abundantly clear, and because a lot of Google employees read this, the we-know-better comment isn't a jab - because often Google engineers DO know better, but it does occasionally mix with i.e. poor communication and create frustration for the many developers who use Google services and tools.

Re: Go 1.13 Release Notes

#138

Post by omaranto »

ainar-g wrote: post #83
omaranto wrote: post #74

I haven't been keeping up with Go. Is it still the case that the only datatype than can be used as keys to a map and is not of a fixed size is string?

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 there is a type of array of 5 ints, a type of arrays of 8 ints, etc. Each of those is of limited size.

A slice is like a string, it can point to an arbitrary amoun of data, but slices are not allowed as map keys.

A struct has a fixed number of members and is only allowed as a map key if all of its members are of types allowed as maps keys.

So a struct type that is allowed as a map key type can only point to unlimited data all used for equality if it contains directly or indirectly a string somewhere. Among types allowed as keys, the only source or arbitrary-sizedness are strings.

For example, if you want to represent multivariate polynomials sparsely as a map from exponent vector to coefficients (i.e., the polynomial 3x^2y^3-7xy^4 corresponds to the map {(2,3)=>3, (1,4)=>-7}) you can only do it in Go with the built-in maps awkwardly. You could pick a maximum number of variables and use arrays of exponents as keys. You can leave the number of variables arbitrary and convert exponent vectors to strings (i.e., use {"2,3"=>3, "1,4"=>-7}). I find it frustrating that those are my options.

Re: Go 1.13 Release Notes

#139

Post by mfer »

TheDong wrote: post #113
rgbrenner wrote: post #111

Earlier quoted context omitted.

First programming language that I've had to read and understand a privacy policy to use.. and consider that it may change in the future. The idea that the language I'm programming in now reports anything back to google is distressing.. and I say that as someone who has been programming in Go for about 7 years. What right does google have to collect usage information from modules hosted on github (or elsewhere)? I che…

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

There is a difference between npm, perl, and the others mentioned and Go. Go is Google with a diverse set of products and services. Many people who use Go build competitive services to Google.

What company is using python and building something in competition to the python software foundation? Or something for the others?

This difference is worth taking into account. If Go were part of a software foundation like Python this would be a different story.

Re: Go 1.13 Release Notes

#140

Post by timothycrosley »

kissgyorgy wrote: post #135
timothycrosley wrote: post #103

Earlier quoted context omitted.

> This is exactly how I felt moving from a Python codebase to Go. But you realize on the 100th or so Python stacktrace that it's worth the investment up front, if not for type safety alone. Luckily, you don't have to choose between those two outcomes: https://github.com/python/mypy

Python's optional type hints even with mypy are nowhere near strict/expressive than a statically typed language like Go. Type hints in Python are an afterthought and it shows in a lot of cases.

Do you have any concrete examples?
Post reply on HN