6 ms·
Is there a reason to prevent concurrent reads? Seems rather .. Silly considering the db should handle all that stuff. Also, one thing I'm still waiting for is
by dastx 6y ago
Is there a reason to prevent concurrent reads? Seems rather .. Silly considering the db should handle all that stuff.
Also, one thing I'm still waiting for is a decent non-complex di that works using go generate. I'm aware of google's wire (?) But I've looked at it multiple times and I still struggle to understand it.
- throwaway894345 6y agoI've never understood the value proposition of a DI framework. Why would I want one when I can initialize my objects in main()? Is XML or JSON or whatever really that much more pleasant than wiring together Go objects?
- orisho 6y agoI'm with you on this. Dependency injection seems to me to replicate some of the features of interfaces while introducing complexity because the injection is indirect -- instead of having code that initializes a different object, it all happens dynamically during runtime using reflection. An antipattern as far as I'm concerned. It seems to achieve little or no gain at a very high cost.
- throwaway894345 6y agoIt sounds like people just want a little bit of dynamic typing to assemble their object graph or something, but that's such a small (possibly negative) value add for such a steep price (everyone who might touch this software--new team members, system administrators, whoever takes over maintenance, etc--now needs to know the DI framework for even the most basic troubleshooting).
- isbvhodnvemrwvn 6y agoIt doesn't have to happen at runtime. For instance in Java you have annotation processors which generate the boilerplate for you (in DI space I'm only aware of Dagger 2 that does it). It's a bit inconvenient but you can easily audit what's going on. That being said I somehow doubt a similar tool is used with go.
- specialist 6y agoMe three. DI and IoC are for people ignorant of or hostile towards composition. Further, aspects and reflection are for those unwilling or unable to make reasonable architectural assumptions. Said another way, meta programming is for personal projects. And maybe for small, disciplined, high trust teams. Most devs are average (axiomatically) and most projects are CRUD or scraping. So choice of these tools is self soothing to mitigate inferiority complexes. Like Mensa.
- throwaway894345 6y ago> DI and IoC are for people ignorant of or hostile towards composition. This isn't helped by the messy terminology. "Dependency Injection" is literally another term for "composition", but dependency injection frameworks imply automating the composition of one's object graph. However, people who like these frameworks don't seem to be aware that they can more easily compose their object graph using the structures available in most general purpose languages (literals for lists, maps, structs, etc as well as function calls and so on). Arguably there's some repetition in constructing an object graph (initializing a list of objects that vary only slightly) that one might want to DRY up, but we already know how to do that with helper functions in host languages, and anyway this is just boilerplate--it's almost certainly not where your bugs are, and it's not where your developers are spending their time. A framework introduces a bunch of complexity at the top level (near main()) i.e., the stuff that everyone from developers to testers to operators/sysadmins will probably need to dig into at some point, and all that for no material advantage to anyone.
- specialist 6y agoAgree on all points. VRML-97 is the near pinnacle of human achievement, for declaring scene graphs, a special use case of object graphs. It had reuse. It had patch cords (specify non parent-child relations). It only lacked path expressions. I really I wish I could tell younger me to publish my own VMRL successor, way back when. Young me forfeited when confronted by XML's JavaScript-like metastasis, which had overwhelmed all rationale human endeavors. Then maybe I could have spared humanity the indignity of JSON and kin. Had I only known that all bouts of irrational exuberance eventually implode...
- permille42 6y agoThe purpose of DI is to allow the use of a DSL to instantiate and connect objects, with configuration for those objects embedded into the DSL so that the setup and the way things work can be changed quickly without altering code. Mocking objects for testing purposes and swapping them for the real objects is also something commonly done that is helpful. There is no "real" DI for Golang as far as I've seen. The only DI I've seen that effectively do the sort of thing I am describing are for Java.
- lostcolony 6y agoBy DSL...you mean XML/JSON? Because that's literally the only thing I've ever seen used for DI purposes. And then invariably there's still just two versions of any given injectable interface; the one used in production, and the one used in testing.
- jolux 6y agoDI is a decoupling technique. You might only have two interfaces to begin with, but the rough idea is that writing to interfaces and using IoC allows you to make many changes by adding code without having to change old code.
- sagichmal 6y agoSure, but you don't need a framework or DSL for this in Go.
- virmundi 6y agoI don't need them in Java or Typescript. The benefit is that I don't have to write these boring, but necessary pieces. As applications grow larger, especially with Go's desire to have an interface with only one method/function, DI requires a lot of boilerplate. If there was a DI for go that used generate, then I would have compile time checking of dependencies. This would satisfy the community's sense of purity while satisfying my sense of annoyance at having to write this same process for every project.
- sbergot 6y agoYou can initialize your object with main. But if you are reusing some implementation in multiple object you will start to repeat yourself a lot in the initialization. A DI framework allows you to set conventions to avoid repeating yourself in the initialization phase. (ie if a class requires a parameter 'foo', look for a class named 'FooImpl').
- valenterry 6y agoCould you give a more concrete example? How would you "repeat" yourself?
- throwaway894345 6y agoI guess this makes sense, but DRYing up my object graph assembly doesn’t seem particularly important, and when it gets excessive I’d just create helper functions. This way everyone who touches my code (including the poor souls who operate it downstream) don’t need to understand my DI framework (how the DSL files are loaded and mapped onto code) for even the slightest debugging.