31–40 of 363 posts
Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code with less things to learn.
Earlier quoted context omitted.
The thing with Go, is that it is disappointing what Google is capable of in terms of language design versus what Apple and Microsoft have done in this field. Sure there were languages with such type systems before, and we managed to deliver our work with them. However I don't want to work in 2017 as I used to work in the mid-90's, when templates were an experimental feature in C++, or the only MLs we knew were Caml L…
> is that it is disappointing what Google is capable of Man, how long will this meme survive? Go only initially originated with some Google developers, it's not in any way "Google's answer to Apple's and Microsoft's strategically-important and accordingly-subsidized-and-evangelized-and-invested-in languages". Just picture a handful of (previously "accomplished" in the field, as it turns out though) guys thinking "thi…
If Google wouldn't agree with their actions, or did not pay to increase the team size, they would be developing the language outside Google walls.
The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics. Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code wi…
No, it's the same language with a bigger vocabulary and grammar, on which everybody agrees.
And generics can be quite sane, as exemplified by the languages in the ML family, which have been around for decades.
Java also didn't have generics. They added them eventually, much later in version 5, but then due to backwards compatibility concerns they added them with invariance at the declaration site and complex wildcard rules at use site.
So the irony of this situation is that Go will add generics, it's inevitable for a (quasi) static language once it grows in usage and ecosystem. But when they'll do add those generics, they'll be broken due to backwards compatibility concerns, becoming yet another counter example for generics, picked up by the next Go / Java that will reinvent the wheels again.
The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics. Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code wi…
> One can say exactly the same about generics No, it's the same language with a bigger vocabulary and grammar, on which everybody agrees. And generics can be quite sane, as exemplified by the languages in the ML family, which have been around for decades. Java also didn't have generics. They added them eventually, much later in version 5, but then due to backwards compatibility concerns they added them with invarianc…
It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power. In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines. If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of dep…
I was forced to use go for a job, it actually made me feel stupider, so much that I didn't know how to use the right types anymore when i moved back to a more sophisticated language. I was afraid the language wouldn't let me do what I want, just like Go.
There will be a "go programmer generation" and it's not going to be pretty. If people deem "generics too complicated to understand", what can you expect from programmers who don't want to learn anything? The only thing I find nice about the language is implicit interfaces. But not at all cost.
The author mentioned that code generation "introduces additional, non-standart syntax". One can say exactly the same about generics. Most useful typesystems with generics are Turing-complete. Essentially they introduce own language for types with often very weired rules and syntax that one has to master on top of the basic language. With code generation I can program my types using the same language I use for code wi…
With code generation you are introducing your own compiler, DSL and all that bullshit that becomes yet another dependency you have to manage. That's busy work, that's bureaucracy, that's brittle. Now your codebase depends on pragma statements, manifests and obviously a specific syntax that aren't even managed by the default compiler, that's the opposite of simplicity.
At least C has standard macros, and most developers uses the same syntax for them.
Go is an extremely divisive language, a fact which will hinder its adoption as criticism of that language will get harsher since more people get exposed to it.
The good thing is, as Google relies more and more on Go, peer pressure from other googlers might force changes in the language.
I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Sigh I hate to say this I really do. But here goes... So have you checked out rust?
It is, I think, going to be very difficult to enjoy writing code in a less powerful language when you are exposed to languages that hold awesome power. In fact, this has been the basis for much writing on Lisp too. Paul Graham has written entire essays along the same lines. If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of dep…
> If you work in a job that forces the use of a less powerful language than what you've been exposed to, you can, I think, go through a sort of depression. You simply long to use the tools that you know hold much more power yet must resign yourself to the tools you have. I was forced to use go for a job, it actually made me feel stupider, so much that I didn't know how to use the right types anymore when i moved back…
That said if I look back on the past 6 months, I believe I have improved. In fact, a core principle I hold dear goes as follows:
"If I look back 6 months and I'm not any better, there's a big problem".
At one point, it seemed to annoy my non-technical boss because he couldn't understand why some of the code I wrote 6 months ago is perhaps not as good as it could be. He has kept me around so maybe it isn't a bad thing :)
We will, I think, always have programmers who don't want to learn anything new. It's interesting that there exists "Continuing Professional Development points" in the UK for healthcare: you get a rebate for each hour spent on courses to further your education. Maybe software engineering would benefit from this given the amount of, quite significant, cost sunk into large scale projects. Their universal credit programme should be incentive enough.
Entirely different problem though. If not Go, then what?
I hate to sound like the rust evangelist strike force... I really do. But your complaints are exactly what it would solve... Sigh I hate to say this I really do. But here goes... So have you checked out rust?
How robust/mature is it as of yet? More importantly, how are compile speeds and how much of a priority are they to the compiler maintainers? I too find it quite promising in terms of "a language aiming for the benefits of Go with the expressiveness and added easier correctness of FP". But "promising" doesn't mean I'd replace the few use-cases where Go currently shines for me (wouldn't recommend it for any-and-all dev…
On the contrary, you haven't pointed out an objective issue that you have with Go. You offered some harsh remarks about the language but backed them up with praise.
I'd say you love the language, but apologetically so. You shouldn't it's a great language.
If ever you decide it's not for you then look at other alternatives, rust being one them.
> Go is just too different to how I think: when I approach a programming problem, I first think about the types and abstractions that will be useful; I think about statically enforcing behaviour I see statements like this a lot from Haskellers and I think its overstated. Anecdotally, after going from Python to spending 3-4 years in Haskell then going back to a dynamic language (Elixir) I've come to the conclusion tha…
I have come to think that it is precisely when the language switch feels the worst, the learning is the most beneficial for long term. If it is popular and you feel like it does not really work, it means you have conceptual learning to do.