If you know Go doesn't have what you need, then why did you use it?
Sometimes, a language isn't a good fit for what you're building, and you said that yourself, you don't write those programs very often.
And some other times, a language just isn't for you, it doesn't match the way you think about programming.
For example, I tried to learn Scala a lot and it just didn't work, so I stopped trying because there are better uses of my time than saying: "I wish language X had feature Y" or "I wish language A was more like language B"
If Elixir has what you need, then by all means use it. Nobody knew Python before Google started using it, didn't stop them from doing great things with it.
I think he answered why he used it pretty clearly in paragraph 3: because people in the Go community told him he had to use it for a bit to give it a fair shake.
Another way of saying it: he couldn't have known it didn't have what he needed until he tried it. So he tried it. Which I think is great. There are lots of thing we think we need that we don't, and lots of things that we never knew we needed until we tried them.
A language with everything would be a nightmare. To program efficiently you need a balance between capability and mental footprint. If I have to write large amounts of code to accomplish a task, that is bad for me and the eventual reader. If I use some feature so esoteric the read has to stop and research, or worse, misunderstands that is also a problem.
The Go promise is that they don't have some things, but you won't miss them. Some are deliberate omissions, some are deferred until they decide if they are required and can sanely be implemented. How those impact you is going to depend on what problems you are solving.
The danger is to end up wanting language casserole with bits and pieces from everywhere. It might be what you want, but by the time you union that with everyone else it is too big to know.
You don't go in saying "I need exceptions. I will use Go!" You start down the road saying, "I used to use exceptions, but in Go I will explicitly check all the errors." Only with experience can you look back and see what the cost was.
Comments
If you know Go doesn't have what you need, then why did you use it?
Sometimes, a language isn't a good fit for what you're building, and you said that yourself, you don't write those programs very often.
And some other times, a language just isn't for you, it doesn't match the way you think about programming.
For example, I tried to learn Scala a lot and it just didn't work, so I stopped trying because there are better uses of my time than saying: "I wish language X had feature Y" or "I wish language A was more like language B"
If Elixir has what you need, then by all means use it. Nobody knew Python before Google started using it, didn't stop them from doing great things with it.
I think he answered why he used it pretty clearly in paragraph 3: because people in the Go community told him he had to use it for a bit to give it a fair shake.
Another way of saying it: he couldn't have known it didn't have what he needed until he tried it. So he tried it. Which I think is great. There are lots of thing we think we need that we don't, and lots of things that we never knew we needed until we tried them.
A language with everything would be a nightmare. To program efficiently you need a balance between capability and mental footprint. If I have to write large amounts of code to accomplish a task, that is bad for me and the eventual reader. If I use some feature so esoteric the read has to stop and research, or worse, misunderstands that is also a problem.
The Go promise is that they don't have some things, but you won't miss them. Some are deliberate omissions, some are deferred until they decide if they are required and can sanely be implemented. How those impact you is going to depend on what problems you are solving.
The danger is to end up wanting language casserole with bits and pieces from everywhere. It might be what you want, but by the time you union that with everyone else it is too big to know.
You don't go in saying "I need exceptions. I will use Go!" You start down the road saying, "I used to use exceptions, but in Go I will explicitly check all the errors." Only with experience can you look back and see what the cost was.
A library for what you need - e.g. language features in library... but then that would be some form of lisp :)