zbobet2012

The largest benefit of microservices has always been lifecycle management, and "clear interfaces" in "modular monoliths" does not in fact solve that. If you update the logging library in a monolith, everyone takes that updates even if it breaks half the teams.

That's a "large" organization problem. But large is actually, not that big (about 5-10 scrum teams before this is a very large problem).

It also means on critical systems separating high risk and low risk changes are not possible.

Like all engineering decisions, this is a set of tradeoffs.

I've had basic facts about mathematics which are wrong deleted in revisions by editors with no knowledge of the subject beyond having asked ChatGPT (which repeats the wrong shit on Wikipedia). It's hard to be worth it. Wikipedia's biggest problem is the editors.

This is true, and at the same time, this article is absolutely rife with unsourced, unserious points. However insane Trumps plans, the fundamental "facts" presented here are largely a joke.

Chinese workers work longer hours more happily and they’re physically faster with their hands; they can do things that American labor can’t. It’s years of accumulated skill, but it’s also a culture that is oriented around hard work and education that the United States no longer has. In China, there are no people who are too fat to work. The workers don’t storm off midshift, never to return to their job. You don’t have people who insist on being paid in cash so that they can keep their disability payments, while they do acrobatics on the factory floor that the non-disabled workers cannot do.

It's an actual joke to present something with such a derogatory view of the median American worker with no data to back it up. Most of America's "labor class" is in fact Mexican, the country with the highest annual hours worked per year. Secondly hours worked does not relate directly to productivity. American workers are the most productive in the world. [1]

More importantly, _we don't manufacture like this anymore, even in China_. Doing "acrobatics" on the factory floor is now obsolete. Much of what's said here fails to acknowledge that we would _not_ build our supply chains the same way as China does. China had a surplus of human labor (one that's facing an impending demographic crisis) and so used human labor in ways modern western countries would not and do not.[2]

[1] https://www.weforum.org/stories/2018/01/the-countries-where-... [2] https://ifr.org/ifr-press-releases/news/global-robotics-race...

Reproducing these supply chains is more possible than this article states. Doing it via destroying our economy however will not work.

That's only the case if you did PGO with "live" data instead of replays from captured runs, which is best practice afaik.

E.h., kind of. If you are allocating in a hot loop it's going to suck regardless. Object pools are really key if you want high perf because the general purpose allocator is way less efficient in comparison.

It depends on how long the time you spend in your c function is. cgo has a substantial overhead for calling. I tend to prefer just writing ASM functions for critical path code. You can use libraries like https://github.com/mmcloughlin/avo to make it easier to write/maintain.

So on point. We do _a lot_ of hand written SIMD on the other side (encoders) as well for similar reasons. In addition on the encoder side it's often necessary to "structure" the problem so you can perform things like early elimination of loops, and especially loads. Compilers simply can not generate autovectorized code that does those kinds of things.

It's not like sabotaging German ships will cause Germany to increase military spending or fix the Bundeswehr's comically bad procurement process so there is little risk for Russia in these actions.

The US has banned foreign leadership of tv and newspapers since the 30s. At no point had the US ever really allowed foreign governments unfettered control over our media.

We've banned foreign ownership of traditional media channels since the 30s. We did not ban the propaganda but we did deplatform it.

What same-process modularization does _not_ solve is independent lifecycle management. In a monolithic system your change rate often becomes tied to your slowest, most bug prone module or team. If you've some integration test that bakes some piece of important code for 48 hours, you can only make a change _everywhere_ else every 48 hours.

Now sometimes folks (the Windows team famously did this) build systems which identify which tests to run based on changes that occur in the codebase, but that's _not_ easy.

Winning in bd rate though isn't hard. You need to win in bd rate and have a hardware implementable, power efficient, cheap decoder.

Agreed hybrid presents real opportunity.

These sorts of models pop here quite a bit, and they ignore fundamental facts of video codecs (video specific lossy compression technologies).

Traditional codecs have always focused on trade offs among encode complexity, decode complexity, and latency. Where complexity = compute. If every target device ran a 4090 at full power, we could go far below 22kbps with a traditional codec techniques for content like this. 22kbps isn't particularly impressive given these compute constraints.

This is my field, and trust me we (MPEG committees, AOM) look at "AI" based models, including GANs constantly. They don't yet look promising compared to traditional methods.

Oh and benchmarking against a video compression standard that's over twenty years old isn't doing a lot either for the plausibility of these methods.

The thing I found interesting in the AVX512 gains over AVX2. That's a pretty nice gain from the wider instruction set which has often been ignored in the video community.

You've mis-understood. The 8tap filter is part of the HEVC encode loop and is used for sub pixel motion estimation. This is likely an improvement in encoding performance, but it's only in one specific coding tool.

Yeah that's cookies. They are great.

I'm a huge fan of providing laymen explanations. And at some point if you _actually_ want to understand you have to stop using those and pickup and understand the math.

http://therisingsea.org/post/mast30026/

Has a good introduction to space, and the notion of a manifold, and what a Minkowski space is.

Emacs has none of these problems :p

Sure, but you are most likely using these funds as core positions in an account which is SPIC covered to 500k.

If you have more than 500k of assets in this form, you should have multiple funds and bank accounts.

Again, you need the collapse of the US currency if you are a) not exceptionally wealthy or b) not wealthy and incredibly financially uninformed.

