bencyoung

From what I remembe of Undergrad physics this isn't actually possible. According to GR, within an event horizon, space-like pths become "time-like" which effecitvely means the singularity is unavoidably "in the future". No matter how big a black hole is, you can't just drift around inside it as literally all paths lead downward (hence even light not escaping)

If you were inside a black hole you wouldn't be able to see light from "deeper" because it wouldn't be able to travel towards you.

This is not what we see within the universe, so I don't think we can be inside a black hole

Personally I think this is a really cool idea: https://experiments.withgoogle.com/paper-phone. Both mildly mocking and thought provoking at the same time!

I once had a financial bin packing problem at a previous company. Rather than going down a dynamic programming route which was highly exponential, we decided to use a combination of monte-carlo simulation and a very basic genetic algorithm to try and find a solution. This made use of the fact that we could try solutions extremely quickly, and also timebound the overall time taken (something that was important as we had a limited time window). We'd still be able to run 1-2e6 different approaches in under a second.

Although we couldn't guarentee the "best" approach possible we generally came up with something good enough, often in many orders of magnitude less time.

A good example of the performance improvements you can make when you move from thinking of what the best solution is to what a "good enough" one is.

The worst memory performance bug I ever saw turned out to be heap fragmentation in a non-GC system. There are memory allocators that solve this like https://github.com/jemalloc/jemalloc/tree/dev but ... they do it by effectively running a GC at the block level

As soon as you use atomic counters in a multi-threaded system you can wave goodbye to your scalability too!

Yep mine too! It's pretty cool that they put this level of detail out there

We're a startup that uses dotnet. Develop on Windows and WSL, deploy to Linux containers in K8s. Works fantastically well for us.

I think one thing that's very underrated in dotnet is the new analyser functionality. It basically allows to to upgrade an migrate your whole codebase to new versions/preferred idioms in a zero cost way. Of course you can stick with the existing code as generally compatibility is good, but the analysers are fantastic things I haven't seen too much in other languages.

I think it certainly used to be the case, but I don't see this any more. Having said that dotnet is pretty "batteries included" so you can go a long way without too much third party stuff

I've been at tech startups and high tech jobs that both heavily use dotnet so these seem anecdotal at best. If you're in the ecosystem there are huge numbers of jobs out there

If anyone's in the UK I can recommend our product Paycada for this (https://www.paycada.com/)

The main thing Kafka is great at is scaling out via partitions with it's natural stickyness, while maintaining excellent ordering guarantees. This means it's really easy to create a load of reliable in-memory processing where each thread processes a single partition of data.

When scaling out on a standard message queue you generally have greedy consumers which means you can't assume stickyness, or have to create your own partitioning structures. It makes it great for realtime apps...

If there were cheaper alternatives I think people would use them but it does definitely have powerful benefits.