Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
kokada
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
15 ms
·
211.
▲
by
kokada
2y ago
I don't think Lennart changed his opinion, if you look further in this thread[1] Lenart wasn't ever against musl per se, it is more like "we use non-POSIX features from glibc that we found useful, and we are not going to rein
212.
▲
by
kokada
2y ago
Thanks, fixed. Definitely need to have some way to check those links automatically.
213.
▲
Making a blog for the next 10 years
(kokada.dev)
8 points
by
kokada
2y ago
|
3 comments
214.
▲
by
kokada
2y ago
> That is good to know, assuming that the newer hypothetical toolchain is not vulnerable (e.g. a zero-day in the newer toolchain). This would still be really difficult to explore: 0. An undiscovered zero-day in the newest version o
215.
▲
by
kokada
2y ago
Author here. In Go case though the version can only go higher, not lower (e.g.: it will not download a toolchain if the Go version is set to lower than your current one, only higher). So I can't see the same attack being executed here.
216.
▲
by
kokada
2y ago
Author here. I think you misundertood how this feature works. If you have a `go.mod` that sets a `go` directive with a version bigger than the version your Go toolchain is currently running, it will download the binary automatically and pas
217.
▲
by
kokada
2y ago
Author here. You are confusing the `go` toolchain and the binaries generated with Go toolchain. The `go` toolchain itself is compiled statically, this is why this works without issues even in NixOS. Binaries built with the toolchain may or
218.
▲
by
kokada
2y ago
Author here and NixOS user. This works even in NixOS, because `go` toolchain is statically compiled.
219.
▲
by
kokada
2y ago
I do something similar to my blog, I even wrote an article about it (that is out-of-date, but the idea is the same): https://kokada.capivaras.dev/blog/using-github-as-a-bad-blog... . Basically I write the posts in Markd
220.
▲
by
kokada
2y ago
Author here, also a big user of NixOS. But strangely I liked this feature, mostly because it allows me to use newer features without needing to wait nixpkgs to update the Go compiler to the version 1.23. It is easy to disable if you don
221.
▲
by
kokada
2y ago
Author here. What I meant is that the toolchain itself is linked statically, this is why it can be just downloaded from the internet and it will work without extra setup from the user. Yes, Go will build the libraries once you call `go buil
222.
▲
by
kokada
2y ago
Author here. This doesn't make sense. The toolchain will be updated only IF you say your project only runs in Go >= XX. This is what `go` directive in `go.mod` says: my projects doesn't work in versions of Go older than this. T
223.
▲
by
kokada
2y ago
I think I recommend you reading the proposal them. I don't claim of being a specialist in Go to say if it is possible or not, but I find it highly unlikely given how the language is. The reason I think nullability is more likely than s
224.
▲
by
kokada
2y ago
I didn't develop too much because as I said in another thread, I wrote this post without giving much thought. Sorry for not being at the HN standards, but this post wasn't even supposed to be here, and here we are ;). That said, I
225.
▲
by
kokada
2y ago
> The parent's point is that this is still within the guarantees hashmap (the abstract data structure) gives about order: none. This is not the point from the parent point, at least nothing else in the text suggests so. > All the
226.
▲
by
kokada
2y ago
That is still a valid expectation, just look at other commenters on the thread that they also find the behavior surprising.
227.
▲
by
kokada
2y ago
Yes, I did cover this point in the post, but basically the main issue of not having this in stdlib is because now the choice is not obvious: if you search "ordered map for golang" you will find a dozen of different implementations
228.
▲
by
kokada
2y ago
I didn't say this is error handling, this is a stack trace for debugging on error. Similar to an uncaught exception in other languages. And yes, I will not use this on production applications or libraries, I mostly use this in scripts
229.
▲
by
kokada
2y ago
I never said once that the implementation is incorrect, just that it is weird and uncommon.
230.
▲
by
kokada
2y ago
I talked in my previous post ( https://kokada.capivaras.dev/blog/go-a-reasonable-good-langu... ) that nowadays I just implement a generic `must*()` family of functions that can be used as: func must(err error) {
231.
▲
by
kokada
2y ago
> simply adding an element and then immediately removing it with no lines of code in between those two calls was enough, in some cases, to completely mess up whatever order I thought there was. Yes, this is what I expect too. But this is
232.
▲
by
kokada
2y ago
> It was stable for any one run :D Not even that, because if you iterate multiple times you get random order in each different iteration: package main func main() { m := map[string]bool{"foo": true, "b
233.
▲
by
kokada
2y ago
> First, assuming that the keys iterate in the order they're inserted, the cliche problem. Author here. I never assume that hash maps can be iterated in the same order as the insertion in any language, however the fact that in Go ea
234.
▲
by
kokada
2y ago
I think you're nitpicking about semantics, but ok. > In any hashmap, it's a given that you cannot rely on the order. Again, any order was fine, as long it was stable (it could be even stable between compiled versions, if Go say
235.
▲
by
kokada
2y ago
BTW, I will confess: the orderedmap one is something that I put mostly because I know it is something that would be feasible to implement in a future version of the language and it would probably be relatively uncontroversial. So I was expe
236.
▲
by
kokada
2y ago
Author here. > The specific examples don’t ring true to me though. And I don't think it should. To start, the list is small because it is a work in progress, I plan to write more once I have more to talk. I didn't expect this p
237.
▲
by
kokada
2y ago
Author here. The fact that `strings.ReplaceAll` exists I think is a good argument for having default arguments, because I can't think of a good reason why we need a separate function for this case. But maybe it was a bad example. I rem
238.
▲
by
kokada
2y ago
Author here. I never expected this post to get here in HN the way it was. It is definitely a work in progress, most some personal notes that I will probably add more when I use other parts in Go that bothers me.
239.
▲
by
kokada
2y ago
> Even if they didn't randomize, unless they also explicitly guaranteed stable map order across versions, you DO need to sort the map if you want reproducibility. Author here. The particular case where this behaviour took me by surp
240.
▲
by
kokada
2y ago
> My experience in that respect was just the opposite of yours: just barely OK at the beginning, and quick degradation in spite of the adaptive battery. In 2 years it wouldn't even make it to 3 PM in days of heavy usage. Definitely
More ›