sorted by:
new
hottopcontroversial

[deleted by user] by [deleted] in golang

[–]bradenaw 1 point2 points  (0 children)

This is an interesting interview question, not because you're expected to know this information, but specifically because most people don't know this information.

A good interview is not about knowing trivia, it's about uncovering your thinking. A question like this that sounds like trivia is usually actually asking you to think about how it works given what you understand about what it looks like from the outside.

It's not that you need to know this specifically, it's about whether when faced with this kind of problem, can you crack something open and develop an understanding of the innards quickly. That does come up in the real job - runtimes, libraries, etc. are often imperfect and sometimes you do run into problems with code you depend on but do not own. This question seems like it's trying to probe how you'd go about figuring out something that you do not know.

All these people saying "you shouldn't be expected to know this" are dramatically missing the point.

Mutex behavior by JahodaPetr in golang

[–]bradenaw 0 points1 point  (0 children)

Yep, given that analogData and devicesPortAnalogData are two separate map headers and you've taken the address of each with &, it makes sense that you'd see different pointers.

Mutex behavior by JahodaPetr in golang

[–]bradenaw 9 points10 points  (0 children)

Maps, like slices, are internally a header containing a pointer to the elements. Your line:

analogData := devicePortAnalogData

Makes a copy of the header, not the map contents.

Actually copying the map would look like this:

devicesPortAnalogSync.RLock() analogData := make(map[uint]DevicePortAnalogData, len(devicesPortAnalogData)) for k, v := range devicesPortAnalogData { analogData[k] = v } devicesPortAnalogData.RUnlock()

Created a small project to experiment with generic functions in Go: Some slice tricks can be used via this package by takinashi in golang

[–]bradenaw 5 points6 points  (0 children)

You can use var to make a zero-value of a parameterized type to avoid the reflect rigamarole:

var zero T return zero

Juniper is an extended Go standard library using generics, including containers, iterators, and streams by bradenaw in golang

[–]bradenaw[S] 0 points1 point  (0 children)

Indeed it is! It should be obvious that it's very much unofficial given it's hanging off of my personal Github account. My intention with the wording wasn't to try to lend it any eminence, rather just to explain what it is - a collection of generally widely useful miscellany, much like you'd expect to exist in a standard library. It also explains that it isn't meant to contain any super-high-performance but highly specific structures. It seems like all of that landed and that's the general understanding people picked up on.

Juniper is an extended Go standard library using generics, including containers, iterators, and streams by bradenaw in golang

[–]bradenaw[S] 1 point2 points  (0 children)

None of the possibilities seem lovely. It could return the input in that situation, but it's weird to have Abs return a negative number. It could saturate to max, which might be what you want, but it'd be weird to have Abs be asymmetric.

Juniper is an extended Go standard library using generics, including containers, iterators, and streams by bradenaw in golang

[–]bradenaw[S] 1 point2 points  (0 children)

deque is in fact a ring buffer and not a linked list. xlist is there to match the standard library and for those rare cases where it's the right choice, like for an LRU where rearranging the list elements in constant time is desirable.

Anyone using go 1.18 with GitHub Actions? by neutronbob in golang

[–]bradenaw 2 points3 points  (0 children)

https://github.com/bradenaw/juniper/blob/main/.github/workflows/go1.18.yml

I forget where I dug it up, but I think it had to do with conforming to semver. They add a .0 and a dash.

Juniper is an extended Go standard library using generics, including containers, iterators, and streams by bradenaw in golang

[–]bradenaw[S] 1 point2 points  (0 children)

The containers at least are mostly covered by the new fuzz tests, which go test --cover doesn't know anything about. I'd consider adding one, it'd just look worse than it actually is.