He supported proposition 8 in California in 2008 (which passed). Some view that as unforgivable, and it's the main driving force behind all subsequent controversy about Eich.
My mistake, I was thinking of the wider ecosystem not the runtime, ie formatters, bundles and linters like Biome, oxc, etc being written in Rust or other compiled languages. That's where I saw the biggest speedup, because developers of them decided to use a compiled language to write them in instead of JS via a JS runtime where you'll inherently be limited by even a JIT language.
Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.
Do you only build stuff that performs financial operations? I'm not sure why sqlite being suboptimal for this one very specific use-case means that sqlite as a whole is a no-go for you.
No, not at all actually. But I had a lot of applications where at somepoint we needed to add storage of currency in the database. It became relevant for billing or other features. This without the app itself being financial in nature.
This and DATETIME. The workarounds for these are mostly fine if you’re just using SQLite as a key value store, but doing translations in SQL queries for these workarounds sounds atrocious.
90% of people aren't using "SQL" anyway. They are just doing basic CRUD operations on a data store with SQL syntax, usually abstracted through an ORM. The only reason they want a SQL database in the first place is for ACID.
If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.
Yeah, Linux definitely has corporate sponsors. This is not a good rule of thumb.
React is also now owned by the React Foundation, so I also don't see why it would be problematic to contribute to it now that it doesn't (seem to) belong to Facebook anymore.
I think the anti-corporate angle is a bit extreme as it would rule out a large number of projects that are widely used.
If the project is truly open source and widely used by the community it shouldn’t matter if it is or was associated with a corporation. Contributing to it helps the public who use that project too.
To a degree. But the corporate interest is spread across enough organisations that it's much harder for the Linux kernel to reject a patch solely because it's good for business, whereas a lot of corporate open source projects - even those with an OSI approved license - will actively refuse to merge code that competes with their commercial offering or simply isn't submitted by a customer. Hashicorp already operated like this long before they switched to BSL. Unfortunately having a project owned by a foundation isn't a good indicator either, because I know of at least one Apache project where the entire membership is one company, the CEO is the project chair and code is sometimes just dropped into repos in one huge commit.
Why is EF regarded as such a good ORM? I've encountered countless bugs in different repos related to its stateful nature after many years in .NET. Personally I found it completely illogical for my ORM to maintain state. I just want it to hold my schema and build queries.
Are you referring to the change tracker? FYI you can have it skip tracking as the default (or per query), but when you actually want to make changes you better opt in with `.AsTracking()`.
Anyway, I've used EF at work for about a decade and I'm happy with it. I surely have blind spots since I haven't used other ORMs in that time, but some things I like are:
- Convenient definition of schema.
- Nice handling of migrations.
- LINQ integration
- Decent and improving support for interceptors, type converters and other things to tailor it to our use cases.
What ORM do you prefer, and how does it differ by being stateless? How does saving look like, for example?
Dapper can be a better fit depending on the scenario. It's dumb objects. You fill them yourself with actual SQL statements. There is no change tracker. You are the change tracker.
The main issue with EF is ultimately there is an expression builder that maps linq expressions to sql. This mostly works, until it doesn't, or it does but has strange generated sql and performance. If all you are doing is CRUD or CRUD adjacent then it's fine. But for some complex stuff you spend a lot of time learning the innards of EF, logging generated statements, etc. It is time better spent writing good sql, which something like Dapper allows.
Fair enough. We use Dapper for a handful of performance-critical queries. But I wouldn't want to use it for the 99% where EF works well. Just like I wouldn't want to hand-roll assembly more than where it's really needed.
And it's not just about performance. LINQ plays well with the same static analysis tools as the rest of C#. You know, type checking, refactoring & co.
EF hits you in the face right at the start with the massive convenience that it provides. And then the paper cuts start adding up, and adding up, and adding up.
Although the EF team has made huge progress towards keeping your entities persistence-unaware, it's still not enough and eventually you wind up building your project in Entity Framework just as much as in C#.
Being forced to compromise your domain model. Yes the product has improved this greatly in recent years but it’s still inadequate IMO.
Fluent syntax can at first seem like the product has achieved persistence ignorance nirvana but then you have to compromise a little here, compromise a little there, until some point, if you’re still thinking critically about the design, you realize that you’re writing your app in Entity Framework as much as you are writing it in C#, as I mentioned.
Passing around a large mutable blob (dbcontext) which, if not managed with the utmost discipline by your dev team, can make it necessary to understand what large swaths of the code do before you can adequately understand what any small part of the code does.
Yes, european roads are not as wide, since they make place for proper sidewalks and bike lanes. Another advantage is that narrower roads make drivers drive more carefully and slowly, reducing accidents even further.
In Japan many neighborhood roads (even in cities) are narrow and have no sidewalk to speak of. But I feel safe walking down them because drivers expect to go slow and look out for pedestrians and cyclists.
If you want to blow through an area fast, there are other roads for that with lighted crossings and sidewalks, and often slower mixed-use parallel roads for pulling in and out of businesses.
I've no doubt it varies, but they're all doing something differently that seems to work versus the US.
> Other countries haven’t seen this increase in pedestrian deaths: in every other high-income country, rates are flat or declining. Whatever’s causing the problem seems to be limited to the US.
Then we shouldn't really be talking about the US, which has similar size and population stats, but instead individual cities and states. Denying that US states are correlated and European city construction are correlated is to ignore the history of how they were made.
Not in my experience. The road widths were set hundreds of years ago and the buildings have not changed. Walking around European and UK towns I find myself much closer to cars than walking around in the US. This is a factor in keeping car speed low, which likely affects how often and severe pedestrian collisions are.
I do agree that European roads are safer, but not because they have made large segregated sidewalks (which is what I disagree with as reality and the root cause).
On small village roads with little traffic you don't even need pavements (not to mention bike paths) as long as the road is narrow and winding with good visibility. Cars drive slowly and rarely, it's perfectly fine to walk there.
Not the same, since if you buy Bitcoin, you don't have partial ownership of the machines used to mine and also these machines being used for a singular purpose which you cannot change.
reply