mason55

No, because there was no year zero. The first century started in the year 1 AD.

I don’t think they’re independent events. Bayesian priors would say that if you have five failed businesses then your chances of being successful on number 6 are probably less than 60%

Yeah the keys to make it all work are

1. It's easy to create the objects you need

2. Your creation functions are well tested so that the rest of your tests can rely on them.

If you have spotty coverage or just poorly defined creation semantics, or it's a bunch of calls to functions all over the place just to set up your test data, then this doesn't work.

But the solution typically isn't "write a bunch of JSON mock test data", it's to solve those problems.

Huh. I’m shocked at the storage temps for apples. I always heard they go mealy in the fridge. Also that you should store things at home like they are in the store, and apples are never refrigerated at the store.

Lots of stuff that says 50-55 F which is unfortunate because most people don’t have any kind of storage at that temp.

Lots of companies still work like you said. With a company like Amazon, though, you have two things at play.

The first is that it takes a massive amount of dollars to make an impact on revenue. You're just not going to move the needle by selling a new product or something. It's a mature business and to meaningfully increase your revenues you need to alter people's current behavior so they spend more.

But, the second thing, is that if you manage to increase revenue by a percentage point, that is a huge amount of money, and that potential payoff can justify a huge investment. And once you've made that investment, there's a lot of incentive to try to make it work (between sunk cost fallacy and potential payoff).

Lots and lots and lots of companies fail because they build something that doesn't solve a need. It's like the number one thing you learn. This is nothing new. It's just that in the age of hyperscaled tech companies, the payoff for unlocking a new market or changing user behavior is huge, so you end up with lots of attempts to develop some technology and then figure out how to use it to change the world.

> but I need to put it in “gaming mode” manually?

No, I don't think so. I'm pretty sure the point is that the phone does it automatically when you're playing a full screen game.

In the Getting Started section, why have the user write the code before installing the dependency? Any kind of Python tooling is going to complain that the import doesn't exist when the user goes to write the example. Obviously it doesn't really matter but there's also no reason to not install the dependency first, and it will provide a better dev experience.

As mentioned elsewhere, what this is actually doing is showing that string and String are not structurally equivalent in TS.

If you add another class Email that extends String, you can pass it as a Hash without any problems. And you can get rid of the Hash stuff altogether and do something like

  compareHash(userInput, new String(userInput)); 

and that fails just as well as the Hash example.

Using extends like this doesn't actually fix the problem for real.

Or, a version that's more inline with the post you're replying to.

Just add an Email class that also extends String and you can see that you can pass an Email to the compareHash function without it complaining.

  class Hash extends String {}
  class Email extends String {}

  // Ideally, we only want to pass hashes to this function
  const compareHash = (hash: Hash, input: string): boolean => {
    return true;
  };
  
  const generateEmail = (input: string): Email => {
    return new Email(input);
  }
  
  // Example usage
  const userInput = "secretData";
  const email = generateEmail(userInput);
  
  // Whoops, we passed an email as a hash and TS doesn't complain
  const matches = compareHash(email, userInput);

https://www.typescriptlang.org/play/?#code/MYGwhgzhAEASkAtoF...

Yes, that is the core PE playbook.

1. Acquire loan to buy company

2. Take money that was being spent on growth and use it to make the payments on the debt

3. Try to decrease operating costs while maintaining revenue or increase revenue while maintaining operating costs (or some combination)

4. Sell the company for more than you paid based on the improved profit margins

The key is finding a company who's still spending on growth but isn't really growing. If the company is actually still growing then you're going to have trouble making your money back if you cut growth activities (because your initial price would be higher due to implied growth in the future).

The challenge is in step three. Can you increase revenue or decrease operating costs without sacrificing too much goodwill? If you do too much to scare away suppliers or customers then step 4 is hard and the whole thing blows up.

Eh, they compared the M3 to the M1 when they launched it. People grumbled and then went on with their lives. I don't think they'd use that as a reason for making actual product decisions.

