Dependency controls have improved quite a bit. They went through a couple of variations of this and the current solution is nice.
I haven't ever run into an issue with artifact hand off to this point though. Maybe it's one of the more rare concerns, but it's not something I've experienced (fortunately). I imagine it would be a concern to debug though.
Nonetheless I have run into the diamond dependency problem in practice. Their solution is unprincipled and there's no way to turn off the default behavior.
While the article highlights interface upgrades, it overlooks potential downsides like increased complexity in debugging. Anyone experienced issues with this?
It's not going to be solved. Stop saying this. It's a great step forward and a real user experience improvement, but it doesn't solve it.
Packages need to precompile, and they don't. They need to fix invalidations, and they don't. They need to fix inference issues in their packages and they don't. "Using" time remains quite high.
How they handle multiple monitors is a choice and the memory leaking is a design decision as is the lack of addon api and a system where any crashing addon takes out the whole session.
I'm referring to cases where you have to use unowned, etc, to break reference cycles. The larger the application the harder it is to find these issues.
It's odd to complain about the first run not working, when the first run is significantly earlier. I'd also say the interactivity of Pry and binding.pry more than compensates for anything lost by not having a compilation step.
Nah. I have had to deal with memory issues in 3rd-party dependencies, so I'm not saying it never happens. I'm just saying I have much bigger problems in other areas that are mostly unaffected by "better" languages.
I saw some posts on the mailing list where their position wasn't that it isn't a problem, but that no obviously-right solution is yet known, so it's better to let it shake out in third-party land for now, which seems reasonable. (That's all from memory, so salt appropriately.)
FWIW, I have been using godeps and it seems nice so far. I'd definitely recommend taking a look.
This still happens, but the surface area is greatly reduced to figuring out that the directory, variables, credentials, dependencies between stages, etc. are set up correctly
Sure, none of that is in doubt. But in my experience the performance cost of hot code getting deopted is so massive as to overwhelm virtually any other factor, so realistically, fixing the deopt is what solved TFA's problem. Of course getting rid of the switch statements was presumably an additional speedup, but since TFA doesn't compare those cases I guess that's neither here nor there.
I worked on a farm. I think the things you're bringing up are still subtlely different. Modifying something you can see and touch for some unintended purpose versus modifying some piece of software because it doesn't work are miles apart from each other.
For example, I have a graphics project where screen tearing suddenly started appearing although my code didn't change, and the tearing wasn't there before. Is the issue in Skia, OpenGL, the graphics driver, the Intel or NVidia GPU, or the OS? Or is it some latent issue in my code that started showing up because of a change in these dependencies? Or is it some other complex interaction between multiple dependencies? I couldn't possibly know, and I actually don't think there is anybody that actually knows. And there is zero chance I could ever figure it out. I mean, it at least appears it was a driver issue as after some updates and a reboot it just went away, but there is zero insight into why or what actually made it go away.
If I modify a plow because some part as originally designed was flaky and constantly broke, you usually know to a pretty good degree why your fix works.
In software, the abstractions are such that it is practically impossible atbtimes to understand.
Part of the problem is that it overrides extremely low-level things like cd. That can get in your way pretty badly if there's a bug, or just a feature you don't understand.
I was talking about the applications I personally use frequently, like Slack for example. Unlike the parent said that "this becomes a frequent issue in any app at scale", I just don't see this happening on the UI's I personally use.
Having said that: they key-optimization thing will be implemented. The more frequent issues get a higher priority. Maybe it's this one.
I'd chalk this up to dependency management and resolution being a hard problem.
Ruby's bundler had these exact same issues 5 or so years ago. I remember attending a talk by on Bundler run by it's core devs and asking about how they make dep resolution faster. Turns out that it was never really a solved problem there either, Bundler just uses a bunch of heuristics to avoid cases like the 18 minute `Pipefile.lock` described above.
On the topic of leaking HANDLEs, Synergy/Barrier's service leaks zombie processes and causes systems to malfunction over time, and this hasn't been fixed in years.
I haven't ever run into an issue with artifact hand off to this point though. Maybe it's one of the more rare concerns, but it's not something I've experienced (fortunately). I imagine it would be a concern to debug though.
reply