anuraaga

Agree and suspect most didn't read a word of the article (porn has nothing to do with this). If only HN could ever return to actually being Hacker News, rather than yet another sensation platform.

This reminds me when my DB broke down on the way to Zurich just past the border and I had to change trains, though I believe in that case it was a swap from broken DB to not-yet-broken DB. The scenery was great so I didn't mind terribly.

Sorry for the pointless post but got to reminiscing.

Isn't it normal for mortgage payments to be at least to some degree higher than rent if talking averages? Bought property tends to be much larger right? I tried to find normalizing factors like it talking about payment per square foot but didn't seem to find any. I assume WSJ wouldn't push out anything completely off so what am I missing? The difference has grown just much more than it should have?

I believe the point is that this is http/3 support added to the nghttp2 library which has been around for a long time, longer than Rust's mainstream popularity started to build. While I haven't used it personally I have heard good things about the library it's good to see it continue.

Dismissing a new feature in an existing library seems quite excessive and possibly zealous. Or perhaps we should just stop using OSes entirely because they continue to release new features in memory unsafe languages.

It's too bad that there is still no JEP for an official context in Java.

Disclaimer: I wrote the OTel one, and am sad to see yet more context implementations being made, including the OTel one, these really need to all be on the way out.

I have found the single-dev projects to _always_ have a wonderful contributor experience, with company or vendor ones often being quite poor. Really can see the passion when they put in the effort to work together on improving the project.

While there are likely sustainability issues, I guess we will still continue to have these projects and hats off to everyone like Daniel working not just for themselves but also for their community.

I'd say with semver becoming far better known, this is not a problem for "any" software development. The developer gets the choice to pick libraries that are stable, often also influencing language choice. Mistakes happen, Guava broke the Java ecosystem for about two years, but it's never something that is accepted as just a fact of software development, it is a mistake.

Wanting to hold Python+C ecosystem more accountable is fair I think, at least from my own experience around half a year ago, Anaconda doesn't work and you need a Dockerfile for any sort of reproducibility, which can have issues since GPU with docker isn't that easy. And this means developers from the vendors working with Anaconda, for example, on solving the issue rather than just hoping for contributors to do it. If AMD were to make easy, reproducible builds without root or VM a reality, that would be reason enough to try their hardware. If not, hopefully Nvidia does and then there really would be no way across the moat for me at least.

Does anyone know if all the time, it is not possible for the staff to know if you tipped or not when using the terminal? Not for post-pay but pre-pay, e.g. buying a coffee. I would generally be inclined not to tip in these situations but am worried my drink will be contaminated if I don't.

I have a feeling the answer is yes, or don't know, and if there were any regulation enacted the best would be to ensure gratuities before service provided are either banned or guaranteed to be hidden. Gratuities after service provided don't seem to require any restriction.

Disclaimer: I live in a country without tips and love it, would feel better on trips to the US if it were the same.

Happy user of a Xiaomi band which has similar life and likely hardware.

The strategy I found for charging is to habitually plug in when in the shower, the few mins of charge per day provides "forever" battery life for me.

I was using Cloudflare DNS for a while until learning it was the cause of archive brokenness, switched to Google DNS, and recently have started trying out Adguard DNS just out of curiosity of trying out DNS-over-QUIC (requires a VPN app that supports that). Can't say whether it's better or worse but always fun to try out a new tech.

This seems likely a partnership between Google and Hashicorp, from what I understand most GCP integrations like redis are actually partnerships rather than just running the OSS independently. Potential license and trademark implications seems like it would be a particularly bad time to try the latter with Terraform.

As others have mentioned, this is not all that useful of a service - it doesn't seem to even have the concept of a "plan" let alone any approval system and seems to only allow for the most basic of workflows. Given that TF by default will store state in a bucket with true locking, I can't come up with any potential benefit this provides vs using Terraform directly.

The main question is whether this will be improved in the future or is intentionally just "Terraform Trial Edition" with terms of partnership preventing anything encroaching on Terraform Cloud. Perhaps for the former, the trial is important to understand usage to better inform revenue sharing for a future improved product.