I'll echo what the other reply said. I wanted to use it like a digital whiteboard in meetings, but the flow just isn't there.

Yes, drawing on it in isolation is great, but it hasn't otherwise worked out like I hoped.

I could certainly be abnormal, but I'm much more likely to sign up for something that has a real free tier. There's honestly very little difference to me between 60-day free trial and just having to pay from the start, I know that once I do the work to integrate then I'm committing to having to pay. At least for a startup with little revenue and little cash, 60 days is just too soon to commit to having to pay, unless it's like $10/mo.

What's worked better for me is the "startup scholarship" that a lot of companies are doing now. A year is far enough away that we'll either be out of business or have the cash to pay, and I don't need to worry that I'm getting my money's worth by the time the 60-day trial ends.

I'm a big fan of Posthog right now because they have both a generous free tier & a generous startup scholarship. I've moved a ton of stuff to their platform.

A lot of it probably depends on your product though. If you're solving a very targeted problem then you might not be able to create a reasonable free tier. But a lot of B2B tech stuff is like... sure you can charge a bunch of users $5 apiece, but you risk missing the signup of the one user that was going to pay you $10k. Anything with usage-based pricing is going to have Pareto distributed revenue and you need to do everything you can to make sure you're capturing those customers on the tail.

Option a, you stay small, don't chase trends, and you bring in decent profits year after year. Eventually maybe you close but not after paying back the investments plus more.

Option b, you grow super fast, you have a lot locations, each one barely profitable, but you make it up on scale. You scale quickly enough that you make a lot of money before trends change. They key is that you accept that you're chasing a trend and move as quickly as possible to extract as much as you can.

Option c, you come up with the core concept, and you create a franchise program. You make your money off franchise fees & shadier stuff like making the franchisers use suppliers that you own. The franchises die when trends change but some made a profit, and your capital outlays were never very high, so you make a lot of profit.

It’s not the $9k deposit that’s illegal, it’s structuring your deposits to avoid the $10k limit. The same actions can be legal or illegal depending on your in intent.

In your example, the $9k deposits are perfectly fine. Although if you really always deposit $9k you’ll probably get some questions.

The decision between structural and nominal typing has nothing to do with whether you retain type information at runtime.

TS could have just as easily chosen nominal typing + a simple way to do typedefs and had everything else work like it does now. But structural typing gives you a lot of other useful features.

Not really, not for TS at least. If you just want to take a string and call it an email address and have your function only accept email addresses (the simplest use case) then you need to use branding. That's not encapsulation.

Works very well too for any kind of validation or encoding. Anything that accepts input from the outside world can accept a string. And then everything else in the app can work with a "SafeString" and the only way to create a safe string is to send a string through a string escape function (or whatever makes sense for your app).

Works especially well if you're using any kind of hexagonal architecture, make your functional core only accept validated/escaped/parsed/whatever types, and then the imperative shell must send any incoming data through whatever transformation/validation/etc before it can interact with the core.

Yeah, or what's more likely is that you originally used an AccountID everywhere, but then you decided that you want to use a UserAccountID. So you update your functions but you miss a spot when you're updating all your call sites.

Or you have a client library that you use to interact with your API, and the client library changes, and you don't even notice.

Or you change the return type of a function in a library, and you don't even know who all the callers are, but it sure would be nice if they all get a build error when they update to the latest version of your library.

Lots and lots and lots of ways for this to happen in a medium+ sized project that's been around for more than a few months. It's just another way to leverage the power of types to have the compiler help you write correct code. Most of the time most people don't mess it up, but it sure feels good to know that it's literally impossible to mess up.

Java was in real danger in the seven years that it took to go from 5 to 7. Very little of substance was added and it didn't appear like there was a path forward to get any real new features added to the language.

Yes, Java is not the language to use if you want the hot new PL ideas in your language. But languages need to continue to move forward because it's not like PL research is dead either.

