4 ms·

SQLite is pretty much the only remaining native dependency in my C# codebases, and as much as I love the engine, I wish that could go away. Replacing System.Da

SQLite is pretty much the only remaining native dependency in my C# codebases, and as much as I love the engine, I wish that could go away. Replacing System.Data.SQLite with Microsoft.Data.Sqlite already helped with Apple ARM builds (despite all the small differences that only showed up in actual use), but pretty much the only native debugging I do these days is related to the "batteries" -- the linked article outlines the general strategy pretty well. On the one hand, I feel bad about turning into a "pure-Java only" kind of developer (I mean, limiting yourself to H2, the horror...), but on the other hand, I'm increasingly starting to see their point. Oh, well, if AI actually works, I'm sure Microsoft.Native.Data.Sqlite is just around the corner (and, later edit, to prevent confusion: the abuse of 'Native' here is mostly making fun of Microsoft naming conventions -- they'd call it 'Interop' if it were like truly native).

mcraiha 1y ago
Would the WebAssembly version of SQLite be OK for you?
- ZeroConcerns 1y ago
  I haven't really kept up with the state of WebAssembly in .NET (mostly because I'm entirely uninterested in Blazor), but I don't think we're at a point yet where we can simply reference a .wasm file and invoke code in it regardless of the underlying platform, right? Until that is the case: no, not really.
pjmlp 1y ago
Exactly because of the benefits of this, there is the meme CGO is not Go, as any package with native dependencies kills the possibility to cross-compile with the Go toolchain. Same applies to the pain of using native dependencies in Perl, Python, Ruby,... Many .NET developers are only now slowly the pain of having so many dependencies to C++ DLLs, COM and C++/CLI. One of the reasons why we still do so many .NET Framework projects at my employer agency.
- andix 1y ago
  > One of the reasons why we still do so many .NET Framework projects at my employer agency. What's the issue with porting them to .net (core)? Most of that stuff is still supported, if you only have native windows DLLs you would still be constrained to windows only, but still better than staying on ancient .net framework.
  - stackskipton 1y ago
    If you are stuck on Windows and upgrade to Core requires more then 2 hours of dev time, it's likely not worth it. Core biggest feature is running on Linux. If you can't, who cares? Framework is not going anywhere. It will be supported till 2035 for now.
    - andix 1y ago
      No, linux support is not the only new feature. Read the change logs, it's thousands of huge improvements everywhere.
      - stackskipton 1y ago
        As someone who deals with this, Framework -> Core on Windows is small % performance improvement. Framework Windows -> Core on Linux is huge. Most of it coming from not Windows. Yes, there is other nice language features but obviously 15 years of Framework code base has probably put up guard rails around those sharp edges. My point still stands, I can't imagine most companies green lighting .Net Framework -> Core conversion if they can't switch to Linux. If you are stuck on Windows, you have probably developed all the tooling to deal with Windows so it's all sunk costs.
        bob1029 1y ago
        Linux was rarely part of the conversation when I was doing these conversions. Getting access to things like Kestrel (breaking out of IIS jail) is way more critical. Also, self contained deployments mean you can stop shipping magical blessed machine images around. It's not even about the performance. It's about having technology that doesn't actively hate you.
andix 1y ago
I guess you would need to switch to a dotnet native database, like litedb. Even if you would use postgres, there would be native code left, decoupled from the dotnet application though. It would be interesting though, if it's possible to run webassembly inside the CLR (dotnet runtime). But I don't really get the issue with native code inside a dotnet application. In the end everything you do in dotnet ends up being executed as native code. Even a simple console.writeline() is implemented in native code.
- ZeroConcerns 1y ago
  I've really tried to like LiteDB (mostly because it can use an IO.Stream as the database backing store, which enables lots of fun scenarios), but even light usage mostly resulted in data corruption and inconsistent result sets, something I've literally never seen with SQLite. Plus, I think the project is pretty much dead? And yes, of course everything ultimately runs as native code, but deployment is a major issue. As long as you only deploy IL (or, possibly at some point, WASM), you only need to worry about the relatively lightweight CLR (the dotnet executable and its direct dependencies) -- it does get a lot more complex once you go beyond that, unfortunately.

mcraiha 1y ago

Would the WebAssembly version of SQLite be OK for you?

ZeroConcerns 1y ago
I haven't really kept up with the state of WebAssembly in .NET (mostly because I'm entirely uninterested in Blazor), but I don't think we're at a point yet where we can simply reference a .wasm file and invoke code in it regardless of the underlying platform, right? Until that is the case: no, not really.

pjmlp 1y ago

Exactly because of the benefits of this, there is the meme CGO is not Go, as any package with native dependencies kills the possibility to cross-compile with the Go toolchain. Same applies to the pain of using native dependencies in Perl, Python, Ruby,... Many .NET developers are only now slowly the pain of having so many dependencies to C++ DLLs, COM and C++/CLI. One of the reasons why we still do so many .NET Framework projects at my employer agency.

andix 1y ago
> One of the reasons why we still do so many .NET Framework projects at my employer agency. What's the issue with porting them to .net (core)? Most of that stuff is still supported, if you only have native windows DLLs you would still be constrained to windows only, but still better than staying on ancient .net framework.
- stackskipton 1y ago
  If you are stuck on Windows and upgrade to Core requires more then 2 hours of dev time, it's likely not worth it. Core biggest feature is running on Linux. If you can't, who cares? Framework is not going anywhere. It will be supported till 2035 for now.
  - andix 1y ago
    No, linux support is not the only new feature. Read the change logs, it's thousands of huge improvements everywhere.
    - stackskipton 1y ago
      As someone who deals with this, Framework -> Core on Windows is small % performance improvement. Framework Windows -> Core on Linux is huge. Most of it coming from not Windows. Yes, there is other nice language features but obviously 15 years of Framework code base has probably put up guard rails around those sharp edges. My point still stands, I can't imagine most companies green lighting .Net Framework -> Core conversion if they can't switch to Linux. If you are stuck on Windows, you have probably developed all the tooling to deal with Windows so it's all sunk costs.
      - bob1029 1y ago
        Linux was rarely part of the conversation when I was doing these conversions. Getting access to things like Kestrel (breaking out of IIS jail) is way more critical. Also, self contained deployments mean you can stop shipping magical blessed machine images around. It's not even about the performance. It's about having technology that doesn't actively hate you.

andix 1y ago

I guess you would need to switch to a dotnet native database, like litedb. Even if you would use postgres, there would be native code left, decoupled from the dotnet application though. It would be interesting though, if it's possible to run webassembly inside the CLR (dotnet runtime). But I don't really get the issue with native code inside a dotnet application. In the end everything you do in dotnet ends up being executed as native code. Even a simple console.writeline() is implemented in native code.

ZeroConcerns 1y ago
I've really tried to like LiteDB (mostly because it can use an IO.Stream as the database backing store, which enables lots of fun scenarios), but even light usage mostly resulted in data corruption and inconsistent result sets, something I've literally never seen with SQLite. Plus, I think the project is pretty much dead? And yes, of course everything ultimately runs as native code, but deployment is a major issue. As long as you only deploy IL (or, possibly at some point, WASM), you only need to worry about the relatively lightweight CLR (the dotnet executable and its direct dependencies) -- it does get a lot more complex once you go beyond that, unfortunately.