My current stance with reviewing code is: It's not ok to make another human review the code you made with AI, if you used AI then you're the reviewer, so unless you come to me with a well defined question or decision to make, just merge it and take responsibility.
Obviously that could only work in a high trust environment, that why open source suffers so much with AI submissions.
I really dislike this idea of testing in go: only ever use an interface, never the real implementation + mockgen the mocks based on this interface + use the mocks to assert that a function is called, with exactly this parameters and in this exact order.
I find this types of tests incredibly coupled with the implementation, since any chance require you to chance your interfaces + mocks + tests, also very brittle and many times it ends up not even testing the thing that actually matters.
I try to make integration test whenever possible now, even if they are costly I find that the flexibility of being able to change my implementation and not break a thousand tests for no reason much better to work with.
The last batch of juniors we hired just completed 4 years in the company, which I would say is a pretty successful batch, but sadly we haven't hired juniors since.
Edit: I must qualify that this is for software developers only, we did hired juniors for things like data engineers, security, IT and such.
Implement the simplest thing that works, maybe even by hand at first, instead of adding the tool that does "the whole thing" when you don't need "the whole thing".
Eventually you might start adding more things to it because of needs you haven't anticipated, do it.
If you find yourself building the tool that does "the whole thing" but worse, then now you know that you could actually use the tool that does "the whole thing".
Did you waste time not using the tool right from the start? That's almost a filosofical question, now you know what you need, you had the chance to avoid it if it turned out you didn't, and maybe 9 times out of 10 you will be right.
As far as I know there is no way to do Promise like async in go, you HAVE to create a goroutine for each concurrent async task. If this is really the case then I believe the submition is valid.
But I do think that spawning a goroutine just to do a non-blocking task and get its return is kinda wasteful.
I think I tested very casually some time ago with Go maps and up to like one hundred items the linear search on array was faster than map lookup. Considering that many times when we use Maps for convenience they will have less than a hundred items this could be useful.
Unfortunately I don't have the results (or the test code) anymore, but it shouldn't be hard to do again (casually at least).
Not sure about this particular instance. LTT got a video taken down by community guidelines violation just the other day, and they are much bigger than Jeff.
Yes, I guess. I wouldn't be surprised to see "Jai inspired" languages coming out before Jai itself, since some of the ideas look pretty good.
> How does one even get the compiler and build programs ?
Don't know how seriously you're asking this, but I believe you can apply to use it and if Jon likes your credentials and what you want to try it on he might let you have the compiler for some version. Don't know why he won't just open source it and say it's a early version passive of change, but game development is not usually very open source friendly compared to web dev.
I don't know if there's ever been a language that was announced 10 years before its first closed beta. I don't even know if having a "closed beta" for a language is something that really happens.
So there's a lot that is different with Jai, it's more like a highly anticipated game than a language.
I was thinking about that just the other day, who it would be really cool if Go had compile time code execution. I think Jai is making that a very prominent feature of the language.
I remember a few years ago a very good engineer in our company shared a very similar article about hexagonal architecture in golang, and a lot of people started using it, including myself for some time.
Now he's not here anymore, and posts in his linkedin about simplicity and how people overcomplicate things in software so much. This shows me that you should be careful when taking advice from other engineers, they learn and move on from what was previously a "best practice", while you might get stuck thinking it's worthy it because "that one very good engineer said it was how it should be done".
It's been fun dealing with memory and C's weird design in this age of agentic coding.