whatever_dude

I haven't looked at the code but it's likely some out-of-the-box physics engine, many of them available in JS. They often have to employ many more complex physics features. Buoyancy is just one of them. Computationally I'm sure it's complex, but it's made to run at game tickrates, less than the max budget of 16ms at a time.

I had a similar thing happen to me, not here but on Reddit. Was shadowbanned for no reason (never learned what it was) on an account where i treated everybody with respect. I created a new account, but from that day on i started behaving like shit on the website. I knew accounts were worth nothing if they could get randomly shadowbanned so I started acting like so.

I actually think a lot of the things that were very difficult are much better now.

For browser incompatibilities we used to have to hand write CSS. We now can use normalizers and autoprefixer on build, including reading from a browserslist file, so it only includes what's necessary. Same thing for JS; instead of including a dozen hand written polyfills, babel-preset-env will only include what I actually need for the same browser target list.

People complain that now we need a while bundler, and that's correct, but it's a needed step. In reality, the easy things might have got a bit more complicated because you need an organized build instead of just a simple HTML, but the difficult things got way easier. And I'm ok with that.

Tangent, but BeyondCompare is one of the few tools I'm proud to have purchased. I use it all the time for file and folder diff. It has been invaluable for me and my work on both Windows and macOS.

This. Making DST permanent is like buying an amplifier that goes from 2 to 11 instead of 1 to 10.

> Is it right to expect an Engineer to do the managers' work too?

Who said anything about a manager's work? There's lots of things that can be called "boring" but are still expectations that fall on an engineer, not on a manager.

I didn't get that impression at all.

I'm purely an engineer who 100% prefers being hands on; now that I accidentally have to manage teams, I fully appreciate the article's perspective. I've been on both sides of that argument as well.

It's not about a manager expecting an underling to get his paperwork done. I think that is an unfair assessment of the argument being made. It's that there's more involved to the job of engineering than simply pushing code one thinks is clever.

Sometimes that means knowing which problem to focus (not just the fun ones), sometimes that means dealing with other responsibilities like mentoring or interviewing or filling up timesheets or getting to work on time or attending meetings or what have you. None of those are unreasonable requests (as much as we hate them). If it's part of the job description, it's part of the job, and, for example, making a piece of code conform to one's own subjective preferences so they can feel clever doesn't make up for missing a deadline on a separate, boring, high priority task.

I've frequently seen engineers who think otherwise. Who think their work is so brilliant, they don't need to care about the boring stuff. Some of them have indeed been brilliant. But guess what; they still need to get their shit together, because their brilliance is still objectively not making up for being unreliable.

Same. Playing on PC. Few bugs. I didn't buy into the hype (ignored the game's marketing) and am enjoying it very much as a result.

In the past I've been bitten by my own unrealistic expectations of certain games prior to release. I'm sure there's a little bit of that at play here, both the developers and gamers/new media's fault.

My own favorite is an equation parser.

Before attempting to do so I thought it was implemented as a simple seek over the string, maybe a bunch of regex stuff. I guess it can be done that way, at the cost of growing complexity; but the proper solution (with a stack, etc) is so elegant (makeing it easy to add functions, operators, parenthesis, variables, etc) that it really makes one appreciate the value of good, thoughtful engineering.

This makes sense. I've been playing the game on PC (thankfully very few bugs compared to everybody else it seems) and loving it. The difference? I avoided reading or watching anything about the game prior to release. So on fresh eyes, I just think it's a good, fun game that has the average number of bugs.

I've seen this phenomenon elsewhere. To some circles, everything that is not a huge, public, IPO'd tech company is considered a "startup".

Wrapping a piece of proprietary technology with other piece of proprietary technology is not the way to go with this. I get that you keep saying it's easier than creating a new player from scratch, but it doesn't mean it's better.

You managed to put into words something I always felt about PG. Thanks.

Please support Ruffle. It's a true open source project borne out of the will to preserve a forgotten creative Internet. As opposed to previous and recent license-encumbered or commercial products.

The two goals are greatly symbolic of Maradona. There's the genius and there's the deeply flawed human.

Whoever is making that claim should bring the evidence, not the other way around.

(there's none, it's a fabrication)

Twitter is a hellfire, but it still has value if well controlled. I use a third-party client and added dozens of muted word (eg anything political or covid related) and it's amazing; it's a bit of a escape even. Once I realized I don't have any obligation to mind the Latest Piece of Shitty News 24/7, I'm a much better online social media user.

I still read the news every day (Feedly) and know what's going on, but it's compartmentalized.

