ablob

The post you replied to literally doesn't care about upgrades. More enforcement also doesn't matter if its what you need to get specifically _what was asked for_, which is a thinner device in this case. I also wouldn't like an X60 if it meant I have to leave things out of my bag.

It's closed to the public at the moment, so I don't think you will be able to find much.

AFAIK, the language is and was used in JB's projects. JB is just very picky about when he wants people to see things. He doesn't want outside voices influencing him and he still has some things he wants to think through. Doing that mostly solo takes time - it's not like the PL is the only thing he has been doing

If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.

I would like you to elaborate on how still being in closed beta is an argument against the thesis. To me it just looks like avoiding feature-requests, nitpicks and community interactions for a product he doesn't even want to sell.

I don't really see the semantic difference between your code snippet and

  if (double.TryParse("5.x5", out double val)) { ...

which would be the C# equivalent

the set theoretic type system variant has one issue I think the algebraic one avoids: An overlap between types is ambiguous, i.e. "int | int" doesn't make any sense to write. In a function parse_postal_code, where you either get the postal code, or an error code you wouldn't be able to differentiate. You could write your own types for that, but now you've essentially recreated what the algebraic versions do by forcing a selection through the type constructor on the inner type instead of the wrapping union type.

That being said, in cases where there is no overlap I don't see why "the old way" shouldn't behave like typescript through implicit conversion as there is only one applicable constructor. Forcing explicit selection if there is overlap, but do it automatically when there is none seems like reasonable behavior that is a strict superset of what you wrote before.

At least the fallout will be less if you have to resolve your custom domain differently in the intranet due to something like this.

If github is "taken down" you can't just resolve the whole domain differently, you need to only resolve the packages differently. If your "Golang domain" is taken down, it should be a lot easier to hotfix until something proper is implemented (the quickest and dirtiest would be a hostfile-entry).

I assume that the result of the rename operation must be known. I.e. if it was successful or not, or which files were affected. That implies 2 function calls. One to start the operation, and one to query its result. That is, by definition, already an asynchronous interface. The only other (i.e. synchonous) way to achieve remote procedure calls is by blocking until it's finished.

I don't know about you, but I do not want to block on every keystroke. Program analysis can take time, asynchronous feedback is a natural fit. None of the features I use from LSP should be synchronous.

I can almost guarantee you that a synchronous API would yield a much more complicated design just because many operations can not be expected to reliably work within a few milliseconds.

You want to rename something across multiple files? Well now you add file system overhead and blow straight past reliable frame timings. Good luck waiting for that operation to finish. Of course you could make the API beginRename, and queryRename, or whatever you fancy to see if the operation was successful, but now you're back to what you wanted to avoid: an asynchronous API. Do mind that the example is actually one of the better cases, as many things you might want to do with a codebase are actually more expensive. You will feel the hiccups from waiting in the UI thread and you will loathe the program for it.

As far as I know you might want to read the GLSL or Vulkan specification. At least there (and by extension in SPIR-V) you can select different floating point behaviors.

Historically graphics programming has been more concerned with looking good rather than being accurate, and behavior is likely different on each GPU. It's a "hop into the water and learn to swim" kind of thing as far as I'm concerned. You will find errors for things you'll never have thought about and there is hardly any way to brace for it except trying on the go.

You don't need a build system to share code.

You can share with header files and respective (shared) object files regardless of the build system you're using. Likewise you could just share the source. None of this needs a build system.

I think the crowd will split into those who just cared about it being rust and those who wanted some kind of leverage to tempt others into doing something. The former crowd will cease being, while the latter looks for something new to push.

I believe that one does not need to be overly concerned here. As with most things you will never satisfy zealots so it is sufficient to reconsider every once in a while when the status quo changed enough to warrant the effort (i.e. the actual arguments change).

It is always a choice to participate in these "culture wars" or whatever you want to call this. If you can stick to a decision you can limit the impact quite a bit, I've come to realize.

A red herring is a bait planted specifically to derail a conversation. I will make an example to demonstrate this in a setting which is less loaded. Beware that all analogies are flawed in essence, so a direct transfer to our conversation will be difficult, especially since I am trying to be blatant. But since I want to answer your question of where the red herring lies I feel like that is the easiest way:

A (raising an issue): This hole in the wall sucks, I can't stand it. At least if we were in a tent we could sew it shut.

B (planter of herrings): So you'd rather live in a tent than in a house? Don't you know that tents are generally worse than houses?

C (the innocent bystander lead astray): I also much prefer houses. You hear so many bad things about them, but in the end nothing is better. No caves, no huts, and certainly no tents. I'd pick a house any day of the week.

Did you notice that we are no longer talking about the hole in the wall? The hole could be required for mold-prevention, it could just be an oversight that is actually fixable, it might be a trade-off. But since we are no longer talking about the hole we will never know.

> ... but ”With a dictator you have full responsibility concentrated in a single person” is simply not true. Dictorships are master minds of shifting blame.

This is you talking about the hole in the wall. I am also not convinced by the original argument, but I do believe that there is some substance to be explored.

> ... I’m obviously biased as a European but I’d pick the eu any day.

This is you falling for the red herring. We don't know if the original poster lives in the EU. We don't know if they prefer it to a dictatorship, but it also does not matter. The original qualms are that there is seemingly no single point you can go to to stop the endeavor once and for all, which in this context is encryption backdoors within the EU. We could be talking about how the same mechanics that make this so frustrating are useful elsewhere; find out or explain why the things are the way they are. We could be uncovering a valid flaw in the system just waiting to be fixed; conclude that things don't have to be this way. Instead, we ask ourselves if we like living in the EU better than in other places. We've lost the plot, so to speak: There is no more insight to be had.

This is what makes a red herring so obnoxious to deal with. It is an easy trap to lay if you don't want to think about something or hinder someone, but takes so much effort to recover from. In the tent-example it is easy to see that we completely derailed and stopped talking about what matters. Unfortunately, reality is much more subtle and not everyone has the same goals in mind. At least on HN I'd like to try and keep discovery in focus and once we reach the stage where it's only about opinions there is nothing more to discover.

They are saying that in bureaucratic countries there is not a single entity that can be held accountable, which means that "bad" decisions, are not easily undone. Likewise it means that "good" decisions are hard to change. It is a statement about the momentum of change, not about it's worth or intention.

There is no further comparison made between these governmental forms and how they affect their subjects.

Why would you create such a blatant red herring?

I don't find it particularly surprising that a company tries to influence legislation influencing their business.

What the headline is missing is that, according to the article, Meta is paying influencers to advertise for existing parental controls. If the issue is not that there are no controls, but that parents don't use them because they don't know about it, then I see hardly any evidence to support such a pretentious title.

Parents are supposed to care about what their kids do. The government can only mildly reduce this burden. To be honest, I think that there might not be enough information on how to effectively parent on the internet and this seems like a low hanging fruit to try. In the end a ban might be the best option, but exhausting other options first seems worth a shot.

One of the main arguments pro-Meta is that they at least try, even though a strong argument can be made that they don't try hard enough. I find it difficult to believe that preventing children from interacting online via social networks is achievable. As long as adults demonstrate the availability of these things kids might want to imitate/have the same interactions. I'm glad I don't have any stakes in this topic at the moment - foreseeing evasive behavior from either side is going to be a nightmare.

Surely the King is doing it, so that must be the correct way. Look, the King even wears clothes and is totally not naked at all.

That the world runs on Kubernetes is no qualitative statement about the correctness of its Raft implementation. You can say that it's clearly good enough to not matter most of the time, but that is a different statement. No matter who you look at, they're just cooking with gas like you do, and they can make mistakes in just the same way.

Now; I'm only attacking your argument. I do neither know nor particularly care about the correctness of that implementation itself. There's been better refutations of the claim you replied to in other answers anyway.