giulianob

Great example of how bad dynamic languages represent data in memory.

Yes, absolutely a language without types is slower. Performance nowadays is almost always due to memory access patterns and allocations. Dynamic languages not only do not often have enough information to properly allocate memory in an efficient layout but they also tend to allocate a lot overall. Assembly is generated by languages that are compiled natively or on the fly for JIT languages. The type info is used to generate more efficient assembly.

Those people are also missing the point that not having types means you are inherently writing a slow program.

It's both. Go look at your memory usage per tab and it's not uncommon to see hundreds of megabytes for a simple static 2d UI. The way web renders is extremely inefficient then you couple that with a language that has no regards for how a computer actually works and you get to the sad state we're in today.

I recently went through this exercise and it really is sad. I actually decided to use the Godot game engine because at the end of the day it's fairly lightweight, you're in complete control over the rendering, the built in components are great (the editor itself is written in the game engine), it supports C#/C++, it runs literally everywhere, and it's completely free/open source.

I'm keeping my eye on Flutter and Avalonia as well but so far Godot seems the most mature on the desktop.

Have you actually looked at how much you make on unemployment? I'm in Florida and you get $275/week. The federal govt is giving an extra $600/week for 4 months. So you'd be making $3500/month for 4 months before it drops to $1100/month. Also consider that you have additional expenses like health insurance if you're not employed. It's basically buying people a little bit of time to find another job before they go back to regular unemployment wages which I consider below poverty line.

No, anything other than finding by id is eventually consistent by default. Also, modifying the schema generally means reindexing. Those 2 points should be enough to keep you away from trying to use it as a standard db. Use it for data that needs rich searching like it was designed for.

Regardless of whether it's on the stack or heap the point still stands. If all your objects are randomly allocated then an array is just references to those objects and will start out null. If you're using value types then your array of objects will never be null (empty instead) and you will benefit from CPU caching the data.

I have an UHK now and love it so much that I bring it back and forth to work everyday. Before the UHK I had a MS Sculpt and was a bit worried I wouldn't be able to get used to the UHK so I used Karabiner to set up a mod later and pretrained myself for a couple of weeks before pulling the trigger. Once I got the UHK the learning curve wasn't bad at all. For people who maybe tried a split keyboard and couldn't deal with it I would recommend the UHK since it's mostly the same as a regular keyboard.

The official demo that uses wasm is here https://blazor-demo.github.io/

Performance is only part of it. Using a single language for the whole stack is very valuable to a lot of people. I think that's why Node gained popularity because many developers were using JS for the frontend so why not use the same language for the backend as well?

I believe most of these are from Span which allows doing a lot of operations (e.g. substring) without allocating a new object.

The OP just said it would be hard to do that query (regardless of performance) and I'm saying it's totally capable.

MongoDB has supported some types of joins for years now, you can do quite a bit with MongoDB aggregation pipelines. https://docs.mongodb.com/manual/reference/operator/aggregati...

As requirements change, you do need to migrate your data into a schema that makes sense and that's regardless of whether you're using SQL or MongoDB.

Isn't "fulfilled by Amazon" more trustworthy since they are shipping the product to you rather than a 3rd party? Or does Amazon fulfill counterfeits too?

My point is you need to balance the effort you're putting into your estimates vs getting work done. Customers also won't be happy when you give them a date and don't meet it. Honesty is important too.

I think what a lot of people fail to take into account is the amount of effort it can take to "estimate" tasks. From my experience, the more pressure there is to give an estimate the less time they want you to spend researching the work. To increase the accuracy of an estimate, you need to do more research and if you take that to its logical conclusion then the best estimate is given after the work is completed. So there is some area in between of extremely inaccurate guess with little effort to actually doing the work and knowing the time it took. It's best to accept that estimates are near useless (unless you want to spend a lot of time basically doing waterfall to come up with requirements/design/etc...) and instead just try to find out how to chop up the work into smaller pieces that each deliver value and plan how the feature will be delivered. This way the team can be focused on actually getting value out the door instead of spending time doing a futile exercise (estimating).

The author did an AMA on Reddit where he answered a bunch of questions: https://redd.it/5azhtx

`await` will "block" the current method but the current calling method will continue executing unless that method calls await itself (and so on). You can perform whatever other work needs to happen that doesn't require on the data. It's just a matter of having the right architecture in place that doesn't just waits for the request to finish before doing additional work.

I really want to see how ASP.NET Core does in these tests.

It reminds me of how Mario flies in the Super Mario World ( http://www.mobygames.com/images/shots/l/218714-super-mario-w... ) where he bobs up and down.

This is really cool. It reminds me of OmniSharp which provides Intellisense to any IDE. It just runs as a background process listening on HTTP so adding intelligent autocompletion to a text editor is fairly easy. I like this approach a lot.

Looks great but the App Store link doesn't seem to work FYI

Will talented people be willing to give up their full time job for a job they may very likely get fired from?

Automattic does something interesting from what I've read. They have you work there as a trial for 1-2 months while keeping your full time job. This is probably pretty stressful but you get the ability to work with the candidate while not asking them to sacrifice their livelihood if things don't work out. Needless to say, it seems a lot of people don't get hired after the trial.

I would even expect some out of the box management APIs to help upgrade the microservice with low to zero downtime, feature toggles, etc... A lot of these get built into each app typically but when you're creating many different microservices, the overhead of creating a service needs to be as close to zero as possible.

It wasn't before the market crashed but it's been much cheaper to buy than to rent where I live at least.

You can close a branch and it will not show up as being active but you still have the info for every commit which is what makes history readable.

Not sure if it's a difference in location but where I live it would cost me more per month to rent a similar property than what I own. If I wanted to save, I'd have to rent a smaller place instead.

Also this is a problem with Git not GitFlow. In Mercurial, for example, every commit is attached to a branch so it's very easy to follow where the changes happened.

They only support both because most libraries still support older version of .NET

If they were to support only .NET 4.5 or higher, then you can just call any async method in a sync manner simply by doing httpClient.GetAsync(...).Result

async/await in C# is a beautiful thing.