Solid reflection in rust

language design
45

It's pretty clear that you don't know what you are talking about and are just parroting things you've heard about reflection, JIT, etc. You really need to take a step back, consider that perhaps you don't know everything, and then spend a little more time understanding the difference between low-level targeting languages that do AOT and optimize aggressively at compile-time and dynamic languages that do on-the-fly re-compilation for "performance".

As far as reflection, JIT, etc. being necessary for so-called "Enterprise Frameworks", you are simply flat-out wrong. It's implemented that way in Java because that is the way Java was designed, not because it is necessary to do things that way. Really, the only reason Java is so ubiquitous is because Sun, early on, backed it aggressively and gave it away for free at the time that Microsoft had a de-facto monopoly on languages, development tools, and API's and Sun wanted to break that monopoly. They pumped in HUGE amounts of resources and provided a "Free(ish)" alternative. Because Sun had their own SPARC line of servers, they wanted something that could target all of Unixy systems, Mainframe-ish systems, and of course Windows and MAC (which at the time wasn't Unixy). So, they settled on a byte-code system that did not have JIT. This turned out to be entirely too non-performant, so they bolted on JIT to try to gain back sufficient performance to even be in the running (barely) to compete with AOT languages like C, C++, Pascal, Delphi, etc. Notice, that Java is not written in Java. It is written in C++. Most of the low-level things like graphics, sound, RNG, atomics, etc. are all implemented in C and/or C++ and the Java JDK just wraps those low-level things via JNI (effectively). Why do you think that might be?

Now, getting to this whole "Reflection" thing. What you want, in an AOT language, is something akin to COM/DCOM, not "Runtime Reflection" as Java does it. Actually, Java byte-code is more like MIR or RLIB of Rust. Both MIR and RLIB effectively have link-time reflection, which is what Java reflection is too. If one were to develop the ability of Rust binaries to dynamically, load, JIT compile, and link (including LTO/RGO), and couple it with a library to introspect the MIR and/or RLIB for type and function meta-data, you could have something better than what Java does with reflection/JIT. That being said, I don't think that you, or anyone else, has made a case why that would be something worth investing time in.

If you want it, you have 2 options:

  • Convince the people capable of creating the implementation of that idea that it is worthy of their time such that they will devote their precious time to implementing it.
  • -OR- you yourself educate yourself sufficiently so that you can implement it and spend your "valuable" time implementing it.

So far, your style of argument does little to accomplish the first, and based on your rather incoherent understanding of the issues, I doubt you could accomplish the second. Feel free to prove me wrong, but, I think you need to stop implying that everyone else is too stupid to understand your genius. It's not productive.

Please, again, see the X/Y problem. If you would spend more time explaining Y (what you'd like to accomplish), rather than stating that the solution must be X and insisting anyone who doesn't agree is less than competent, I think you might actually learn something. You do need to open your mind and engage others in a more constructive manner if you expect to ever understand things better.

Good luck with everything. I hope you find this helpful.

18 Likes
46

As a piece of anecdotal evidence: Spring XML is floating our boat in an "enterprise" environment right now. It's a ridiculous bit of technology but it works. Extremely well. I love it. I would feel short-handed without it. Should it perhaps be viewed as sloppy duck typing on top of rigorously typed Java? Or as a means of configuration?

Update: one way to view Spring XML is perhaps as a DSL for linking loosely coupled software components. DSL-s are handy once in a while. The fact it survived for so long means it's filling a real need.

I suppose a solution similar to Spring XML could be made to work "statically" (at compile time) in today's Rust.

It can probably be a useful mental exercise to try and figure out what language features missing today would enable a similar experience "dynamically" (without re-compilation, like in Java). First thing that comes to my mind is that not all traits are object-safe. "Dynamic" Java-style Spring XML would however pretty much require that the loosely-coupled components that it links together invoke each other via trait objects and trait objects only.

1 Like
47

Could everyone please take a second to breathe and a minute to read what they've written and double-check they're not being needlessly aggressive?

publicocean0 has come to us with an honest question. While they have a few difficulties communicating with the long-time members of this forum, too many of the answers offered in this thread have been (or can be understood as) inflammatory.

We're the Rust community, we're supposed to be friendly :slight_smile:

Maybe this thread should be stopped here and resumed somewhere else? Perhaps on the user's forum where members are a bit more accustomed to discussing with newcomers?

16 Likes
48

This whole thread could stand to be a lot kinder.

It's true that a lot of Rust developers and fans have pat answers for talking points like reflection. A lot of this stuff has already been heavily discussed, gone through proposals like the one in 2019, and been ultimately rejected or at least delayed. Just asking for reflection isn't going to cut it. If you want it to happen, you need to resolve the blockers that prevented the linked proposal from moving on in the first place,

But while this does explain the behavior of everyone who replied, it doesn't excuse it. Runtime introspection and reflection are not false desires; the fact that you can get by without them doesn't make them useless or inferior. The implication that @publicocean0 somehow doesn't know what they want is insulting. There are a broad class of features enabled by runtime bytecode generation and reflection that Rust can't do as well as Java can. There are ways around it, but there's still a reason why projects like Piston prefer to extend their Rust codebase using a language other than Rust.

This isn't a Q&A forum. We don't have to answer all of the OP's questions right away. Exploring reflection and code generation without knowing everything up-front is fine, as long as the proposer understands that it won't be implemented right away unless good use cases are found (and it doesn't break any promises, like memory safety, or zero-overhead).

12 Likes
49

It might be best to just close this thread and let the OP start a new one on a more conciliatory tone if they wish, AFTER they have researched the references that have been provided in this thread and AFTER they have considered the arguments in this thread made by experienced Rustaceans about how most or all of the features desired by the OP under the heading "reflection" are already achievable in Rust.

The new thread should link to this thread, at which point a moderator can counsel that everyone be chill in their responses.

13 Likes