One of the things I find most interesting about Go is that they have missed so much stuff out. So people coming from other languages tend to go through a period of wondering why it doesn't have x,y,z, which they were used to using. One example of this is inheritance, another generics, and finally things like dynamic creation of types based on a string (as lolly notes below). Generics may come later, the other two I doubt will ever be possible. There was a deliberate choice to dramatically limit the language in terms of syntax and capabilities, to the minimum necessary. So you won't find optional features put in just because someone might want it.
In the case of creating classes from a string, while a neat trick in Ruby this shouldn't be necessary - what did you want it for? You should find it very rare indeed to use an empty interface{}, I think on this website it is used for tests (not really required), and for creating rows from the db. If you can make the decision on a mapping at compile time it's fairly simple (see most Go routers for example). You shouldn't try to rewrite go by doing things like constructing a huge map of classnames to classes though. Rethink your code, not the language.
For packages, I found them one of the most intuitive and interesting parts of the language, and you should heed the warnings it gives you about structure if you find yourself fighting a separation, perhaps it was unnecessary, if a package becomes too large split it up. Generally till you know what you want I'd start with one main pkg and only split when you are sure functionality needs to live separately or might be reused (probably after you have written it the first time). The standard library is a great guide as to package structure in most cases. Re interfaces, you might find this article from Russ Cox interesting.
I definitely wouldn't look for ways to work around restrictions on inheritance etc, as then you're trying to recreate another language, and will end up frustrated and speaking in a pidgin - better to try to learn the idioms and patterns available in Go (culture is part of the language, as well as the syntax). Of course writing articles like this and questioning why things are done a certain way in Go or were left out is part of that process.
> In go, you can’t do something like "user".camelize.constantize.first. You can’t instantiate an instance of a struct while having it’s name as a string. The way this can be done is by maintaining a large map[string]interface{} with a name to struct instance mapping. I still haven’t found a good way to maintain such a map.
Please, don't do this.
It's interesting how much people try to import concepts from other languages they've used.
Author here. I know that this is a bad practice. But I think that it should be there and we avoid using it instead of not being able to do it at all. Or at least that's what I think.
Thanks for the article.
One of the things I find most interesting about Go is that they have missed so much stuff out. So people coming from other languages tend to go through a period of wondering why it doesn't have x,y,z, which they were used to using. One example of this is inheritance, another generics, and finally things like dynamic creation of types based on a string (as lolly notes below). Generics may come later, the other two I doubt will ever be possible. There was a deliberate choice to dramatically limit the language in terms of syntax and capabilities, to the minimum necessary. So you won't find optional features put in just because someone might want it.
In the case of creating classes from a string, while a neat trick in Ruby this shouldn't be necessary - what did you want it for? You should find it very rare indeed to use an empty interface{}, I think on this website it is used for tests (not really required), and for creating rows from the db. If you can make the decision on a mapping at compile time it's fairly simple (see most Go routers for example). You shouldn't try to rewrite go by doing things like constructing a huge map of classnames to classes though. Rethink your code, not the language.
For packages, I found them one of the most intuitive and interesting parts of the language, and you should heed the warnings it gives you about structure if you find yourself fighting a separation, perhaps it was unnecessary, if a package becomes too large split it up. Generally till you know what you want I'd start with one main pkg and only split when you are sure functionality needs to live separately or might be reused (probably after you have written it the first time). The standard library is a great guide as to package structure in most cases. Re interfaces, you might find this article from Russ Cox interesting.
I definitely wouldn't look for ways to work around restrictions on inheritance etc, as then you're trying to recreate another language, and will end up frustrated and speaking in a pidgin - better to try to learn the idioms and patterns available in Go (culture is part of the language, as well as the syntax). Of course writing articles like this and questioning why things are done a certain way in Go or were left out is part of that process.
> In go, you can’t do something like "user".camelize.constantize.first. You can’t instantiate an instance of a struct while having it’s name as a string. The way this can be done is by maintaining a large map[string]interface{} with a name to struct instance mapping. I still haven’t found a good way to maintain such a map.
Please, don't do this.
It's interesting how much people try to import concepts from other languages they've used.
Author here. I know that this is a bad practice. But I think that it should be there and we avoid using it instead of not being able to do it at all. Or at least that's what I think.