It is a lot more complex than moment, but only because there's a lot of inherent complexity to dates and times that moment just doesn't deal with. So you need to be explicit about whether you're dealing with dates, times, or datetime objects, whether or not the object you're working with has a timezone, etc. Where moment is generally designed to have a convenient API, Temporal is designed to have a correct API.
In theory yes, but in practice I don't think you could build something like Servo very easily like that. Servo is a browser, but it's also purposefully designed to be a browser-developer's toolkit. It is very modular, and lots of pieces (like the aforementioned CSS selector library) are broken out into separate packages that anyone can then use in other projects. And Servo isn't alone in this.
However, when you install Servo, you just install a single artefact. You don't need to juggle different versions of these different packages to make sure they're all compatible with each other, because the Servo team have already done that and compiled the result as a single static binary.
This creates a lot of flexibility. If the Servo maintainers think they need to make a breaking change somewhere, they can just do that without breaking things for other people. They depend internally on the newer version, but other projects can still continue using the older version, and end-users and distros don't need to worry about how best to package the two incompatible versions and how to make sure that the right ones are installed, because it's all statically built.
And it's like this all the way down. The regex crate is a fairly standard package in the ecosystem for working with regexes, and most people will just depend on it directly if they need that functionality. But again, it's not just a regex library, but a toolkit made up of the parts needed to build a regex library, and if you only need some of those parts (maybe fast substring matching, or a regex parser without the implementation), then those are available. They're all maintained by the same person, but split up in a way that makes the package very flexible for others to take exactly what they need.
In theory, all this is possible with traditional distro packages, but in practice, you almost never actually see this level of modularity because of all the complexity it brings. With Rust, an application can easily lock its dependencies, and only upgrade on its own time when needed (or when security updates are needed). But with the traditional model, the developers of an application can't really rely on the exact versions of dependencies being installed - instead, they need to trust that the distro maintainers have put together compatible versions of everything, and that the result works. And when something goes wrong, the developers also need to figure out which versions exactly were involved, and whether the problem exists only with a certain combination of dependencies, or is a general application problem.
All this means that it's unlikely that Servo would exist in its current form if it were packaged and distributed under the traditional package manager system, because that would create so much more work for everyone involved.
But isn't the problem with X- headers that if they ever get standardised, they necessarily create this smuggling issue? Whereas if you start with an unprefixed header and standardise it under the same name, you avoid this issue.
You could also solve the problem by standardising the header with the X- prefix, but this is more confusing to users and violates the idea that X- always means "not standardised", at which point the prefix is useless anyway.
The point is that you probably don't care that much how exactly the dependency is called, as long as it is called in such a way that it does the action you want and returns the results you're interested in. The test shouldn't be "which methods of the dependency does this function call?" but rather "does this function produce the right results, assuming the dependency works as expected?".
This is most obvious with complex interfaces where there are multiple ways to call the dependency that do the same thing. For example if my dependency was an SQL library, I could call it with a string such as `SELECT name, id FROM ...`, or `SELECT id, name FROM ...`. For the dependency itself, these two strings are essentially equivalent. They'll return results in a different order, but as long as the calling code parses those results in the right order, it doesn't matter which option I go for, at least as far as my tests are concerned.
So if I write a test that checks that the dependency was carried with `SELECT name, id FROM ...`, and later I decide that the code looks cleaner the other way around, then my test will break, even though the code still works. This is a bad test - tests should only fail if there is a bug and the code is not working as expected.
In practice, you probably aren't mocking SQL calls directly, but a lot of complex dependencies have this feature where there are multiple ways to skin a cat, but you're only interested in whether the cat got skinned. I had this most recently using websockets in Node - there are different ways of checking, say, the state of the socket, and you don't want to write tests that depend on a specific method because you might later choose a different method that is completely equivalent, and you don't want your tests to start failing because of that.
The fakes vs mocks distinction here feels like a terminology debate masking violent agreement. What you’re describing as a “fake” is just a well-designed mock. The problem isn’t mocks as a concept, it’s mocking at the wrong layer.
The rule: mock what you own, at the boundaries you control.
The chaos you describe comes from mocking infrastructure directly. Verifying “deleteUserById was called exactly once with these params” is testing implementation, not behavior. Your HashMap-backed fake tests the right thing: is the user gone after the operation? Who cares how. The issue is finding the correct layers to validate behavior, not the implementation detail of mocks or fakes… that’s like complaining a hammer smashed a hole in the wall.
In the SQL example, unless you actually use an SQL service as a fake, you cannot really quite get the fake do the right thing either. At which point, it's no longer a mock/fake test but an integration/DB test.
Network servers are another such class and for most parts can be either mocked or faked using interface methods.
I would argue that (barring SQL), if there are too many ways to skin a cat, it is a design smell. Interfaces are contracts. Even for SQL, I almost end up using a repository method (findByXxx flavors) so it is very narrow in scope.
Isn't that exactly what privilege is though? A measure of a person's ability to be part of that self-selected pool, and to shield yourself from issues that affect other people?
"Privilege" has sort of morphed in an mostly-untouchable insult and I don't think it means very much of anything any longer and should not be used. What it means in practice:
- You can't have an opinion because you're in the wrong group.
- Your opinion is wrong because you're in the wrong group.
- Your opinion is hypocritical (and therefore wrong) because of the group you're in.
It's a big step back with regard to argumentation. Ideas are either correct or not, and the fact that they came from someone who might have some advantages does not weigh in on this.
I've not noticed that change in my own conversations, where privilege maintains its pretty clear definition. Maybe you need to find better conversation partners? Or perhaps you're misunderstanding the criticisms that people have of what you're saying?
I like both the options you've proposed for me: either I only speak with awful people, or else I'm always wrong. I'm sure it's one of those two options.
I'm being snarky there, but I've genuinely never seen people make the arguments you're talking about in real life, and I run in some fairly lefty circles. Maybe online, but even then I rarely see people actually trying to argue that privilege has anything to do with the validity of people's opinions. More common is the idea that we need to better promote the voices of those with less privilege, which I don't see as being a particularly objectionable idea.
The only place I regularly see the points you mention are in the opinion pieces of certain types of pundits who like to peddle outrage and invent menaces that don't exist. They regularly tell me that people say those sorts of things, but rarely seem to be able to provide receipts.
Googling it, looks like the trip costs around $6.5k for 2 people for a week. Expensive, but not out of reach for most Americans.
I mean we're on HN... if anything we're more likely to be in a wealthy bubble here. On average. There's plenty outside Silicon Valley but this place is a bubble too.
The US doesn't mandate any vacation or sick leave days, so a huge chunk of the population can't even get a week off work, much less afford $4k per person.
I live in the US and I've worked minimum wage jobs for half my life. By minimum wage I mean where they only give you 29 hrs a week to avoid risking you become full time and you have to work two.
Yet, I've always been able to take time off if I really press for it.
You're absolutely right that it's not easy and harder than the average crowd here but it's far from out of reach.
Also, you hiked up the price by 20% by rounding in the wrong direction. While Americans don't have mandated vacation most Americans have access to PTO. You don't need to exaggerate problems to be able to discuss them. It only makes them harder to discuss and easier to dismiss
How often can you get that week off? Most people I know working in the service industry have to fight to get that even once a year. Hopefully someone's OK not going home and seeing their family in a year to take a vacation like this. Hopefully they don't get sick and need the week for that.
To the cost: $6500 for two is low. Just getting there will be a significant amount, especially if you don't live in a major travel hub like LA or NYC.
"My Galapagos excursion took place on a boat with over a dozen other travelers."
The absolute cheapest is the 100-passsenger Galapagos Legend at $2000 per person for 4 days, 3 nights - but a flight to Baltra Airport from, say, Pittsburgh will add another $1800 per person, and even from Chicago it's $1500 on a mix of airlines.
If you want a small ship with only a dozen others it will be significantly more expensive. If you want a week on something of that size you're looking at $4700 per person and up - plus travel. https://www.galapagosislands.com/cruises/catamaran/tiptop-ii
I would imagine the set of people who would spend $4K per person on a week in the Galapagos does not contain very many people who don’t have 3 weeks of vacation per year (or are retired).
That's definitely out of reach of most Americans. I live in rural America, and am pretty active in my community. I can thing of 2 or 3 couples besides myself who could make a trip like that reality. We are all remote-workers working in software.
- Median bank account balances in the U.S. range from $5,400 for those under 35
- ... $13,400 for ages 65–74
So yeah, in range.
Does it require saving? Yes. But most Americans go on vacation each year. Give up the cost of a few years of vacations and you have this one.
I want to stress "not out of reach" doesn't mean easy. It explicitly doesn't mean one doesn't have to reach. I'd have said something very different if I meant most Americans could easily go on that trip. I specifically mean if it's something they really wanted to do, enough to save over a few years (or more) then that's something that could be accomplished.
You don't need the hidden="until-found" for details/summary, because that has those semantics automatically, but you can use that for other elements that behave similarly (for example tabs, which can't quite correctly be implemented with details/summary, and so needs to be done by hand).
Also I think the event isn't currently emitted consistently on all browsers (and maybe not at all for hidden="until-found"?) so unfortunately you can't quite rely on that yet if you need to sink some JavaScript state to your html. But in general, yeah, this is a really cool feature.
Yeah, support was patchy until recently (and I think that behaviour might not even have been standardised?) so I think a lot of people have assumed that if you want that functionality you need to do something extra.
Yes, Google started revealing the contents of <details> a few years ago, long after the element was supported in all browsers. Firefox added support earlier this year and Safari just added it.
Supporting the behavior was related to changing the user agent CSS when they're closed and the other browsers implemented it and hidden=until-found at the same time.
I would generally caution against doing toggles with CSS. While it can be done, it often has surprising effects, and can be difficult to make properly accessible (for example in the case of opening the navigation, I don't believe it's possible to set the correct aria tags to indicate that the toggle is a button that is showing/hiding another element on screen).
Instead, for a brochure site like this, I'd rather have the links just always visible, because this is the reference site for Ruby and I imagine a lot of people find them by searching "Ruby", coving l clicking the homepage, and scanning for the link to the docs/downloads/etc.
Alternatively, if the show/hide feature is really that important, right now I would (a) explore whether it can be done accessibly using the new invoker API, so you don't need JavaScript at all (with a JS fallback), or (b) just do it in JavaScript directly, but with an accessible default if the JS doesn't get loaded properly.
But yeah, the rest I largely agree with. There's a bunch of stuff here that would have been simpler, and arguably also easier, if they'd taken a slightly different approach.
Yeah, I thought those code samples would run immediately, in which case maybe the loading would be justified (although surely very easy to avoid). Instead, they're links to a different page that has the same code sample and a link to run the code, meaning I need to press twice to see what the code does when it runs, which isn't a lot but is surely at least one (possibly two) clicks more than necessary.
That said, it's cool seeing some of those samples, because they're honestly not really what I expected. For example, I didn't expect the list subtraction to work at a set operation, so seeing that example gives me a feel for what sort of things I can do with Ruby code.
> I need to press twice to see what the code does when it runs, which isn't a lot
I don't know the exact numbers, but the figures show you lose a high percentage of viewers with each click. So if you have 100 people who view the first page, 10 of them might click the link to the second page, and only 1 of them might click the link to the third page. If having customers view the running code is crucial, you'd want it on the very first page, above the fold.
I think the question is whether Cyberpunk 2077 would ever have been made under the constraints that Blow and Muratori talk about. Like, Order of the Sinking Star looks pretty impressive, but from what I can tell it's basically just a bunch of Sokoban-style games operating on a fixed grid. You don't need anywhere near as complex an engine for that as you do for a game like Cyberpunk 2077.
My impression is that the Blow/Muratori style works well if you're the only person working on a game, or part of a very limited team, which is fair enough, but it naturally limits the scope of what you can achieve.
Having a 3D engine does not a AAA make. The Witness is a beautiful looking game, but the amount of state and interactions it has to deal with is orders of magnitude less than GTA: San Andreas. It is closer to the complexity a Myst remake would have.
I think the key idea is that Rust gives you a lot of tools to encode semantics into your program. So you've got a much greater ability for the compiler to understand your semantics than in a language like JavaScript (say) where the compiler has very little way of knowing any information about lifetimes.
However, you've still got to do that job of encoding the semantics. Moreover, the default semantics may not necessarily be the semantics you are interested in. So you need to understand the default semantics enough to know when you need something different. This is the big disadvantage of lifetime elision: in most cases it works well, but it creates defaults that may not be what you're after.
The other side is that sometimes the semantics you want to encode can't be expressed in the type system, either because the type system explicitly disallows them, or because it doesn't comprehend them. At this point you start running into issues like disjoint borrows, where you know two attributes in a struct can be borrowed independently, but it's very difficult to express this to the compiler.
That said, I think Rust gives you more power to express semantics in the type system than a lot of other languages (particularly a lot of more mainstream languages) which I think is what gives rise to this idea that "if it compiles, it works". The more you express, the more likely that statement is to be true, although the more you need to check that what you've expressed does match the semantics you're aiming for.
reply