3 ms·

Think that is a misconception, that Go was just designed for inexperienced people. Rather it was designed to be easier to use than C++, from which the motivatio

Think that is a misconception, that Go was just designed for inexperienced people. Rather it was designed to be easier to use than C++, from which the motivation to have something different came. That a language is easier to use, doesn't mean it can't add features. The features are relative to how it helps the language be more useful and solve issues that users are having, so keeps it easier to use. Languages are always going to have pressure to adapt.

zelphirkalt 3y ago
True, but it still took them 12y to add generics.
valenterry 3y ago
I didn't say that it was designed only for inexperienced people. But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly. And the more features a language has and that a codebase uses, the longer it takes for someone to learn it and be productive (unless they can transfer knowledge from similar concepts of other languages of course).
- iainmerrick 3y ago
  But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly. Do you have a citation for that? As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones.
  - valenterry 3y ago
    > Do you have a citation for that? I do indeed have a citation for that by Rob Pike - and no matter how downvoted I am, it stays a fact: > 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. (https://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/ https://bravenewgeek.com/go-is-unapologetically-flawed-heres...) and also: > Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. (https://go.dev/talks/2012/splash.article https://go.dev/talks/2012/splash.article) > As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones. No, it's not a second order effect. Or rather: both what you say (a language "as clean and straightforward as C") as well as a language for devs early in their career (i.e. inexperienced) are both second order effects from the underlying reason that the language is targeted at developers at google.
    - deleted 3y ago
      [deleted]
    - pjmlp 3y ago
      > as clean and straightforward as C Says anyone that has never tried to write portable C code during the UNIX wars days, or deal with UB across compiler toolchains.
    - iainmerrick 3y ago
      Thank you for the links! I think I had read this before but I’d forgotten it was explicitly called out like that.

zelphirkalt 3y ago

True, but it still took them 12y to add generics.

valenterry 3y ago

I didn't say that it was designed only for inexperienced people. But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly. And the more features a language has and that a codebase uses, the longer it takes for someone to learn it and be productive (unless they can transfer knowledge from similar concepts of other languages of course).

iainmerrick 3y ago
But it was the or at least one of the major goals of the language creators that inexperienced developers can become productive quickly. Do you have a citation for that? As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones.
- valenterry 3y ago
  > Do you have a citation for that? I do indeed have a citation for that by Rob Pike - and no matter how downvoted I am, it stays a fact: > 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. (https://bravenewgeek.com/go-is-unapologetically-flawed-heres-why-we-use-it/ https://bravenewgeek.com/go-is-unapologetically-flawed-heres...) and also: > Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. (https://go.dev/talks/2012/splash.article https://go.dev/talks/2012/splash.article) > As far as I remember that’s as most a second order effect -- they wanted a language that felt as clean and straightforward as C, to benefit everybody including experienced developers, not primarily inexperienced ones. No, it's not a second order effect. Or rather: both what you say (a language "as clean and straightforward as C") as well as a language for devs early in their career (i.e. inexperienced) are both second order effects from the underlying reason that the language is targeted at developers at google.
  - deleted 3y ago
    [deleted]
  - pjmlp 3y ago
    > as clean and straightforward as C Says anyone that has never tried to write portable C code during the UNIX wars days, or deal with UB across compiler toolchains.
  - iainmerrick 3y ago
    Thank you for the links! I think I had read this before but I’d forgotten it was explicitly called out like that.