Thanks for the easy to follow getting started for Golang.
I did find an error in the first blog post when following the steps on a Mac.
You have the command cd $HOME/go && mkdir test - This creates the new directory, but does not place the developer in the "test" directory which means those following along will likely create test.go in the "go" directory and not the test dir which is where you need to be in order to follow the rest of the steps as written.
One of the big go gotchas is redeclaring a variable within a loop when using go routines/errgroups (https://github.com/golang/go/discussions/56010 / A decade of experience shows the cost of the current semantics).
Didn't seem to find it, but that's always a fun one.
Another good tip to reduce binary size is to check if all the imports used are really needed. Just using a constant from a package also pulls in all its code. It would be great if Go could do some link time optimization to remove all unused parts of packages during compilation.
It may be worth noting that HEIF supports some features not available in JPEG, such as transparency or 10-bit color support. Therefore, the conversion may be even more lossy than just re-encoding the image data.
This talk by Yehonathan Sharvit is about the principles of Data-Oriented programming and how to reduce the complexity of software. As the talk is not focused on Go, the video is an interactive session between our speaker and the #gofrm community.
Data-Oriented programming is a paradigm that aims at reducing the complexity of software systems and making the development experience more productive. Data-Oriented programming draws a clear separation between code and data. It treats data as a value that is manipulated by general-purpose functions. In this talk, we illustrate the principles of Data-Oriented programming in the context of a software production system. After attending this talk, you will be able to apply Data-Oriented programming principles in your preferred programming language, whether it's Object-Oriented or Functional, and reduce the complexity of the systems you build.
iPrism Technologies is a global technology and process driven software, web and mobile app development company offering customer centric solutions with knowledge and experience of the entire IT lifecycle, we help enterprises streamline core IT processes and augment their competitive advantage.
Not sure I agree with most of this, but it's interesting to see another's approach to dealing with complexity.
The article correctly identifies complexity as the biggest problem with writing complex long-lived web applications, but then presents a series of ad-hoc solutions to specific problems (problems caused by the structure they have chosen) as the best answer. It would probably be better titled 'Things I learned writing go' or something similar, rather than attempting to frame different decisions trade/offs as anti-patterns.
To take one example, having one user model is good in that it is easier to maintain and less complex to think about, but the author advocates having a write model and an api model - in some circumstances that might be useful (where there are many private fields which must never leak to the view or require processing before presentation), but most of the time it's overkill and needless complexity.
Yes and written by some of the people involved in the original net package. Brad used to be one of the maintainers of net/http and net packages in go. I'm glad they are so conservative about changing the standard library though, even if it does mean warts like this persist.