It's interesting how even before this has taken hold on HN the repo was already basically dead

https://github.com/google/project-gameface/pull/31#issuecomm...

More interesting is not having the "This is not an official Google project so not supported" disclaimer so many repos in their org has.

Shady origins, shoddy maintenance, but the incident will be forgotten as is usually the case. The reality is Google still has huge mindshare and respect among engineers and will likely be immune to damage in these situations.

This is why I am happy to see RustRover - it's very likely the significantly better product is actually similar for the Go plugin. Once they release an IDE, it seems development picks up and things get a lot better quicker.

I have used clion with rust plugin and while it's better than nothing, it's generally been pretty spotty on all the features, completion, marking errors, refactoring. I'm looking forward to RustRover "pulling a GoLand" by bringing a proper IDE experience to rust.

Will go ahead and start off the config wars as undoubtedly the OP intends.

FWIW my best config experience has been with HOCON via typesafe|lightbend/config in Java. The ability to compose environment specific defaults in a reasonable way just felt good. Of course /internal/config to dump the config was a necessity, but trivial, so I tend to be less sympathetic to DRY is not necessarily good arguments.

Have been missing it in Go, unfortunately Java's ability to publish files within packages (that can be imported in config) was a key part of the UX that is missing in any compiled language I've seen.

Didn't read through the entire thread but anyone that has experienced startups will have seen that the stack is decided by the tech co-founder/ first engineer. This is because they are often still the only engineer. And they will decide on a language they already know - a language that is not popular among startups is a language not popular among engineers that join early stage startups. I could imagine that many enterprise developers using Java or dotnet have relatively comfortable jobs and tend to not relocate.

There is then the point where a startup may need to "step up" to a more large-scale language, for example when Twitter started incorporating Scala. But succeeding enough to reach this point is a small subset of startups, many probably not even called startup anymore, so any language at this stage may not "feel popular" when limiting to startups.

The article only talks about SBF and the supposes that there are others needing the same or more than him. There are no anecdotes or data for this though, usually you would at least expect some of "so and so has been in prison for 5 years and has been..." type of point.

It really doesn't take a journalism major to see this is just a blog and may as well be a sob story for SBF since it does little more than that...

> The interviewer varies a lot though... And makes all the difference when you have an inexperienced one, or someone that doesn't care.

I believe this is likely the main point being made about luck - be unlucky enough to hit up an inexperienced interviewer and all the time spent preparing as in the linked OP is up in smoke.

Not sure if it counts as an average tech company, but in terms of non-FAANG I think startups and smaller companies can end up relying less on luck. There is more time and motivation to truly flesh out candidates, maybe giving non-interview coding tasks and such to balance out interviews. At a FAANG if there was an issue because of an inexperienced interviewer, again you need luck for a recruiter or committee to attempt a save among all the other applicants.

I remember first coming to Japan and playing a round of chess with someone who had mostly never played but was very strong at Shogi. I'm not master or anything but had played a lot and was still generally confident in tactics, and had experience playing with new players, adjusting to keep a good game pace while still winning.

Got obliterated.

Also then started playing Shogi with him for the first time and while it didn't take that long to triumph with an all pawns handicap, after much effort finally reached being able to win including rooks/bishops. But it was obviously basically cheating since eventually you realize how easy it is to win with handicap be just putting 100% into defense.

Anyways, with those games to me it really felt that Shogi is the more strategic game, having similar mechanics to chess but being more dynamic. Chess in the end, even looking at GM matches, looks like much more pattern matching, i.e., tactics.

So my takeaway from that was that as much as I enjoy chess, Shogi is just the more complex game and its experts may just be able to defeat masters if they cared to because of the otherwise similar mechanics, as one of the anecdotes in the article.

Random share this is just personal but honest feeling from past experience and not an endorsement. Really fun memories.

