Tragedy of commons.
2,241 karma · joined May 2, 2017
.NET/C# decompilers are widespread and generally work well (there is one built into Visual Studio nowdays, JetBrains have their own, there were a bunch of stand-alone tools too back in the the day).
https://wits.worldbank.org/trade/comtrade/en/country/CHN/yea...
The point about being explicitly part of the API stands, though.
When you work with exceptions, the key is to assume that every line can throw unless proven otherwise, which in practice means almost all lines of code can throw. Once you adopt that mental model, things get easier.
This .unwrap() sounds too easy for what it does, certainly much easier than having an entire try..catch block with an explicit panic. Full disclosure: I don't actually know Rust.
What do you mean?
Exceptions do not force panic at all. In most practical situations, an exception unhandled close to where it was thrown will eventually get logged. It's kind of a "local" panic, if you will, that will terminate the specific function, but the rest of the program will remain unaffected. For example, a web server might throw an exception while processing a specific HTTP request, but other HTTP requests are unaffected.
Throwing an exception does not necessarily mean that your program is suddenly in an unsupported state, and therefore does not require terminating the entire program.
Win32 is stable, supported and will stay supported forever, as various technologies built on top of it come and go. It is the API for the OS.
> Linux is even more important today, given the Steam Deck and Proton
Which uses Win32 under the hood!
There is a running joke that Win32 is the Linux's most stable API.
Assuming Parent <- Child ("<-" denotes inheritance):
- If Generic<Parent> <- Generic<Child>: it's covariant.
- If Generic<Parent> -> Generic<Child>: it's contravariant.
- Otherwise: it's invariant.
Or at least it's that straightforward in C#. Are there complications in Rust?
Source generators didn't exist in C# 10 years ago. You probably had something else in mind?
- Attributes can do a lot of magic that is not always obvious or well documented.
- ASP.NET pipeline.
- Source generators.
I love C#, but I have to admit we could have done with less “magic” in cases like these.
Well...if you implemented a relational DBMS server without using threads. To my knowledge, no such DBMS exists, so the distinction seems rather academic.
> Btw if you really want consistent multi reads, some DBMSes support setting a read timestamp, but the common ones don't.
Could you elaborate? I can't say I heard of that mechanism. Perhaps you are referring to something like Oracle flashback queries or SQL Server temporal tables?
Normally, I'd use MVCC-based "snapshot" transaction isolation for consistency between multiple queries, though they would need to be executed serially.
If some other transaction commits at just the wrong time, it could change the result of some of these queries but not all. The results would not be consistent with each other.
The solution is to disable Wake Timers.
That might actually not be such a bad thing, if it removes some of the pressure to think overly short-term from the company management.
So not quite “over a century” but getting close. :)
Now that I think of it, I did disable sleep and just use hibernate instead. I no longer remember why - perhaps I too had some issues. Maybe I was just annoyed by Windows restarting in the middle of a night and (c)losing my open applications whenever it wishes to update? Or did I disable Wake Timers for that? Sorry, my memory is a bit fuzzy.
As it is, hibernate works perfectly for me, is fast enough, and it never closes my applications behind my back.
OTOH, I had sleep issues with pretty much all PCs that I ever had (be it laptop or desktop), so maybe it was just inertia to always use hibernation instead. :)
As I write this, the fans are either completely stopped or so slow that I cannot hear them. The fans can get a little "whooshy" under load, but nothing out of line with other Windows laptops, as far as I can tell.
I'm running under Windows profile (not one of the ASUS-specific ones in Armory Crate). I also limit the battery to 60%, since I'm mostly using it plugged-in, with external monitor and keyboard. A month ago, I upgraded RAM to 40 GB and added another 4 TB SSD (and cleaned the fans in the process, so it's even quieter). I think I'll keep this machine for a few more years...
That being said, I did experience occasional cursor stuttering, but mostly when the machine is under load (typically during Visual Studio build).
In the last 10 years, 3D NAND memory has scaled 10x (in bits per unit area). So… maybe not the best analogy?
In my case that means using it as a rendering library and component composer, but not for managing state or side-effects.
ADO.NET is available both in the legacy Windows-only .NET Framework and in the new cross-platform .NET (previously known as .NET Core).
> In any case, it's just one framework; previous comment said "all major languages".
Well, you are not implementing a piece of code in "all major languages" - you can pick the one that fits the problem best.
> And it's useful to be able to abstract and compose over expressions and predicates and such, not just data values, which this still doesn't help with.
You can do that via LINQ - there is even special query-like syntax built right into C# for that that looks like this:
var companyNameQuery =
from cust in nw.Customers
where cust.City == "London"
select cust.CompanyName;
But anything non-trivial is much better done in SQL proper, IMO. Most of the time, at least for OLTP, you'll be using static SQL - that is you will not need to change the text of the SQL query, just parameters. But dynamic SQL is a thing and can be very useful on occasion - which is string concatenation with all the problems that might bring.
I don't really see a "problem" here. Having everything in the same repo is probably the easiest way to ensure that the client cannot go out of sync with the database. When making a release, create a Git tag and deploy both client and database from there.
But you must make sure you know which tag is deployed at each customer. We use naming conventions for that (the name of the customer is part of the Git tag name), or you could hold that mapping externally if necessary.
Once you have that, making a client-level hotfix for a specific customer is (relatively) easy - just branch from the customer's release tag, do the changes you need, run the tests, and there is high probability everything will work properly. Once you release the hotfix, you create another tag and remember that this tag is now installed at the customer, and so on...
If you make changes to the database, then of course you still need to have an upgrade procedure from one version of the database to another, but you can be confident that the client will never query the "wrong" database version. And since both old and new database structure are just SQL files under different Git tags, you can discover exactly what changed by just by diffing.
> What does Visual Studio do?
Visual Studio has a special SQL project type, where you can keep you base table definitions, as well as all the SQL code (stored procedures, functions, views, user-defined types, indexes etc.). You can group the SQL project together with client projects, tools, automated tests and benchmarks in the same "solution" (kind of a project-of-projects). When working on the product, you load that solution, and you have all dependencies in one place, right in the Solution Explorer. This eases navigation and minimizes dependencies whose source code you cannot (easily) see.
After you make your changes, you deploy to the local database (we use the free SQL Server Developer Edition, other databases have their own free editions), run/debug tests, run/debug clients as needed. You can even start debugging a C# test or client application and step into T-SQL stored procedure seamlessly, which can be a very powerful tool for ferreting-out difficult bugs. When you are done with your changes, commit to Git, let the CI double-check the tests and make the build for the the last-row-of-defense manual QA testing. Then deploy, associate the new Git tag to the customer, rinse-and-repeat...
Basically, we treat SQL like every other code, and manage SQL dependencies not fundamentally unlike any other dependencies.
SQL can be stored in version control just as well as any other code. This can include application-level queries as well as the DDL SQL which defines the actual structure of your database.
It's sad that tooling for this kind of workflow doesn't seem to be particularly good across the board, Visual Studio being somewhat of an exception.
ADO.NET has full support for table-valued parameters.
But what to do if you have a race condition in a database stored procedure? Or in a GUI rendering code? Even web applications can experience race conditions in spite of being "single-threaded", thanks to fetches and other asynchronous operations. I never heard of somebody using ICE in these cases, nor can I imagine how it could be used - please enlighten me if I'm missing something...
> You're changing the conditions that prevent accurate measurement without modification.
Yes, but if the race condition is course-enough, like it often is in above cases, adding print/logging may not change the timings enough to hide the race.