I think Java does a really good job now at being conservative with what they add while still keeping things modern enough that people aren't abandoning the language. Once features have proved themselves in other, less conservative languages, the Java team can add them, with the benefit of seeing what sorts of problems might arise.

Right. There are lots of things I’ll spend $100 on an entertainment expense for a night out. And plenty of things that people think is worth $100 for entertainment that I don’t find to be worth it.

And the house edge at a casino isn’t THAT bad. Eg if you’re playing blackjack at $20/hand, a house edge of 1% means you can play 500 hands for your $100.

I'm not sure how updating dependencies a few times a year makes you safer from a well-hidden supply chain attack.

Also, not sure what JS has to do with the xz attack.

The argument I was responding to is that automating your dependency updates somehow makes you more vulnerable to a supply chain attack.

I could see an argument that waiting X days from a dependency release to when you pull it in gives you a little time for other people to find issues. But that's orthogonal to whether you update dependencies automatically or manually, or whether you do it once/year or every day.

Sure, why not? Are you suggesting that having a human in the loop, robotically bumping the version numbers of your dependencies would have mitigated it?

Lots of humans upgraded lots of dependencies without noticing, I doubt whoever is doing it in your org is special enough to be the one who would have caught it. And if they are, they should be working in security research, not bumping dependency versions in package.json.

Which is fine, I'm just saying you're not the target market for the big observability vendors.

The current generation of observability tools is built for distributed systems that are basically too complex to reason about, and so you have other ways of monitoring and debugging them. When you have 10's of k's of ephemeral containers running hundreds of services, you can't just look at some logs for a server to understand what's going on (ignoring the fact that servers aren't even a primitive in this system).

10's of GBs of logs a day just doesn't move the needle on pricing. They want the customers that are going to generate 7 figures in revenue and those customers aren't talking about aggregating logs from a few hundred servers.

Yup and the reason no one markets something like "tail the logs for server X" is because, if you're talking in the context of an individual server, you're too small for anyone to care about.

This is one of the best responses about market positioning that I've ever read. Best of luck to you!

Does accepting cash really save a business that much money? I've heard arguments in the past that it ends up being a negligible difference once you account for all costs of processing cash (someone has to take it to the bank, it can get stolen in a robbery, employees can skim, you have to count it, you need a safe, you need cash deliveries, etc).

I have no numbers, so it could be totally off-base, but it feels not-impossible that it costs a percentage or two to process all your cash anyway, so the difference between cash & credit cards isn't actually that big. It's just that the interchange fees show up as one big chunk whereas the cash processing is lots of little bites, or even accounting for things that didn't happen (like skimming).

I guess this only applies if you're legitimately reporting all your cash take, if the business itself is skimming for tax reasons then the savings on cash would be substantial.

It really depends on which parts of AWS you're using. Spinning up a bunch of EC2 instances and treating them like colo'ed servers has pretty much always been boring (other than the excitement of not having drive to the DC when you need to reboot something).

> If they believe the things you disparage it's because the governments and systems that the "smart" and wealthy have created have utterly failed at getting those people educated and involved.

I think the issue is that there are two groups of smart & wealthy people.

There's a mid-level of people who are happy to have more than they need and don't have the Machiavellian drive to extract every last ounce of money and power.

And there's an upper-level who are fine exploiting anyone and everything.

There are of course altruistic people who are extremely wealthy. But sort of by definition, the middle-level is never going to have the drive & energy to fight that upper-level, who's willing to do anything.

I guess my point is that there are two groups of smart & wealthy people, and the ones complaining about the lower class being exploited are not the ones who are doing the exploiting. It's a classic setup where the upper class keeps the middle class happy enough to not make it worth the middle class joining the lower class in revolution. And they aim the ire of the lower class at the middle class while they exploit the lower class.

I imagine that both of those were quite a bit more expensive to build.

The point isn’t that houses from the 40s are still standing. The US also has tons and tons of those. The point is that the cheap, modular, assembly-line houses are still standing. Cheap usually equates to non-durable so it’s notable that these cheap houses are an exception.