2,733 karma · joined April 30, 2011
I'm sorry, but even though I think D is a great language, there are plenty of usecases where D isn't a viable alternative to neither C or C++.
If D had all those missing features, or if you compared D to some other mainly-GC:ed, statically typed and compiled language, I think the syntax comparison would have been more fair.
In my eyes the problem isn't so much that the systems are overly invasive, it's more that the failure modes of automation aren't well understood or signalled and cannot always be remedied.
A close friend of mine was held in custody in the US based on false accusations by a police officer.
The police officer later admitted the false accusations to the judge, that he just wanted to "scare him a bit". The judge nodded, proceeded to aquit him of all offenses exept the speeding ticket which he deserved, and off he went.
While you initially might think that interfacing with the db is going to be very tedious and labor intensive, it usually turns out to not be that bad.
Battling the ORM to make it do what you want can on the other hand be very tedious.
When you have the SQL in the code it's much more obvious what the performance profile and potential concurrency problems are. That's very important to solve real problems which arise in almost all projects with some scale.
If I were to choose my tools, I would pick some sql-based schema versioning system, and potentially a simple data mapper for moving data back and forth between db records and entities.
But I would be very reluctant to use a full-blown ORM nowadays.
I think this is the most important question to solve if we want more equal outcome in worklife.
The results seem very useful when reasoning about coordination in programs, but I'm questioning how practically useful these results are when applied as methods.
In the GC example, for instance, you do need to find the garbage nodes. Any trivial way of re-formulating that search in a monotonic way would likely destroy performance. My guess is that it's no silver bullet to solving problems in distributed systems.
So I wouldn't be so quick to dismiss the idea of associating these concepts. After all, category theory is all about making that kind of associations.
But there are plenty of data types like smart pointers, where multiple copies of the original smart pointer points to the same underlying data.
In the eyes of the compiler, these are different variables, and can be manipulated independently.
When writing said smart pointer, however, Rust won't allow you to share data between copies unless you explicitly ask for disabling some of the compile checks. When you do this, you need to manually ensure (thread) safety. And this is where locks and other concurrency primitives generally come in handy.
When it comes to motivation, I usually pick my tasks in such a way that I don't exhaust myself. Typically, I would push a daunting task until I have a really good day and feel ready for a new challenge.