Comment by Willamin
8 years ago
The two caste hierarchy is my biggest issue with Golang. Macro capability exists in Golang, but only for the upper caste of language creators. It makes me feel like the language creators of Golang purposefully decide that users of the language aren’t smart.
Rob Pike, in his own words, claims that programmers at google are "not capable of understanding a brilliant language", and that this is the reason why Go is designed the way it is.
The full quote:
> The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
-- Rob Pike, 2014, at ~20m50s of https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr...
That's been my experience at Microsoft. I'd love to start a new project there in F#. And I think the kids there would eventually grasp it and create better code. They're certainly smart enough. But it would take a while to unlearn OOP. My first year or two of F# code was complete crap. So given average tenure of a fresh grad bigcorp employee is a couple of years, it would not be worth it. I think this is a good decision though an unfortunate reality by Rob Pike.
A solution might be to change the hiring process to test FP concepts instead of OO, or to use a lisp- so users do not need to learn a complex type system in addition to FP.
2 replies →
I think it would be easy enough for the go compiler to support macros, while keeping them disabled by default. There could be a cli flag for go build that enables macros. It would be easy to have a company-wide rule to keep macros disabled. It would be trivial to prevent code with macros from passing CI if that was one of your organizational requirements.
It's not a comment on a users intelligence. It is instead a recognition that not all users value the same things. Therefore it is helpful for consistency and the writing of robust maintainable code that Go be opinionated at the language level. You don't have agree to with them but they made their choices informed by their years of writing large complicated codebases and they enforce those decisions at the language level. They have no wish to allow someone else to subvert those decisions since it would be counter to the goal of the language.
You as a user can choose to live with those decisions or use a language that gives you more freedom. All such decisions come with a series of tradeoffs. Just make sure you are making the decision in as informed a way as you can.
You might be interested in trying out Nim. It's a language that empowers the user, giving access to AST macros, compile-time function execution and generics.
I would say that using Nim's metaprogramming capabilities to create a great SPA framework is a better direction than creating a brand new language.
My only gripe with Nim is, as usual with non-mainstream languages, lack of libraries and frameworks (and lack of polish in the ones that exist, like Jester). The language itself is good and it's still evolving, so it has a chance of getting even better.
BTW: I've read your book, great job! The "Advanced concepts" part was a bit too short (I'd gladly trade some of the earlier chapters for more examples of both FFI and metaprogramming), but I generally enjoyed the book.
Also, I like how the code listings are annotated - how did you generate them? Is there some software specifically for this, or did you have to position all the arrows and lines and text manually?
> My only gripe with Nim is, as usual with non-mainstream languages, lack of libraries and frameworks (and lack of polish in the ones that exist, like Jester). The language itself is good and it's still evolving, so it has a chance of getting even better.
We need you to help us change that :)
> BTW: I've read your book, great job!
Thanks!
> Also, I like how the code listings are annotated - how did you generate them?
I used asciidoc to write the book and then my publisher applied some magic to format everything nicely. Not sure about the details I'm afraid.
I'd second this, especially since Nim has already got decent server-side capabilities as well means you can write an isometric web application where the server-side is written in a language with performance comparable to C.
Programming is as much about communicating with your peers as it is about getting the computer to do what you want. Go's inflexibility results in uniform code which makes it easier to understand.
Macros allow you to introduce dialects which can be powerful in their expressiveness but often result in significant departures from the original language.
When someone new comes into the project they have to learn the dialect before they can even read the code. More often than not they give up and rewrite the code from scratch in a language they understand.
Sometimes additions to the language make sense, but there's a real cost, a cost that often gets ignored. Do it to much and you kill the golden goose.
I agree with the first point, but not the second.
The go language seems more than anything to be "you can use our language, but it serves us and our wants first and foremost."
Now, I like the enforced style guide. That's not my gripe. It's that go deliberately treats certain platforms as second class, deliberately treats feature requests as second class if they are not complementary to what the original creators intents.
I don't wanna get shot for opening the can of worms about generics for the millionth time, but it just seemed like such an obvious solution to a widespread, pervasive, irritating problem. It was an issue early on, before there was really a lot of back-compat surface to even think about, but it wasn't what the Google posse wanted, and it didn't happen.
In the case of go, I believe the true cost of making it better is that Google is learning that when you use an internal product for a wide array of projects, and then later on you decide to flesh it out and open source it, you lose the ability to react to your audience as easily and that also narrows the surface for people to come in fresh to the project and contribute or provide feedback.
Go shot it's own foot. We (non-googlers) certainly didn't do it to them.
All this aside, the technical prowess at work on the team, especially in the past twoish years has been really impressive. At least they have stellar developers.
> It makes me feel like the language creators of Golang purposefully decide that users of the language aren’t smart.
If they are anything like Guido for Python, I think the idea is quite the contrary.
Language users are smart. Just too smart for their own good.
Like the coyotes we talked about recently on HN (https://news.ycombinator.com/item?id=17079369) who are "winning the mini-game of each human interaction, but they are losing the meta-game of what society will do if coyotes aren’t scared."
Well, just like that, language users with macros are winning the mini-game of their interaction with the current opened files in their editor, but they are loosing the meta game of maintainable projects, shareable knowledge and reusable tools.
Macros (or their small brother, "just a little DSL") are the most abuse feature in dev, period. They are too clever, the results almost never documented or even tested properly while often being very specific to the creator use cases.
I really think macros are one of the reasons why Lisp never became more popular: a small smart population love it for macros while the rest of the population just doesn't want to have to deal with all the macros BS created by the former population.
Same for Ruby. Honestly, having to go through yet another DSL du jour killed it for me.
So my guess is that the Goland creators know very well how smart the language users are. And they are afraid, very afraid.
.. and they're afraid, very afraid that if you give them that kind of power, they will make the creators roles irrelevant.
By echoing this in the echo chamber, we've perhaps deprived ourselves of getting enough collective experience with powerful programming tools to be able to establish good norms to teach high power maintainable programming. We're instead stuck in low level language wars.
Using type systems for system design anyone? Use Beta abstraction systematically?
> .. and they're afraid, very afraid that if you give them that kind of power, they will make the creators roles irrelevant.
That would be fantastic.
But right now most companies have a hard drive finding decent middle level dev.
Let's talk about your plan when american companies don't hire me to work from my bedroom in the south of France because they can't even find what they need in their own country anymore.
Unless you have a recipe to turn people that strugle with fizz buzz being able to magically understand complex abstractions.
2 replies →