megadal

Joined 2 years ago

Karma

137

Submissions

103

Member since

Apr 21

View on Hacker News

Recent submissions

Comment · 2 years ago

> I don't see how it is related is relevant to this discussion.

Because it was brought up as a subtopic in my original comment and someone quote responded directly to it.

Comment · 2 years ago

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...

Comment · 2 years ago

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.

Comment · 2 years ago

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

Comment · 2 years ago

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.

Comment · 2 years ago

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...

Comment · 2 years ago

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.

Comment · 2 years ago

What BIM formats does it support?

Comment · 2 years ago

Of the 3 big US based clouds, Azure was the worst I dealt with. AWS comes close second to worst. GCP is the best UX but pricing is probably comparably crazy.

Azures biggest issue is it inherits most of the same technical debt most Microsoft products suffer from. It's slow, glitchy, and at times unforgiving. Also I find I often have to have the network tab open as errors aren't reported to the UI. They just happen and stuff hangs.

I really wonder how despite all of this, they still get business... It's been a demonstrably terrible Cloud from the start. Even Equifax avoided Azure during their lift and shift, which is surprising given a lot of their stack is super legacy Microsoft tech... I guess they learned their lesson.

Comment · 2 years ago

The title: "bug exposed up to 255 bytes of server heap and existed since 2011"

The post: "Silently sends up to 255 bytes of the client’s heap to the server."

Comment · 2 years ago

I could be wrong but I think a good way to have an edge is pricing. Email is generally a low bandwidth service with lots of cold storage, yet for most personal email services the price doesn't seem to reflect this.

Like for example Google One is $2/100GB and $10 for 2TB yet you can definitely get storage much cheaper than this, and bandwidth is close to, if not free on bare metal clouds.

I've been considering this myself. That or some IRCv3 offering.

If you go the commercial route you'll almost certainly end up building an ERP/CRM, as it's what a lot of companies seem want: a personalized ERP/CRM (not sure why, though it does kind of feels like just outsourcing an IT dept whenever this has come up in the past)

Comment · 2 years ago

So then your argument isn't that GraphQL is better than REST. It's that you need something specifically designed for graph based data access to handle graph based data access.

Which a REST API can do.

This argument is quite a goalpost shift from your original point: that it is easier to implement authz/access control in GraphQL than for a REST API.

An API to generate PDFs is not comparable to GraphQL, because it's not a Graph based data access API...

You're so disingenuous and unserious it's insane. This is why people hate GraphQL and it's devs: 100% of your talking points are non-sequitur copy paste arguments. It doesn't matter how much context is provided to prove what you're saying is nonsense — you'll just bulldoze right along with said nonsense anyways. It's like I'm talking with a zombie.

For the purpose of accountability I'm pointing out that so far you've:

- made an invalid comparison

- tried to elaborate on that comparison only to make several other logical errors

- goal post shifted to a totally different point than your original point after being called out

you've already pointed out that you have zero experience with JSON:API and that you can't come up with anything good to compare GraphQL with sort of demonstrates that your reasoning behind using it is not based on anything other than marketing as you have never actually used an alternative to GraphQL... Everything you've said I've only ever seen in GraphQL promo material.

So basically you got shilled and turned into a shiller.