As a dev, if you use a private method, you've just taken ownership of the problem. I suggested to you in our contract not to do it, and that it would likely not be supported, and you did it anyway. Fix your shit, common software or not.
This is what an Apple engineer could write in the electron's github issue if they refused to fix it.
We're not discussing that, but that they have pushed an update without proper testing. You can see from the other comments that breakage is not limited to people using private methods.
I'm editing this to be nicer. I'm really trying to be nicer. Consider the possibility you're not the only one in the codebase and that the git history might provide the why to the code's what.
I do think commit messages should give some reference to what they're changing.
However, in more than a decade of software development, I don't think I've ever got much use out of commit messages. The only reason I'd even look at them is if git blame showed a specific commit introduced a bug, or made some confusing code. And normally the commit message has no relevant information - even if it's informative, it doesn't discuss the one line that I care about. Perhaps the only exception would be one line changes - perhaps a change which changes a single configuration value alongside a comment saying "Change X to n for y reason".
Comments can be a bit better - but they have the nasty habit of becoming stale.
> However, in more than a decade of software development, I don't think I've ever got much use out of commit messages.
> normally the commit message has no relevant information
Maybe that's why you've never got much use of them?
If your colleagues or yourself wrote better commits, they could have been of use.
An easily readable history is most important in open source projects, when ideally random people should be able to verify what changed easily.
But it can also be very useful in proprietary projects, for example to quickly find the reason of some code, or to facilitate future external security reviews (in the very rare case where they're performed).
> Consider the possibility you're not the only one in the codebase and that the git history might provide the why to the code's what.
I can't win with HN critics. If I talk about someone else looking, then I'm assuming. If I talk about myself, then I'm being too self-centered (in the oblique sense you reference). I am very aware of how this works across teams of people, not just myself, since I'm in industry.
If it includes merges commits, "fix" commits, commits that do more than one thing, detours, side-quests, unrelated refactors then squashing is 100x better.
As a reviewer, I don't care how you got to the end result. I want to see the final code. If you settled on something in your code that was unintuitive, because you tried simpler ideas that didn't work, then note that in a comment. Comments provide the info inline and don't require someone reviewing the code now or working on the code 15 years later to read your "commit story" to understand it.
I'd have written this exact comment two years ago. After two years using C# and .NET in anger, I'd pick it for almost any project. It's better than Python, Ruby, Go, Elixir, Typescript, Etc. and better than Rust unless you absolutely must squeeze every ounce of performance out of something, and even then, sometimes C# is better.
I know it's not cool, but I spend very little time on distracting stupid shit in C#. No other ecosystem does it as well as .NET. It seems like such a low bar, yet almost no one can get over it.
I sit down to program for what feels like 30 minutes in a moment of inspiration, and I look up and it's been 5 hours and I got more done than I was expecting. Every other language often has me dealing with some distraction having nothing to do with the actual problem I'm hoping to solve, and sometimes robbing me of the desire to solve the problem at all.
Other languages drive me to mess with my editor config, because it's more fun than trying to convince my environment that a business problem is more important to solve than why some dependency that was importing fine a week ago is now broken. Other languages have me trying to get AI to build me something I've built before without typing any code. C# wants me to ship something quickly that works and it wants to help me do it. It's a remarkable ecosystem, and it makes it really hard to put up with the hoops the others make me jump through. 5/5, would .NET again.
All that said, you .NET folks need to let your patterns die in a fire. Modern C# doesn't require any of this crap anymore. Use functions. They're great. The world of nouns is behind us.
Honestly, I could see myself writing this some time ago, but I somewhat disagree with it now. The problem isn't the patterns themselves, the problem is the overuse.
C# provides many tools to allow you to defer needing to apply patterns (which you should when possible) until they are actually necessary, such as extension methods. But some patterns can provide lots of utility and prescribed ways to approach problems that provide uniformity to large codebases.
Yeah, .NET developers have been passing CancellationTokens around in the places where they have needed them for 15 years. The tokens are basically invisible until their existence emerges when someone decides they want to cancel a long-running API call or something. At that point, they are plumbed as deeply as seems fit for the problem at hand and then hardly thought about ever again. CancellationTokens are generally a delightful pattern, especially when the language allows sensible defaults.
"It's not exactly making me feel valued as a community member"
Neither is not getting paid for work/services. If one works hard on things and can't pay their bills, that's unsustainable. Why is developer time worth nothing to other developers? If you can write it and host it, do it. If you can't, and the folks that can charge for it, hand over your credit card so they can continue to do it. Or watch it die when they have to abandon it to make a living writing code for someone that will pay for it I guess.
I do support many FOSS projects. Obviously I can't provide the kind of funding that element is looking for. And that's really where it rubs, none of us in the community can. It's their choice to position this as a massive enterprise level solution.
Can you actually buy that for a handful of seats? All the benefits they're touting apply only to massive installations. So it sounds to me that they wouldn't be interested in selling this to home users. They'll probably refer you to element one or the community version.
Yea I am also not that familiar with the different editions that are available and the whole ecosystem is confusing to me with matrix/element/dendrite/synapse etc.
I feel like though they would have some accessible paid plan for “smaller” users that want to support the development of the project long term - I believe this is the most sustainable way to build complex “big” FOSS projects - apart from having someone sacrifice themselves for the greater good I guess
Which seems to me they want to talk to purchasing departments, not end users. But let's pretend I'm trying to give them money anyway. No Buy/Sign Up link, the Get Started link in the top right and Get In Touch link on each price box lead to the same place: https://try.element.io/get-started?utm_source=pricing-busine...
Again, "consumers go away and use the free tier" or "learn more" about their enterprise offerings. Learn more brings you here: https://element.io/server-suite with a generic sales pitch and a "Get Started" link on the bottom.
Which sends you right back to the second page. So right now, apparently you can't pay Element money
So I'm not sure if Element has made an improvement to this page since, or it's a layout difference based on screen size, but on my windows tablet, the page was as described above, but on my Linux desktop, there is actually a lead generation form. Still a pretty onerous process that individuals are not going to do, which is clearly by design.
