came here to say similar. GGP is another great example of hn people jumping in to make comments without having even a basic understanding of what they're talking about. Frustrating as it spreads misinfo about security which is the last thing we need.
> How hard would it be to automate these iterations?
The fact that we're no closer to doing this than we were when chatgpt launched suggests that it's really hard. If anything I think it's _the_ hard bit vs. building something that generates plausible text.
Solving this for the general case is imo a completely different problem to being able to generate plausible text in the general case.
I'm a committed Kotlin shill and a very experienced Gradle user but I'm the first to admit that it is absolutely arcane for those new to it. Once you know all the incantations it's really flexible and performant but good luck writing a plugin for the first time.
Very interesting. Bulk of my career has been writing Kotlin/Java and after a year of Go I am _still_ really struggling. Nice to know I'm not alone!
I see the benefits (I've have seen some absolute Java ee monstrosities that would be impossible to build in Go) but why am I getting paged at 3am because someone forgot to set a field on a struct. Similarly all the codegen to workaround the lack of inheritance - who cares how fast the compiler is if you've got to do 30s of codegen on top.
Strong, strong agree on this. That plus the verbosity really adds to the activation energy of getting things done. I reckon I end up writing (and having to read) 5x the lines of code for the same result that then ends up being less type safe and lacking null safety. I guess that's the price you pay for simplicity.
As a Java/Kotlin dev now writing Go for a living I agree with quite a bit in here and actually think both languages have things they could learn from the other.
Having said that I cannot understand where the idea that "the [Go] libraries and ecosystem are so much better" comes from. The average quality of both the JDK libs and the popular 3p libs (Jackson, Jooq, even ...Spring) are one of the things I miss most about writing for the JVM and I'm yet to come across another ecosystem that comes close.
Just posting an update to my original article. Should be useful for anyone who needs to get going fast with AWS on Terraform. Leave a comment/issue on the repo if anything's wrong or unclear.
Aimed at people looking to get started fast, I've written up my barebones multi-env AWS Terraform setup (with a working repo). It might not be the best way to do it but it's pretty close, DRY, easy to understand and aimed at people who want to build things quick on AWS with Terraform but want to bypass that initial 5 hour period where you try and figure out how it all fits together. Few tips about certs and DNS also thrown in.
All feedback useful, henry.course at gmail or get me on Github. Happy hacking.
Sorry, missed your reply to this. So this came out of the experience at my previous job where we were a big team working on a rapidly changing codebase and we reckon that resolving conflicts was taking anything from 5-10 engineer hours a week.
We tried quite a few processes to reduce it and they'd all work for a few weeks but inevitably we'd revert back to old behaviour pretty fast.
On your point about it being a procrastination tool, I'd love it if my team members took a minute to stop work and converse with the others if they're working on the same bit of code! Aside from time saved fixing a potential conflict it's probably indicative that a particular bit of the system needs to be refactored. Anything that can help guide the decision to refactor is probably a force for good but we'll see. H
Valid. I definitely need to get some concrete numbers on there as saying "it'll cost ya but who knows how much or when!" is rubbish. I can at least promise that for public repos it's free forever.
Interesting to hear you say that as I think you're right and making it more real-time is something I'm working on next. As you say, by the time the PR is up it's too late already but maybe a Slack/IDE notification the moment you create a conflict would be better.
I've spent the last few weeks building an MVP for my first ever publicly available project and I think it's time to get it out there.
tl;dr: If you're using Github and merge conflicts are slowing your team or project down, MM can stop them before they happen. It'll keep an eye on who's working on what and let you know if there's a potential clash brewing. Free forever for open source projects and hopefully some more useful features in the pipeline!
Any and all feedback welcome and thanks for reading.
Fully expecting 100 better tools for this job to appear in the comments but if one person finds it useful then that's a win. Comments/suggestions welcome.