ilasm is for manually writing IL-based programs in text format, a rather rare use-case. How is this related to LINQ?
It's related to MS contribution to .NET which is the subtopic of this particular thread.
Readit Newsmegadal commented on Net 9.0 LINQ Performance Improvements blog.ndepend.com/net-9-0-... · Posted by u/olvy0
Deleted Comment
megadal commented on Net 9.0 LINQ Performance Improvements blog.ndepend.com/net-9-0-... · Posted by u/olvy0
> It's cool but you can definitely do a similar thing in pretty much every high level language.
No. When it was release (circa 2007), very few mainstream languages embraced "Code as Data" the way C# did. In Java, there was no way to pass an expression (as an AST) to an SQL library. Which is why LINQ is so much more ergonomic than Hibernate. In C#, you could use language features you're already familiar with (such as "order.id > 100 && order.id < 200") in your queries, whereas Hibernate made you learn the framework's specific patterns (add Criteria etc etc, I don't recall now). Java just wasn't expressive enough for this.
In fact, you couldn't do this even today in a language like say Python or JS. I mean, not without running it through something like babel to get an AST, and having arbitrary rules on what's code and what's data. C# had this in the spec; based on whether it was IQueryable.
> Almost everything good that came out of .NET came from open source/non MS teams (like Mono).
My team adopted Mono very early - like in 2005. Your statement is not true at all. C# and the Framework was a very good spec irrespective of what Open Source / Mono did, and while Mono existing might have accelerated .Net's transition into Open Source, it would have happened anyway due to the definitive swing towards Open Source in the 2000s. Linq-to-SQL, Asp.Net MVC, EF etc didn't come out of Mono.
Have you ever read the source code for Microsoft's ilasm compared to Mono ilasm?
Anyway, EF is cool, but probably every .NET dev has an EF/LINQ performance related horror story (the generated queries are ridiculous).
A self compiling language is more impressive to me than ASP.NET MVC.
And C# is just lacking for what is actually capable in CIL bytecode. Or _was_ when I last used.
There have definitely been improvements, but in my opinion, they have just been kind of slow.
When I think of Microsoft's impact on .NET and it's culture, I think of stuff like SOAP, the SmtpClient, breaking changes in APIs every year and the technical debt left by it, the dogmatic fanboys, etc...
megadal commented on Net 9.0 LINQ Performance Improvements blog.ndepend.com/net-9-0-... · Posted by u/olvy0
If it were trivial you'd see LINQ-like providers implemented in "practically every high level language".
Source code of the function means you have to implement the parser/lexer to convert it into a usable AST which is bad for both runtime performance and library size.
Very much doubt this is available in Java, which Java ORM lets you use native Java language expression syntax to query a database?
I mean they kind of are. You can find a library in almost every language that transpiles source code ASTs.
They're just not core features.
In Haxe, it's extremely common :) but Haxe is just one other high level language.
Deleted Comment
megadal commented on Net 9.0 LINQ Performance Improvements blog.ndepend.com/net-9-0-... · Posted by u/olvy0
Wait what? Am I gonna include a source code parser and AST analyser to my JavaScript library for example, to examine the provided expression source and do this? This reads like the infamous Dropbox comment from when it first got released.
You could also bundle your JS. Or pretend like any number of other solutions like caching parsed ASTs exist instead of being as obtuse as possible, or something idk
megadal commented on Net 9.0 LINQ Performance Improvements blog.ndepend.com/net-9-0-... · Posted by u/olvy0
Takes a lot more than that, LINQ providers work by accepting a LINQ Expression Syntax tree instead of an opaque function, which allows providers to inspect and traverse the Expression's AST and translate it into the data source it's implementing.
This Expression AST is constructed by the compiler, not something that can be tacked on by a library later.
Yes, but I think the point is practically every high level language can already do this pretty trivially.
If it's scripted you can typically just get a string representation of the function.
If it's Java, JAR inspection/dynamics have been a thing for a long time. And in other languages, they usually directly support metaprogramming (like Rust) and plugging code into the compilation logic.
megadal commented on Net 9.0 LINQ Performance Improvements blog.ndepend.com/net-9-0-... · Posted by u/olvy0
LINQ is so fucking useful and well designed feature of .NET ecosystem that it is unreal when you gotta use lang which doesnt have such a thing.
C# design team is/was unparalleled
It's just an API for JIT, basically metaprogramming. It's cool but you can definitely do a similar thing in pretty much every high level language.
With scripting languages, it's all JIT :)
The C# teams progress on this has been slow. Keep in mind the CIL bytecode has had such capabilities for at least 20 years now and only in the past like decade are we seeing more features and optimizations around LINQ and System.Reflection.Emit.
Dynamics were extremely slow in C# and if you look at the CIL generated you see why. It's possible for example to use something like a Haxe anonymous types[1] to optimize Dynamics so that CallSite caching is way more performant.
I am pretty sure in C# the only way to accept an anonymous type is as a dynamic value, so even though the type of the structure is well-defined at compile-time, it will still rely heavily on runtime reflection/DLR with no additional caching beyond what DLR does for any other dynamic type.
Anyways, this leads to niche libraries being built for handling dynamic data like JSON performantly.
Which leads to annoying things like .NET libraries/apps being incompatible (without some adapter) if they use for example, different JSON libraries under the hood. (See [2]).
Problems like these (the lack of actually good JIT/dynamic code support) in my opinion significantly slow down the .NET ecosystems development, that's why it always feels like .NET is just catching up with features other popular languages have.
To be fair though, much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).
[1] - https://haxe.org/manual/types-anonymous-structure.html
[2] - https://learn.microsoft.com/en-us/dotnet/standard/serializat...
this completes the move from the server side to the client side
yes, it looks a little crazy and there are certainly serious security considerations (they support ACLs it looks like) but this is the logical end point of JavaScript-based applications that jettison the hypermedia infrastructure of the web
REST (so called, see[1]) was the first step, GraphQL the second step and now this completes the move of pushing the expressiveness found on the server side over to the client side.
[1] - https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
this comment further confirms my belief that GraphQL is a cult.
> this completes the move from the server side to the client side
OK, how does that benefit end users, developers, or administrators? I have never had a person approach me to make a website with a client side database.
> REST (so called, see[1]) was the first step, GraphQL the second step and now this completes the move of pushing the expressiveness found on the server side over to the client side.
Again, I don't see the point..? Who does this benefit..? Front-end only devs who want think doing everything on the front end makes a website more modern/app-like..?
Web architectures aren't separated in front end/back end because of technological limitations. We could've been running databases in the browser for decades now. We don't because of Separation of Concerns...
The front end is for presentation tier logic.. the backend is for business logic.
Just because you can do something doesn't mean you _should_, and when something has been possible for a long time but hasn't been done very often, you should ask yourself why that is.
> [1] - https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
How was this article at all relevant to your point..? GraphQL APIs in the wild also 9/10 require API docs (the schema).
Have you ever heard of OpenAPI?
Wait until you find out about JSON:API. Or that you can use OpenAPI with JSON:API.
> probably every .NET dev has an EF/LINQ performance related horror story (the generated queries are ridiculous)
> There have definitely been improvements, but in my opinion, they have just been kind of slow.
> much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).
Do you actively use .NET (any modern target in the last, say, 3-4 years or so)?
Because it was brought up as a subtopic in my original comment and someone quote responded directly to it.