You missed the point. Most people take on debt when it's cheap (low interest) and take on savings when they have high returns (high interest). You save when interest rates are high, you buy when interest rates are low.

That interest rates change is global.

You've a mis-understanding of how funds like FDLXX are managed. In a T-BILL only fund even a decrease in past asset value doesn't matter because they are by law managed to 1$ of net asset value. That is they most hold 1$ of _current_ asset value for every 1$ deposited _at all times_.

The only situation where the value of the fund can be less than what you put in is the collapse of US currency, which savings account insurance can not protect against either.

Nope, my house loan is 2.3% my liquid savings in FDLXX are about 5%. What you are saying is only true if your debt is incurred at the same time as your savings are accumulated. That's actually rather unlikely.

Depends on the money market fund. There are US treasury only funds like FDLXX, basically the only situation it would become unable to meet it's cash flow obligations is if there where no buyers for US treasuries at face value.

And frankly if that's the case I wouldn't be betting on FDIC or equivalent insurance actually working anyways.

But even "less" secure ones are heavily regulated to be kept at 1$ of NAV and SPIC backed.

I think because there are some very unprofitable companies driven by engineers. You can't have an organization that is devoid of finance based drive. You need some balance, and it's not always clear what the balance is.

Syntax IMO. I know it's obnoxious, but the reality is most people read C like languages, not Lisp.

This is interesting, but it's key to remember that audio and video codecs have three primary constraints in there design: compression efficiency and encode, and decode complexity

Simply addressing compression efficiency without considering the other constraints makes for an impractical codec.

If your encode complexity is too high, then you can't handle real-time (live) use cases, and your compute requirements may make practical use for large libraries like social media impractical.

If your decode complexity is too high mobile devices will suffer from severe battery drain or simply won't be able to decode, even in hardware. Dedicated hardware may also have to much complexity to implement in a cost effective way.

Maybe Not is an excellent video in some ways, but I just watched it a few years later and it reminded me that as much as I love almost every Rich video, I do wish he'd spend some time reading a little deeper on type systems and theory.

For example his note about "Categorical descriptions" and then the explanation about maps/and spec at 25:00[1] seems to indicate he's unfamiliar with the difference between extensional and intensional type theory.

The core difference between the two is extensional type systems decide equality on the observable behavior of the output. For example if two functions take the same input, and produce the same output extensional type systems/theories say they are the same. The problem with this is type equality is then undecidable.

Extensional type systems also struggle because there are more than one way things might be equal! For example two string might be equal if you ignore case, but unequal if you don't. So if we want our type system to check if two functions are equal under case insensitivity an extensional type system will struggle with this.[2][3]

Now in fairness to Rich, these concepts come more from the math community, especially the notion of types being equal under different paths, and in the case of Homotopy type theory are burred in unapproachable language and concepts... even by mathematicians standards.

He also talks about select from spec, and it not preventing you from passing types broader types, and the necessity of specifying deeper type.[4] But, that's just an eliminator defined on the type[5].

Now most strongly typed programming languages suffer from the issue he identifies when talking about not making brittle systems [6] and the issues you get with coupling around taking a map/struct/product type C = A X B (e.g a map C = {A: something, B: something}), and you require A so you're function should be good but you fail to compile because the function says A, and now you're passing C.

It's frankly pretty annoying in places like Java that if you have a Point = Int x Int y you can't use it in functions which take a Tuple = Int x Int y. I'd actually say that's the common observation that both Rich, the Go Inventors, and the TypeScript folks have all made. You need to care about the extensional type of your input (and output) fairly often. And carring around the intensional type causes both dependency issues and just some general PITA's.

[1] https://www.youtube.com/watch?v=YR5WdGrpoug&t=1504s [2] https://math.stackexchange.com/questions/4486995/what-is-an-... [3] https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Ext... [4] https://youtu.be/YR5WdGrpoug?t=2668 [5] https://www.quora.com/In-type-theory-what-is-an-eliminator-a... [6] https://youtu.be/YR5WdGrpoug?t=2823

Rich's simple made easy is the best programming video I've ever seen, and is ultimately I think what so many engineers need to "grok" to unlock better coding. I'm the "most senior" engineer (chief architect) in a company of more than a thousand engineers, and I recommend it to every junior who asks how to get better.

I will also say I used clojure + aleph to write the only significant application I ever released which never had a reported bug or outage. It ran for seven years and that application was under constant heavy load (more than 10k TPS).

Only over an electromagnet, not a fixed one (to our knowledge). Digmagnetic levitation requires more than one magnet or an electromagnet.

https://en.m.wikipedia.org/wiki/Magnetic_levitation

No, digmagnetic of levitation requires multiple magnets in a halbac array: https://www.kjmagnetics.com/blog.asp?p=diamagnetic-levitatio...

https://pubs.aip.org/aip/apm/article/9/10/101107/1061600/Pho...