jespino

This is good feedback, I'll going to incorporate it to the article, to make it more clear about the two paths there. Thanks.

In fact it generate single optimized exe files, but it does in multiple steps for multiple reasons, one of them is separation of concerns, but also, one of the main reasons is speed. The linker is linking (normally statically linking) different already build cached libraries, including the runtime. Without the linking ability, you would need to compile everything every time. Not only that, the linker has other responsibilities, like building some metadata that goes into the binary, for example the dynamic dispatch table.

Yes, there is some information that is written by the linker in the final data section of the binary, the itab, that is the interface table for the dynamic dispatching. AFAIK, it is done there because you need to know other packages structs and interfaces to have the whole picture and build that table, and that happens using the build cache.

One of the things that makes it work so well with agents is two facts. Go is a language that is focused on simplicity and also the gofmt and go coding style makes that almost all go code looks familiar, because everyone write the code with a very consistent style. That two things makes the experience pleasant and the work for the llm easier.

Yes, it is not specially different from other linkers. It has some tasks building the final binary including special sections in the binary, and is more aware about the specifics of the go language. But there is nothing that is extremely different from other linkers. The whole point of the series is to explain a real compiler, but in general, most of the parts of the go compiler are very widely used in other languages, like ssa, ast, escape analysis, inlining...

Misleading in what way? This is the linker part of a serie of posts about understanding the go compiler. I think there is no much space to be misleading.

Yes, is a font problem in some browser because we use SVG for the "IN BETA", we going to change it to a PNG.

Thanks for the feedback :)

Completely agree, I will add this User Story to our backlog, then all depends on priorities or our free-time interests :P

Thanks for the feedback

Completely agree, We add the issue, and we will fix it in the next upload. Thanks :)

Well, the video conferencing feature is a simple link to third party services (talky.io and appear.in) you can configure it on the admin interface of the project.

Anyway you can use talky.io and appear.in without taiga, they are great services!

The plan is integration by git hooks like close issues/task/us by commit message, but isn't planned a git browser of features like this.

Hi, is open source, is really easy to change the font (on your own instance).

The project have an API and the web (AngularJS) application, but anybody can build an application using the api like the web application, maybe an OSX native application. A native OSX client isn't in our road-map.

An example of this is the taiga-ncurses application for terminal lovers :)

The problem is in the taiga.io web, isn't it?

The problem is the animation on the top of the page.

But the application hasn't this problem.