Assembler refactor about bronzebeard

[theandrew168]

Alex,

This is great feedback and exactly the type of concerns that I want to hear about. The prospect of migrating Bronzebeard to Go was purely one of curiosity: would the project be any better off if it was written in Go? The language does work well for the web apps I've worked on recently and static typing is nice for code confidence. However, this project doesn't really suffer from performance issues or feature complexity. It is still a simple, single-file assembler with a low barrier to entry and is very easy to hack on.

I also appreciate your point of view on DFU (over USB-C) vs STM32 (over UART). While they have both worked for me personally, I don't have nearly as much experience with UART adapters as others do. Interacting with USB devices is much easier in Python and I've simplified the Windows workflow as much as I can (by bundling libusb.dll).

Given that the project is already cross-platform and meets its goals of being simple and effective, I think that it is better suited for Python. If the choice of language ever becomes an actual bottleneck / hindrance then maybe I'll reconsider. But without any obvious benefits beyond my own curiosity, it doesn't make much sense to proceed.

Thanks again for the honest feedback. I want to keep this project useful and approachable to as many programmers as possible.

[aw]

Hi Andrew,

The current python-based assembler works perfectly, particularly with the USB-C DFU. I intend to continue using that because the code is simple, small, auditable, and it "just works" (python/libusb are very common on any Linux system).

I personally dislike UART/usb serial interfaces. I own 3 different ones and they never work correctly or as intended. Given the choice, I'd much rather program a device over USB without dealing with an external serial adapter.

If Bronzebeard is something you interact with, and maintain daily, and you constantly find it painful dealing with the Python code, and have performance issues and difficulty adding new features, then perhaps a rewrite can be justified. From your explanations though, it seems like the coding process and final outcome would be a regression rather than an improvement. I don't really see the advantage even from a developer's perspective.

However, I think if you just want to write and maintain Go moving forward because you prefer Go, then that's fine and entirely your choice. Nobody is stopping you there.