> we're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.
Cool. Can you tell us a bit more about the technical process of porting the TS code over to Go? Are you using any kind of automation or translation?
Personally, I've found Copilot to be surprisingly effective at translating Python code over to structurally similar Go code.
WASM code by itself can run at near C speeds, but where you are going to find the challenges is crossing the wasm <-> "rest of our app" divide.
You can call functions living in WASM with integer arguments and WASM can call functions you expose to it. You're host app has access to the WASM memory space though, and with those tools you have to craft your API. For a text editor there are going to be quite a few hoops to jump through and memory copying going on just to let a plugin read the document text.
Platforms like JVM, .Net, and nodejs/Electron have a huge advantage when doing extensions because they are can easily load code at runtime, and pass "platform native" data structures directly into extension code. Compilers exist for many languages which can target these platforms.
Count yourself lucky then. I've tried to work with TDD cult members and it was one of the worst experiences of my professional life. A good sign that people have moved into the cult is when they start saying that people who are not using TDD are "unprofessional" or produce "shit" code.
The standup is daily opportunity for the team together to coordinate itself and the its work. It is not a status update where the workers have to report to the boss. That is not what you should be doing.
> what if people are working on something for a bit longer than one day and got no news to tell or talk about?
They can just say that they are busy on it. But now the team can coordinate.
Maybe that feature is taking too long, and you should instead spend time on something more important.
Maybe Jerry says "hey, I'm finishing up on issue XYZ. Now I can go help you with that long task."
Maybe you are working on that long task, but hear that another team member has a problem which you know a lot about.
Maybe someone in the team is thinking of starting a new issue which is related to your long task, in which case some coordination may be needed.
Maybe someone thinks your long task is shouldn't be taking that long and they can afterwards help you out. It is easy to get stuff in a bog and not know it.
Scrum is meant to be a team sport where members are helping and supporting each other.