Hacker News Reader

I remember reading about this in Java world a while back. To maintain safety you need to validate all the bytecode on load, so you can't really pre-cache it. Newer versions of Java use "class data sharing", but this only caches code after the local JVM has already validated it. Doesn't help with code files you've never seen before.

You could abandon validation and pre-compile but then running applications is no safer than c. You could modify the IR to do bad things like leak memory and crash VM.

JS has the same problem. Parsing and validating JS is a large part of page load times these days.

I'm not sure source generators will be the solution you hope for. Java has supported build time code generation for ages but everybody still reaches for reflection. A few popular libraries like MapStruct use build time generation instead of reflection, but again there's like 20 other popular libraries that do the same thing with reflection.

Java has attempted to fix the reflection hole with modules. You're supposed to pre-declare the classes you're reflecting in your assembly. But at current adoption rates its going to be another 20 years before you can count on all your dependencies using the module system correctly.

Trimming unused code is easy without reflection. Its been standard practice on Android for a long time. But every time I've tried to use it on servers I run into random crashes cause by runtime reflection and classloading.

Pretty unfortunate shortcomings to Java and C#. I don't think they'll ever be truly fixed unless somebody uses to nuclear option of disabling reflection completely

Disabling runtime reflections is key. Most of what it’s used for can be done compile time anyways. But more importantly reflection enables circumventing the type system and doing all sorts of unsound things.

As long as you have a compile time option I don’t thinks it’s nuclear, it just makes sense.

For Java's case the benefits of build time code generation are greatly exaggerated. In many cases, it is a lot faster and easier to generate code at runtime using MethodHandles then build-time code generation. For example, the toString/hashCode/equals methods of record types (that are being added with Java 14). Are all generated at runtime via indy (Invoke Dynamic) instead of generating the bytecode for them at compile-time.

> For example, the toString/hashCode/equals methods of record types (that are being added with Java 14). Are all generated at runtime via indy (Invoke Dynamic) instead of generating the bytecode for them at compile-time.

Didn't know that, interesting. I remember when invokeDynamic was added specifically to make VM conversion of dynamic languages easier, I guess JDK maintainers are somewhat guilty of the same laziness as the rest of us.

An aside, from reading about JVM targets of Haxe I learned that MethodHandles have truly terrible performance especially on Android.

I don't think the potential performance advantages of build time generation are overblown, just that everyone, even language designers, don't want to deal with the added complexity.

I could be wrong of course, but because of this I think the C# idea of generators will end up underutilized as well

CoreRT is definitely the most exciting project in the .Net stable. But there seems to be some people within MS who don't want to go in that direction - mostly for the reason that it won't be compatible with all of the existing code out there.

I just wish they'll see that most users would gladly trade some compatibility for smaller size and faster execution.

But you can’t go very far without serialization libraries these days. Would CoreRT be able to deal with that?

If it works anything like Mono AOT (used in Xamarin.iOS and Xamarin.Android) you can probably annotate parts of your code to be preserved.

A couple of days ago I found this though, it works using source generators and so it doesn't require reflection to work: https://github.com/TomaszRewak/C-sharp-stack-only-json-parse...

The new compile time code generation feature should largely eliminate the need for using runtime reflection, at least for serialization.

> so the JIT is going to be more of a legacy burden

I use Reflection, Reflection.Emit, and Linq.Expressions not just for serialization.

Building code in runtime from something else can be a win, especially performance but sometimes development time as well. That "something else" is not necessarily other code: https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/Tex...

You can replace code generation used for serialization with open delegates, and that should work without any special runtime magic:

https://github.com/naasking/HigherLogics.Google.Datastore/bl...

Constructors are the only odd duck for which there is no efficient alternative. You either generate a delegate at runtime to call the right constructor, or you have to use reflection/Activate.CreateInstance.

What's the reason you can't use AoT compilation together with serialization? The only thing that's problematic is reflection, but I wouldn't use reflection in my serialization if I can help it.

But I believe that’s what .net serialisers currently use.

