|
|
|
|
|
by aelzeiny
1860 days ago
|
|
I aspire to be like the writer of this comment. Using the good parts of both languages to be a productivity machine. > The cons are mostly compile time and startup time. Startup time isn't very relevant for backend services. Compile times aren't great but not horrible either. I'd also throw in readability into the mix. Without knowing the magic it's hard to reason about. Then even by knowing what the magic does you have to have some intuition for its arbitrary rules based on its implementation in reflection-land. <rant>
Let's take an example: Autowiring. Java is the type of language heavily that pushes programmers to use the Strategy Design Pattern. It's almost the core of the language's philosophy. However, if I want a file that globally states to always use a specific Strategy then I have to turn away from native Java to the dark magic of dependency injection frameworks (Guice, Spring). If I'm reading such code, I have to know to look for a file that maps a Bean to a specific strategy; which is not apparent anywhere on either file. It's somewhere else in XML or a vague annotation that I have to now wrap my head around. To do so, I have to understand arbitrary limitations to the dark magic like whether this Bean is matched by name, type, or qualifier. All of this can be a little overwhelming at times when you're looking at a file where every variable is a Bean.
</rant> But if you drink the cool-aid, boy does it taste good. I can't start a new project without Guice (pun intended) now-a-days. |
|
In principle we could do the same in Java. The wiring code would contain the word `new` a lot though.