kag0

It's a compiler level thing, not runtime.

ie. Scala has tail call optimization but Java doesn't, but they both run on the same JVM.

Your credit card runs Java, that's a fun one

I don't have experience with managing large amounts of data with actors. But I can say from the actor experience I do have that you can't think about it in the mindset of "how can I replace my relational database with actors".

Actors can be a near-sliver bullet for some things, but you have to think about solutions differently. I always though a bank was a good example. One actor per-account, how do you think about money in flight and such? Probably in a fundamentally different way than you would in postgres.

> hard to query

That one is easy though, CQRS

Kotlin is like Scala (more ergonomic and with immutable collections in the standard library), but without implicits and with Java's weaker type system. It also has more compilation targets than Java (js, llvm, jvm).

Java is already taking hints from Scala and quickly adding Scala inspired features, which is making it similar to Kotlin. I think unless Kotlin innovates and does something not already in Scala, it will likely run into the issue of being too similar to Java ~20.

Author here, I've been working on updating documentation for my open source libraries to use embedded snippets from tests. That way I know that the documentation is up to date if tests pass. I made this to improve on an existing service (gist-it) so that no dependency on an external service and there was no need for hacks to get custom styling.

Maybe. But a more clever approach might be to limit the size of the HSTS cache per second-level-domin per orign. Or to randomly respect the cache. Or to simply make every request to both the TLS and non-TLS port but do so in parallel and discard the non-TLS response if the domain was in the HSTS cache.

I'm not saying any of those approaches is bulletproof, just that maybe they have a more complex strategy in mind to mitigate risk.

This is related to my main question about this. What if browsers just... don't implement this?

What makes Google think that Apple or Mozilla are going to add this to their browsers?

As a backend engineer who has worked on frontend recently, yes, that's how they do things.

There is some hope though, recent standards like web components and ES imports help a bit.

You could. That's how something like CHAP works.

You'd actually end up hashing it twice. Once using the salt to go from plaintext to what the sever has stored and then again using the challenge.

It has problems though. The strength of your password hashing would be limited by what the weakest client could do, rather than what the server could do. Asymmetric encryption ends up being simpler.

I thought the same. After how consistent Scala's syntax is, it's hard to adjust to what Rust has done here. In Scala

  val hello : String = "hello" // eagerly evaluated once
  def hello : String = "hello" // evaluated every time
  def hello(name: String) : String = s"hello $name" // parameters

counterpoint: you can implement RPC using queues. queues are just one more tool in the toolbox. it's not the screwdriver's fault if it's used to hammer nails.

> Basically you've probably just created another database

I think that's a fair assessment of persistent queues, using "database" in the most general sense.

> Worse, that database may be different to your other databases.

Different isn't inherently worse. It's just a different tool for a different job than a traditional RDBMS. The problem only occurs when we pretend they're the same.

For example, in a near-real-time application it may be better to fail than to have overly delayed message delivery. If a queue becomes too large then we get the idea that messages are not being consumed fast enough (in near-real-time). In this situation continuing to send more messages is just going to make the problem worse (although this is more like a circuit-breaker/fail fast than back-pressure). Also it might be better from a business logic perspective to inform the user of the problem than to apply their input at a later time (eg. a game where user input is unlikely to be intended for anything but the very recent game state).

I agree in general, but is this really true?

> the legacy chip makers have a business model that doesn't work

It seems like this implicitly assumes that everyone switching to Apple silicon is a possibility. But it doesn't seem likely that all the android users are going to switch to iphones or that all the windows/linux users are going to switch to macs.

This is hugely embarrassing for Intel and Qualcomm in particular, and stocks will fall. But the business model outside the walled garden isn't necessarily going to change.

What does everyone think about programming fonts with script italics (dank and victor mono)?

I've come to like them when italics are restricted to keywords. I've found that it makes it much faster to recognize the structure of the code.

Interestingly, the scala language previously supported either => or ⇒ and deprecated the Unicode character in favor of instructing developers to use ligatures for that aesthetic effect.

