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.

If you can predict other things by understanding something, is it truly lossy compression?

So we are reduced to code monkeys mindlessly re-typing what an LLM wrote to increase potential understanding...

Whatever this approaches, it is not a state of software engineering I find desirable.

I think that's a stretch. People can care, but be unwilling to spend the time researching it or accept the trade offs that come with small browsers (which are often unsupported for applications you might want to use). There are many things someone might care about and at some point you have to prioritize. This topic in particular is practically a cold war where you always have to catch up on how things are, lest you loose it all. The required effort is disproportionate to the result.

P.S.: No true Scotsman spotted

It's a nag-box that appears every time someone visits a new website. Of course people are going to click it away as fast as possible. In the few cases you repeatedly visit a website one might want to reconsider, but by then it's out of mind due to not being shown after giving consent.

It is known that warnings and pop-ups that show up almost all the time yield diminishing returns. I think it was named "normalization of deviation" by some folks in a blog a while ago, and I believe that name fits. If you get warned about missing https all the time, or that something might be dangerous (even though it does precisely what you want it to do), it will loose its effect by the time you actually need it.

You can argue this is malicious compliance, but if you want it to go away it would probably be easier to go for banning tracking and personalized ads altogether. Eliminate the reason for this behavior, so to speak.

You can always set the editor in your --global or --local config though:

  git config core.editor "vim"

I do agree that using the default editor is a mostly a bad choice due to it being vi/vim rather often.

I think the only missing thing for me would be to group commits, essentially squashing them for a clean history while allowing to unsquash them in case you need it.

I don't understand your question. The person you replied to never said anything about a boycott. They said that diversification is kind of necessary, so to use both Russian and American services, as both sides do censor/block different things.

Given the recent chat control disaster I'd say our say is rather slim when it matters. Just put a decision into urgency mode (even though technically that's only allowed for the first hearing) and let it be a default pass unless two thirds reject the proposition. If it hits the courtrooms, rewrite it a little bit and effectively keep the status quo.

I might be misinformed, but I believe that American citizens have a way of forcing specific regulation instead of only forcing it to be considered. That would be something we don't have in the EU. So in the end it might just even out in that regard.

I'd like to add an anecdote about machining. Some designers impose incredibly tight tolerances on part shapes that hardly change the overall behavior of the final machine, but are so difficult to produce that sometimes special tools have to be bought and instead of being able to produce 4 parts an hour it might just be one instead.

Maybe this sentiment stems from being software engineers, but at least for hardware it becomes abundantly clear that "good enough" is a desirable state unless you want to spend years in development. The only direct comparison I can find in software is computer graphics, where the endeavor often halts as soon as the average person can't perceive a difference anymore.

You have to deal with this no matter what unless you can live with wasting storage space. You have to arrange extra sales or try and donate stuff (basically, go through all possible options that exclude it from being exempted) if you want to get rid of an item. Your estimates on sales count need to be pretty spot on to keep that low. Donations are still taxable where I live, by the way, so all that shenanigans is added too. It's not just about the report itself. You can't get rid of products not valuable enough to keep around without adapting your whole business model. Even if you are _not_ looking for an exemption, you will have to accommodate.

No one bothered to make any of the other options easier, only the previously simplest option was barred behind trying everything else. This is what over-bureaucratization looks like.

To use a different example: No one wants to switch to public transport (which is already crowded anyway)? No problem, just ban driving unless you can prove that it's orders of magnitude faster and it's not feasible to move your residence. No further preparation is done; no thought goes beyond the horizon. "Eat this rule and deal with it, you don't have to deal with the paperwork if you're willing to spend 2 hours more on commuting". That's the line of thought here. There are no plans to make it actually viable to use the train, the other options are just barred behind this veil of plausible optionality. You can do it, of course. The issue arises from doing this with literally anything you tackle.

You essentially only add rules and special cases without ever consolidating them or even considering possible impact on adjacent topics. Everything grinds to a halt by doing this and nothing ever gets simplified. It is a huge issue on a landscape that favored small businesses (that can't afford divisions dealing with this) when the way the law is written suddenly requires structures only big companies or consultancies can provide. It entombs the market structure and drowns any competition in regulatory capture. We haven't even seen what happens once the markets are dominated by oligopolies and monopolies. By that time the only way to deal with the fall out will be even more rules, as the competitive landscape will already be dead.

I'm not against the goal of this regulation, but the recent way the rules have been made favor a market structure I consider incompatible with the goals of the EU.

funny enough,

  2>&1 >/dev/null cat file

appears to yield the same output. So i wonder where the not "order-independent" chimes in.

Don't phones have identifiers outside of phone number anyway? I feel like you have to trust the hardware/os vendor anyway. So if you don't trust apple to not misbehave, maybe not getting an iphone is better than chasing the whole phone-number idea.

I feel like your example is flawed, I just can't put my finger on it.

Maybe it's because I don't see how sleep regularity is a factor you can change as willingly as visits to the fridge, or maybe its because I don't see why people wouldn't just eat more before heading to bed.

It could also just be that I find a treatment of symptoms to be less desirable than causes.

Sigh, I don't know why a blog-post against micro benchmarks should alter my opinion on this topic. There are more metrics than just "speed" regarding an interface. You also want it to be discoverable and visually distinct.

How someone interacts with your software is absolutely measurable and the results will vary by how a user is likely to use it in frequency and variety of function. Someone that needs to do something specific with your software every day will interact with it quite differently than someone that just hops onto it every now and then to do a different task each time.

All of this requires actual studies and observation of users over time. Micro benchmarks have no space there. Testing how fast a find and replace is is meaningless. In case of software for writing text you'd test a user actually writing prose, changing font sizes, title colors, and maybe replace a word over the file too. You would have commonly used functions mixed in with less commonly used functions over how the software is used under a specific use case. (For example, writing text, revising text, and polishing a graph representation are different use cases)

This is not easy, which probably why it's not done all too often, but it is also most definitely unlike a micro benchmark (which your link argues against).

All that being said, I don't know of any person strictly pitting mouse against keyboard when testing UI for possible improvements.

Most knowledge about human computer interfaces was obtained through metrics. Groupings, menu bars, corner buttons, context menu orderings, and other things didn't just spawn into existence. There was a time where human pattern recognition and physiology was an active consideration for user interfaces. One of the reasons mouse input became popular is precisely because interfaces were created to be easy to use with it.

All of this brings me to my questions: Why do you reject measuring how good an interface is? Or given your dismay over keyboard based workflows, why do you think they would win most of the time?

I'd wager that if actually tested, in only a few scenarios the keyboard would win, while hybrids (with both mouse and keyboard input) perform best for most people.