The language is very opinionated on how to implement things - for example, reading a file or running a web server. There's only one way to do this in Go.
But Go is very un-opionionated when it comes to your code layout and project structure: There is no "default structure", you can create packages as you want, you create files as you want, you can place multiple types and functions within a single file, you can define interfaces inside the package that uses the interface or inside the package that provides the concrete implementation of the interface...
It just takes a time to figure out how to properly structure the code. Go is very liberal in this concern and each project should use a structure that fits best.
In other languages, say, Java, you'd create a file Order.java for your Order class. There's no such convention in Go. You can create a file called order.go containing an Order type, but other types, constants and functions may also be in that file. Go simply doesn't have any restrictions regarding the code structure, and that allows for the best-fitting solution for your use case on the one side but also many possibilities each with their own pros and cons on the other side.
I was more curious about why the leadership is opinionated about error handling, but isn't as opinionated about module conventions.
I understand that in both functional and procedure languages, there is a much larger degree of freedom in how you group together items inside of modules. I haven't done a lot of c programming, but I assume it has very well established patterns for organizing modules by now.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The language is very opinionated on how to implement things - for example, reading a file or running a web server. There's only one way to do this in Go.
But Go is very un-opionionated when it comes to your code layout and project structure: There is no "default structure", you can create packages as you want, you create files as you want, you can place multiple types and functions within a single file, you can define interfaces inside the package that uses the interface or inside the package that provides the concrete implementation of the interface...
It just takes a time to figure out how to properly structure the code. Go is very liberal in this concern and each project should use a structure that fits best.
Why is it unopinionated on how to organize types and functions within modules?
In other languages, say, Java, you'd create a file
Order.javafor yourOrderclass. There's no such convention in Go. You can create a file calledorder.gocontaining anOrdertype, but other types, constants and functions may also be in that file. Go simply doesn't have any restrictions regarding the code structure, and that allows for the best-fitting solution for your use case on the one side but also many possibilities each with their own pros and cons on the other side.Thanks.
I was more curious about why the leadership is opinionated about error handling, but isn't as opinionated about module conventions.
I understand that in both functional and procedure languages, there is a much larger degree of freedom in how you group together items inside of modules. I haven't done a lot of c programming, but I assume it has very well established patterns for organizing modules by now.