Pre-deprecation, there were formatters which would replace the two characters with the single unicode character if you wanted. If you use a language which supports unicode function names and operator overloading, you could easily add support for your unicode comparison operators.

Oddly this site doesn't show the italic variants of fonts, unlike https://www.programmingfonts.org which was on the front page some time ago iirc.

The assertion is that compilation might be faster since there are fewer optimizations, and therefore runtime would be slower.

> how much business efficiency could be gained by taking advantage of the fact that we all know the products our businesses are buying are oversold?

Not much tbh. Our only other option is to not buy, and build in-house instead. Sometimes that's worthwhile, but other times (like in the case of zoom) it still makes sense to buy the vendor's product, even if you know that it's not everything it's advertised as being.

The real efficiency is found in having people who can determine which and if you should buy a vendor's product, or if you should go in house. Specifically people who can see through the marketing BS and evaluate technologies without personal or hype bias.

I think you're missing half of the point. It's a _review_ site for durable products. Presumably the reviews will tell you if it is good.

I'm happy about it.

For me, one shortcoming of gitter is that it has always been tertiary in my pool of chat services. The more tertiary services are accessible through matrix the better, that way I'm less likely to miss notifications.

I don't think there are big downsides, I can't think of anything in the core gitter chat that I would miss when switching to matrix.

The very visible branding is because a) they work very closely with the products that get to use goretex, and they guarantee those products. So if I buy a Marmot rain jacket with goretex and I have a problem with it, I can go to goretex and they'll replace it. That's a pretty strong guarantee that consumers want to see very visibly. and b) they market hard to convince consumers that if it's not goretex, it won't be breathable. A bunch of competitors (outdry, event, neoshell, etc) popped up a few years ago and lots of companies switched to them from goretex, but goretex has since reeled them back in and now we see most companies using only goretex again.

The car was speeding before it hit the woman, and the driver was most probably watching TV before/as it happened. I can see how this would be bad press for self-driving cars, but this really seems like the error is on the driver. Maybe Uber failed to adequately communicate to her what her role was in the car, but otherwise it seems like pretty open and shut negligence.

I meant the thinking that tries to minimize cost and aims for "how much they have to pay you before you decide to quit".

> going to really suck for the people who have gotten used to earning $200K entry level in San Francisco

at first, yes, but wouldn't CoL eventually come down if everyone were earning a nationally based income?

There's a name for that kind of thinking, but I can't recall what it is.

Essentially you're minimizing cost by paying the lowest possible local rate, but isn't it just as valid for someone else to maximize quality by paying a competitive rate for the most expensive locale? Presumably both would be pushed to a middle (location independent) wage because the company minimizing price will (presumably) have issues hiring all bottom-of-the barrel employees, while the company optimizing for quality will have issues paying top dollar when it only provides marginal gains over a high-average wage.

Can someone explain the rationale behind geographically based pay in remote-first companies?

I don't necessarily disagree with it, but I don't know what aspects of the issue companies are actually looking at to decide that geo-based pay is the way to go.

the problem with that (and security through obscurity in general) is that if your opponent attacks at random, they still have a chance of getting you. having lived in a bad neighborhood I can tell you that you don't have to flash money, or even look like you have any money to get into trouble (someone chooses you at random for a gang imitation, crackhead wants your shoes, or someone is just straight up crazy). it's always better to have as much cover is reasonable, and beyond that concealment doesn't hurt.

> there is no such thing as truly random number generation on contemporary computers

well that's just not true. there's no shortage of noise we can sample to get true random numbers. we just often stretch the random numbers for performance purposes.

I've always had a crazy idea that a wealth based income tax would be the way to go. ie. the more wealth you have, the harder it is to get more. This sounds like the capitalist's nightmare; but it encourages spending, and encourages innovation.

The problem with wealth based tax is how to accurately assess an individual's wealth. If someone has a resource for how that would work, I'd be interested.