sagichmal

12 ms·

61.
by sagichmal 5y ago
It would be a little bit strange to build a CRDT system on top of a more traditional data system. CRDTs solve problems at the network layer at enormous cost basically everything else. If you're not using them there, I can't quite
62.
by sagichmal 5y ago
Oh, sorry; I thought you were talking about Slack threads. I can't speak to Discord threads.
63.
by sagichmal 5y ago
> If I want to contribute to a prior discussion that happened a few minutes ago but another one is taking place now, then we have two separate conversations in the same linear chat stream. Yes, this is the essential nature of real-time c
64.
by sagichmal 5y ago
They emphatically are not.
65.
by sagichmal 5y ago
Tell me how to (a) identify an interesting thread, (b) view its contents, (c) contribute to it, and (d) return to it after closing the app, without using the mouse.
66.
by sagichmal 5y ago
> Use `reflect.Value.Select` Never really a good idea, and never necessary. > create a single channel owned by the reader Channels cannot be effectively owned by their reader(s), the contortions you have to bend the code into to make
67.
by sagichmal 5y ago
> I still run into deadlocks and panics (writing to a closed channel) when I try to use channels beyond the simplest use cases. Wild! The rule is that channels are owned by a single goroutine, who's uniquely responsible for sending
68.
by sagichmal 5y ago
> A channel can be buffered or unbuffered Yes, with predictable results. > it can be closed Yes, by the owner/sender, who then understands it as invalid. The effect of receiving on a closed channel is well-defined and predictable
69.
by sagichmal 5y ago
> GMM violation = UB This is definitionally correct (shrug) > Dilettante programmers certainly do not know [that] Go slices, strings, and interface values are unsafely non-atomic. Yes. They do. As soon as a Go programmer learns that t
70.
by sagichmal 5y ago
> They never say or imply something like "if you have a data race, anything can happen [including executing code on the stack]" They absolutely do. https://software.intel.com/content/www/us/en&#x2
71.
by sagichmal 5y ago
> I have no idea what point you are making. _Of course_ there has to be a bug in the code for there to be a buffer overflow vuln. Or are you objecting that they put contrived code to make the race work better (this is the concept of a Po
72.
by sagichmal 5y ago
Er, your summary does not at all describe what is going on there. Like, all of that code violates the memory model, so whatever it accomplishes is irrelevant.
73.
by sagichmal 5y ago
> Go has lots of weird edge cases, like sharing a slice across threads can lead to memory corruption (in the C / assembly sense, not merely within that array) Source?
74.
by sagichmal 5y ago
this_definitely_happened.txt
75.
by sagichmal 5y ago
I know, right ;)
76.
by sagichmal 5y ago
That’s fun! Yeah, I buy it, but to the extent it works as a counterargument I’d say it’s actually more of an inevitability.
77.
by sagichmal 5y ago
I love my job and I love my life and I deliberately blend them together. This makes me substantially more productive as an employee, and incalculably happier as a human being. If I want to see a friend in the middle of the day, I do it. If
78.
by sagichmal 5y ago
> Note that the lightning emoji indicates a blazing fast speed. And the snail emoji indicates slow speed. This article was embarrassing, and makes Redis Labs look childish and inept. Whatever process resulted in this blog post should be
79.
by sagichmal 5y ago
Nobody believes this; your comment is embarrassing.
80.
by sagichmal 5y ago
Depending on workload, Go also does sub-1ms p99 pretty easily. I'm getting sub-1ms p99.9.
81.
by sagichmal 5y ago
I'm pretty confident that the end result would be simpler in an architectural sense (i.e. fewer components), it would be easier to understand and maintain, and it would behave both more predictably and more reliably. But these are subj
82.
by sagichmal 5y ago
> The language authors did not work on large systems. Um. Alright.
83.
by sagichmal 5y ago
Oh, sorry, I misunderstood your meaning when you wrote "That pretty much works now?" — I thought it was a question as to whether a more traditional Prom architecture could do it, but I see now you're just saying you already h
84.
by sagichmal 5y ago
> That pretty much works now? Well, with the requisite glue code that would inform each user's Prometheus instance how to scrape the service instances -- yes, more or less. > is not at all clear to me how doing a purer version of
85.
by sagichmal 5y ago
> They're working around a weakness in the language. Stack traces in exceptions are definitely a feature. OK, I understand this is your position. I don't share it, nor do the authors of the language. So I guess it's not a
86.
by sagichmal 5y ago
> Most languages that I know of have mature DI solutions, and those are needed for writing any non-trivial app. Patently false. > Also, one of said frameworks I was referring to generates mocks for your app and wraps errors so you au
87.
by sagichmal 5y ago
> I think you're reading a critique of Prometheus that isn't really present in what we're writing. I'm observing that you've used pull-based, horizontally-scaled tools to build a push-based, vertically-scaled tel
88.
by sagichmal 5y ago
> Take a look at the major DI frameworks for Go, Wire [0] and FX [1] I'm well aware of them. (There are several more, too, which see at least as much use as these two, unfortunately.) They also reflect a misunderstanding of the lang
89.
by sagichmal 5y ago
> Our physical hosts have hundreds of services exporting metrics. And many of those exported metrics are from untrusted sources. So we can both rewrite labels and decrease the scrape endpoint discoverability problem by aggregating them i
90.
by sagichmal 5y ago
> I worked at an employer who heavily used golang ... they ended up reinventing the wheel on so many different things, including DI and an entire application framework. Sounds like they were trying to force the language to be something i

More ›