It provides users with a means to make simple images quickly. It's robust, reliable, and familiar so I like it a lot.Paintbrush is the original simple paint program for macOS.
Program for mac to go through pictures code#
Super flexible run system, with surprisingly tight integration into other tools like docker-compose.Īll of this is going to sound familiar to people who use Code with vscode-go, but it just never breaks or chugs even with huge projects and files (except on M1 apparently lol).Powerful generation features for things like unit tests, godoc comments, and a big set default snippets that are easy to extend and personalize.Code is fine, but I've seen it choke on large projects or projects with weird Go Modules setups (lots of replace directives, etc) This is VSCode's biggest weakness in my experience. "IntelliSense" style features like Code-hopping navigation just work.Assisted refactoring is very powerful and flexible.Delve client is easier to configure and more fully featured than the one provided by the VSCode Go Plugin.
Program for mac to go through pictures full#
The tooling is incredibly robust and full of features. The level of polish and maturity in the built-in tools is what gets me. I think I'm going to wait for a 27" M1x-based (or similar) machine though. Tl dr: My personal dev machine is still an Intel-based iMac at the moment (I used a new Mac Mini for testing), but now that our entire stack is mostly arm64 compatible, I'm definitely going to switch soon, too. I also haven't found a decent solution for Tensorflow on arm64 yet alltogether, but it seems in this case we might just use pytorch instead, which seems to work fine on arm64 (For example huggingface/tokinizer uses rust) This has probably cost me more time so far than all the Go/Docker stuff even though only a tiny fraction of our Stack is in Python. Minor things here and there, missing compile dependencies, etc. This means everything needs to be built from sources for arm64. A lot of common packages only have wheels available for amd64. Python: This is probably the biggest pain-point for me so far.But from what I understand, native darwin/arm64 support for Docker is being worked on. If you use docker, sadly all of that is lost. If you do a lot of calculations, such as dot products (as is common in machine learning), native M1 performance is insanely good (in one test we had 100% higher throughput). I assume this is because the compiler can only optimize for "generic" arm64, but not use Apple's own SIMD instructions. This works fine on an M1 Mac, but it's not the same as compiling for darwin/arm64 and running without Docker. Docker performance: For now Docker mostly only supports linux/arm64 as a runtime.Some of our CI pipelines (on Travis) went from 10min to 60min because of the multi-arch feature. It will use QEMU emulation for the non-native architecture. You can build docker images for arm64 and you can even build for multiple architectures in one go using docker buildx build. For us only a single package could not be compiled and that was because of some minor mistakes that were easy to fix: We had some amd64-specific instructions in a file that didn't have the _amd64.go suffix, so the compiler tried to interpret them for arm64 as well. Compiling Golang: arm64 support is great in Golang.Most notably with regards to the following points: In the end it's not so bad, but it we definitely had to invest some time. I'm happy we did, because our users might face the same problems and I'd rather fix them before they discover them. So we were basically thrown into cold water and had to adapt. Recently a new employee joined and my colleague ordered a new MacBook for him - I forgot to mention that we might want to wait with buying M1-based Macbooks. My company develops an open-source app written in Golang and we distribute it using Docker images.
0 kommentar(er)