The article mentions Linkedin presumably due to mindshare reasons, but it is Indeed that is far bigger in casual (not tech nerd) hiring. If Twitter enters the market, it seems like Indeed will be completely demolished. Wonder if they have any defense plan (they are not a public company so don't necessarily need one but still...).

This thread is a great example of why not to talk about sex on HN. It can only go down from there.

I am very much wondering this too. I've used Pulumi and like it a lot, it has a great UX in general. But the ecosystem for Terraform is orders of magnitude bigger, e.g. searching for help on Terraform is going to give a lot more results than Pulumi. As someone who can dig into details, this is not a big deal and can use Pulumi on personal projects but cannot in good faith recommend it for team projects only because of the ability to find resources is more important then.

I don't know if the license change actually means providers will not be able to work with Pulumi, but if it does, it seems risky to use Pulumi even for personal projects if newer provider versions (i.e., versions that work with newer products released by the cloud provider) will not work with Pulumi, it's a dead end. And that's not to mention the useful providers that aren't cloud and completely community developed that will not have the resources to maintain two codebases in any case (I'm thinking of Sendgrid).

I looked at terraform-sdk license - it still seems to be MPL. I think this means that all providers can continue to be open and work with both platforms, it will be important for Pulumi to clarify this to prevent the death spiral. Given some negative feedback towards the Hashicorp blog post from Pulumi employees on this thread, I am somewhat skeptical of this since if everything is fine, then complaining will otherwise have a negative effect, that us users have to assume that Hashicorp is actually stomping them out. And if it's the case, sorry but in good faith to everyone else that may need to work on infrastructure I make, I will have to be complicit in the stomping.

I live in Japan but was thinking of taking a Greyhound for a 2-hour or so ride during a US trip but a friend strongly advised against, the presumably exaggerated analogy was getting herpes just riding it. Another friend more familiar than me with the recent US generally concurred.

So I assume that's one reason to take an Uber? I was going to look into a charter anyways based on that advice.

Amtrak I'm more familiar with but at least in California it's just incredibly slow.

I've seen a lot about porkbun lately and they somehow seem to be the de facto option among HN folks.

Currently I am thinking of focusing on AWS route 53 domains under the assumption that there is always a non-zero chance of needing something else on AWS so it reduces the number of accounts/IAM (either 1 or 0 versus guaranteed 1). Anyone have their favorite reasons to go with porkbun instead?

Great post! I respect people's decisions regarding the focus on privacy but above all I just need the internet to work and this was always a mysterious issue. Finally fixed by switching to Google DNS, which for me personally is not a problem, escaping their net is better than not but not a requirement.

Yup - quit Facebook some years back with no regrets, even despite this, but the reality is that it means missing out on high school reunions, something I will never experience in my life because FB controls it.

Is it actually proven or does it just sound nice when stated that way? Perhaps it is, but my counter proof would be taking no measures to protect privacy, very likely being fully tracked by government, and not having any negative consequence. Privacy doesn't seem like a "need" in practice, especially when many vulnerable people will just continue to be bothered by police on public streets, forever.

I suspect they did eventually enable it by default to match expectations. I generally see a rate of actually showing compilation errors of around 70%? Perhaps higher, it's not the 100% of other languages like Java/Go, and anecdotally I feel a higher rate with JS.

I got excited that this is a new, official IDE for Rust from Jetbrains but it's just a repost of the usual plugin. I LOVE their IDEs for Java, Go, Python, JS, and even objective c though that one recently died. The rust plugin still for the most part does not autocomplete well and often misses compilation errors.

I've generally seen the release of a branded IDE for a language from Jetbrains to be when they have great support for it, hopefully it'll come for Rust but it's taking a long time, which unfortunately for a Jetbrains user to death at this point, means not using Rust itself.

> In fairness to Microsoft, a working solution is elusive because many vulnerable drivers continue to be used legitimately by large numbers of paying customers. A revocation of such drivers could cause crucial software worldwide to suddenly stop working.

Maybe, but if a system running today has no drivers installed signed by old certs, transparently blocking them, as well as defaulting to block, with an IT admin ability to unblock, for new installs seems quite easy.

Huh?