Absolutely. But I apart from a very few trivial cases I wouldn’t recommend anyone to use any of the BLC serializers.

I am not going to enter into a debate about the merits of various serializers, but if netwonsoft.json doesn’t run, that’s half of the nuget packages that cannot run in that app. That pretty much guaranties its failure in term of adoption.

Yeah I didn’t even consider text based serialization (json, xml). I know there is at least a couple of aot-aware json.net ports but obviously those aren’t going to be what existing packages use. It seems like a pretty small hurdle though. Once AoT is commonplace more packages will support it, including json.net. It might take three years or ten, but it will happen (I consider 5 years to be a blink of an eye in this space...)

C# code still uses too much reflection (serialization, asp net routing, ORM, view model binding) to be statically compileable. They seem to be doing something against that with code generators

Reflection isn't an issue. CoreRT allows you to include the symbols for reflecting on though it does increase the filesize significantly.

The trouble comes in your dependencies when you don't know what they're reflecting upon or what features they're using that aren't supported.

This is exactly what newer versions of Java allow you to do. The problem is, nobody does it. I really like C# as a language, its better than Java in nearly every way. But this is a rare case where C# is implementing a feature Java has had for a very long time. And just like in Java, I don't think it will have the impact advertised.

The funny thing is that a lot of reflection is made necessary because of the lack of a preprocessor. Considering that everything old comes back after a few decades as a new innovation with a shiny new name I wouldn't be surprised if the preprocessor came back to support static compilation.

C# and Java are both guilty of this. I don't think generators will help nearly as much as hoped, because Java has the same problem even though it supports build time code generation through Annotation Processors for like over a decade, since Java 7 I think.

Reflection is just easier. Unless you go out of your way to use libraries that use code generation, Java is just as bad as C# in this regard.

There's a few bright spots, like MapStruct for object->object mappings and Dagger2 for dependency injection that are built entirely on code generation. But these are exceptions to the norm

> Pieces of our software get deployed over a satellite link so yeah, megabytes matter (and that's why I don't even dare to propose using .NET for those parts).

Megabytes are a one-time thing, unless your app is HUGE. Once you've deployed the runtime and dependencies, you can only redeploy your application DLLs.

> Once you've deployed the runtime and dependencies, you can only redeploy your application DLLs.

We looked into that but we can't run with an unpatched runtime. And servicing the runtime involves installing a huge package several times a year.

What kind of software are you developing that gets deployed over satellite links? Sounds interesting.

Don't want to go into much detail here but it involves ocean vessels.

I apologize if what I'm saying sounds obvious, but have you tried not sending whole binaries/archives, something like delta RPMs / pdiffs?

Have you looked at Delphi? Single executable, small size, multi platform if you want it, etc

And a license that's going to run you at 1700€ the first year and 440€ on renewal. It's spare change for a successful company but I have to wonder if it doesn't hamper adoption, especially when there's a seemingly obvious free and open source alternative like Lazarus + Free Pascal

Theres a free version of Delphi to https://www.embarcadero.com/products/delphi/starter/free-dow...

I'm writing a pretty serious app in FreePascal/Lazarus right now that's working out nicely. At some point, the Delphi cost may be justified, but not right now. Plus, the code injection macros in FPC (Delphi doesn't have) are addictive. I haven't tried on MacOS yet, but the transparent compile ability across Windows/Linux for desktop UI is pretty amazing.

Should probably look at them again - they were painful to get running last time I looked.

Edit: It seems the cross platform is still difficult? particularly iOS, at least compared to using Delphi for iOS

Have you looked at rust?

Yes, it's a nice language. The real advantage of Delphi though is the component library, its the real killer app of Delphi. I find object pascal a bit dated, but the VCL and firemonkey (cross platform component library) are things that make Delphi awesome.

I can see why most would not start a new project in Delphi, but in some regards it's really still unbeatable. Small, self-contained executables definitely is one.

I could see .NET supporting Rust before it supports Go given the recent announcements with Project Reunion.

.NET Native?