slver

16 ms·

151.
by slver 5y ago
They will respect this flag for liability purposes. It's the only purpose this flag has.
152.
by slver 5y ago
So, if I bought a bunch of licenses under the promise of eternal updates, how should I feel and what should I do now.
153.
by slver 5y ago
Basically we need hardware that works a lot more closely with the OS, and an OS that works a lot more closely with modern language semantics. The problem with the general abstractions you call out (correctly) as inefficient, is that they&#x
154.
by slver 5y ago
I don’t care what happens to this site.
155.
by slver 5y ago
IRC is not developer minded
156.
by slver 5y ago
Eventually all languages will go this way but for some reason some are stuck on the wrong abstraction.
157.
by slver 5y ago
There are exceptions and probably in a parallel universe IRC is all the rage with very few changes. I think the issue is that HTTP and the web platform are so flexible, that we've stopped evolving dedicated protocols and just slap ever
158.
by slver 5y ago
I have no idea how these quotes apply to what I said.
159.
by slver 5y ago
I keep hearing this term "requires a runtime" when async execution is thrown around. And on first glance it makes sense. On deeper look, technically all languages have SOME runtime behavior. And I don't know why we're so
160.
by slver 5y ago
Great. But let's roll back to my initial point that the drama around Freenode is disproportionate to its relevancy. The fact you don't like too relevant things kind of isn't a counterargument.
161.
by slver 5y ago
I like the concept behind IRC as a protocol with a set of independent networks, clients. You see, I'm not arguing what we have today is better. In many ways, it's worse, and I'm sick of proprietary HTML-based interfaces and t
162.
by slver 5y ago
> You are pretty young, right? No. > IRC is still the only group chat technology that I use semi-regularily. Slack, Discord, Matrix, FooBar, and the next yet unnamed hype can very well stay where they are. I dont care. I don't un
163.
by slver 5y ago
The current drama around Freenode is completely disproportionate to what its importance in 2021 is. Sure, IRC was huge back in the day. Today it isn't.
164.
by slver 5y ago
You assume the author has access to lossless sources, or has the funding and means to produce the recordings themselves. I don't have this impression. You work with what you have.
165.
by slver 5y ago
On the other hand it’s not as if bird songs are encoded binary information. They’re complex to our ears, but probably hold up pretty well under common audio compression algorithms.
166.
by slver 5y ago
Kids just love entering the mouth of a giant angry face I bet. Some ideas are intended to die.
167.
by slver 5y ago
> What you are describing is really “async-never.” And in fact, the programming model that async/await gives you is in fact, blocking. To the programmer, awaiting is no different from blocking a function. Not exactly, I rather propo
168.
by slver 5y ago
Yes “async foo()” call would be gathering promises without waiting.
169.
by slver 5y ago
It's fine, we reinvent it every day from first principles.
170.
by slver 5y ago
Performance-oriented languages tend to have a strong type system which lets them know well ahead of time what function is being called, so I see no reason why what you describe can't be done there without performance overhead.
171.
by slver 5y ago
Async will continue to look awkward until we drop explicit "await" on function calls. Awaiting should be the default. If I call "async foo()" then I get back a promise I can explicitly await, but there should be no seman
172.
by slver 5y ago
You legit called 1000s of people in the industry to ask them what they think about the 100 lines meme. Great, appreciate your effort there. /s
173.
by slver 5y ago
You see, if they had the rights, we'd know who it is. You reserve your rights through registration. If we don't know, then there's no way to prove you have the rights.
174.
by slver 5y ago
> As in: how many libraries of Alexandria do we lose each day on the web? Because it it's too high a number, then the web is fundamentally broken. If your brain remembered every piece of information it stumbled upon, you'd ceas
175.
by slver 5y ago
The question wasn't "how to magically scale everything". The question was why not eliminate the difference between in-process async call and a service, and that's basically what Erlang and actors do.
176.
by slver 5y ago
Comparing the Library of Alexandria with random web sites is unwarranted. Libraries are curated. And websites who can't afford hosting, and there's hosting for $5 these days, BTW, self-curate themselves out of existence.
177.
by slver 5y ago
In your situation it seems like a non-technical person in charge of technical decisions. Those decisions are by definition poor quality. But the really bad moment is when the developers themselves make those bad choices entirely on their ow
178.
by slver 5y ago
> But wouldn't it be cool if there were a framework where the developer didn't have to demarcate where services started and ended? Erlang/Elixir, for JVM Akka, for .NET Akka.NET.
179.
by slver 5y ago
Disaster #1 is too small services, and Disaster #4 is huge, shared databases (between many services). Which reaffirms my overall opinion that most people writing services have no idea what's a service and what it encapsulates (it encap
180.
by slver 5y ago
Really. All right, I'm looking forward to the author of dickbutt stepping up and claiming what's theirs.

More ›