Sketch trying to make up for their (now) mediocre application by trying to turn one of their cons - heavy platform lock in - into an advantage. Clever.

She's right. It even has a name, "jeitinho": https://en.m.wikipedia.org/wiki/Jeitinho

Only that Apple's track record for supporting anything long term, cross platform, "open", is non-existent.

At this point I don't even care about how good their language is. Apple has a very, very long way to go before I can trust them on anything of that magnitude. I would instead assume they WILL pull the rug from under developers for any random reason.

(And I say this as an iOS developer)

The point here is using types that are still fast and memory efficient without having to resort to brittle pointer magic full of gotchas. You still have raw buffers, and they're still efficient, but you just don't have to do malloc or memcpy all over the place to make them work the way you want.

The way I see it, much of Rust, and this project specifically, is not about moving to a higher abstraction... It's about moving to the right abstraction.

Yes, I could have switched to just about anything else, and end up with an even higher level code. But that would defeat the purpose of keeping it small, fast, and memory conscious.

Long but great article. Echoes my own track record with Rust.

I've been rewriting a project in Rust. The original is a 20+ years C project (not created by me). Rewriting it in Rust has been a delight. So many surprises, discoveries, learnings.

I've first converted the codebase using C2Rust (surprisingly efficient). The code compiles and runs correctly. While Rust has been nagging me nonstop when I try to do things the original C way, and I still have a lot of weird flags on the code, once I rewrite some piece of code in idiomatic Rust, I end up with a much better design than before. Gone are weird linked lists, crazy custom hashmaps, strings regurgitated in memory, "buffers" holding any manner of data anywhere in memory. Instead, the new code is more efficient, more understandable, and of course safer - even if more restrictive!

I've found at least two major hidden bugs on the original codebase doing so too.

Rust certainly has a learning curve. It's not C/C++ nor Java/C#/JavaScript. But I'm more and more convinced it's the right way to do things in what's currently the C/C++ space.

Exactly same. I try different fonts from time to time but always end up going back to Consolas.

I agree with the sentiment but

> Their core sync engine is truly amazing

Compared to current competitors (e.g. pCloud) their syncing has been a mess. It tends to take forever to sync even the smallest files. I have no idea what's going on there anymore.

Can't shake the feeling this is another "me too" product by Dropbox while the main product (hosting files) gets jankier and jankier.

Zoom has a browser version as a fallback.

Most people use the standalone app because indeed it "just works". That's why you don't hear much about its browser client.

I believe you missed half the article, as well as the main point: that trying to hide implementation details too much from the API consumers is not generally a good thing, and that's regardless of the system it's running on.

The OS is just one of many context-dependent axis on an application. Bad decisions done on that level are likely to occur on other parameters that are more important to you.

This.

I like, and agree, with the conclusion, and wish more people would get to it:

> Over and over, Go is a victim of its own mantra - “simplicity”. (...)

> It constantly lies about how complicated real-world systems are, and optimize for the 90% case, ignoring correctness.

> This fake “simplicity” runs deep in the Go ecosystem.

I've always liked simplicity and on my own design, I tend to go for abstraction; trying to make it easier for consumers of my API. But nowadays more often than not I find myself preferring to be explicit about the underlying idiosyncrasies when needed. This is partly due to my recent experiences with Rust, and this post seems to concur:

> Rust has the opposite problem - things look scary at first, but it's for a good reason. The problems tackled have inherent complexity, and it takes some effort to model them appropriately.

In that sense, I especially like the approach to `Permissions`/`PermissionsExt` that Rust takes. It makes it clear what the tradeoffs are, and allows consumers to implement their own high-level, abstracted API without compromises.

I've admired PG and his essays for a while, but I've started paying more attention, and thus I'm starting to realize he's somewhat thin skinned like that; this is exactly the feeling I got after reading this new one.

Similarly, he's been passive aggressively "responding" to VC criticism by subtweeting and deflecting, and never directly addressing, some of the points raised by @DHH and others.

I take everything he writes with a grain of salt now. As a result, I started to realize his essays tend to be can defensive or just contain a lot of bias, rather than being truly introspective.

My new pet theory is that software nowadays is _anti_ power user.

In the 90s and 2000s, software came with a bunch of features that most users would want, and also a few small but powerful features that a tiny portion of their users ("power" users) really cared about. Almost every software had "power" features of some kind. A config file, command line arguments, that kind of stuff.

Nowadays, popular software like Chrome are all too eager to drop "power" features; to make themselves simpler. This avoids confusing general users, at the cost of alienating "power" users.

Dropping Ctrl+tab (heck, making shortcuts support a low priority) is one of such features.