5 ms·

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up

Maybe it makes sense to read the success of Golang as a smart piece of social engineering. Start with a simple and accessible language and gradually ratchet up the complexity to deal with more real-world problems. You may eventually wind up with a worse language but at least you'll have users. Rust tried to solve a lot of hard problems out of the gate and that has slowed its growth IMO. It's sort of another worse-is-better dichotomy.

shmerl 8y ago
That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.
- cageface 8y ago
  What tends to happen is that you bring out a simplified, cleaned-up version of the popular language of the day. People then flock to that new language and start making feature requests. Over time that language becomes as complex and inelegant as the language it replaced and you can start the whole cycle all over again. The move from C++ -> Java -> Go is a perfect example of this cycle.
  - e3b0c 8y ago
    C is a language designed to enable more efficient communication between the computer and the programmer in mind. C++ is a language designed to enable more communication between the compiler and the programmer. Go is a language designed to enable more efficient communication between programmers.
    - pjmlp 8y ago
      C was a language designed by two developers without background in language design that got lucky, because Bell Labs wasn't allowed to sell UNIX thus it ended up licensing it for a symbolic price to universities. C was hardly efficient in the 80s micro-computers, and outside Bell Labs people were doing compiler optimization research in languages like PL.8 and similar. Had Bell Labs been allowed to sell UNIX and history would certainly looked much different.
      - e3b0c 8y ago
        When talking about "efficient communication" between the computer and the programmer, it does not necessarily imply the characteristics of the runtime performance. For instance, Fortran is very performant in numerical computing, even outperforming C, but it has difficulty in accessing I/O mapped registers or implementing an interrupt handler, a jump table, or just cleaning a particular chunk of memory addresses.
        pjmlp 8y ago
        Another urban legend from C yearly days. There was plenty of research in system languages since the early 60's outside Bell Labs, with OSes being written in Algol, Pascal and PL/I variants. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities." -- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
  - klodolph 8y ago
    I don’t think Java and Go will ever, combined, reach the complexity of C++. The reason why older languages are complex and inelegant is because our understanding of how to create simple yet useful languages has increased, not because older languages accumulate much complexity.
    - adrianN 8y ago
      Wanting to do what the new languages can do without breaking backwards compatibility is a big reason why C++ got so complicated. C++98 isn't all that complex, but if you want to learn C++20 you still have to learn every language feature that was developed in the last thirty years and how they all interact.
      - pjmlp 8y ago
        Just like wanting to learn Python 3.7 means learning about 500 PEPs and how they interact across each Python release (major.minor, during the last 25 years and alternatives to CPython.
        adrianN 8y ago
        Well Python 3 broke compatibility so you don't have to start at Python 0.1 alpha, but yes, completely understanding Python is also no easy task. I write Python almost every day and have taught courses using it, but I know of features that I don't understand. There are probably more that I'm not even aware of.
      - klodolph 8y ago
        I would disagree with the claim that “C++98 isn’t all that complex.” It was so complex that any project I found using it would restrict itself to some arbitrary subset, just to keep complexity under control. Java has gone through years of backwards-compatible changes, and is still wonderfully simple compared to early versions of C++. C++ started with a mess of different features and hasn’t really gotten worse. If anything, C++11 is simpler than C++98 from a user’s perspective, even though it’s not from an implementer’s perspective. One of the big differences is that Java and Go have straightforward context-free grammars, mostly, and you can whip up a working parser in no time. C++ is a bit of a beast, by comparison (hence keywords like “typename”). C++ also has the complex overloads and template system. I think people underestimate how complex these things are when they are learning C++, and how complex their interactions are. Then there’s the preprocessor. You can kind of argue that these are just an accumulation of changes, but other languages contemporary with C and C++ do not suffer from these complexities, so the argument falls flat. By comparison, Go and Java rely on reflection or code generation more, and these are a bit simpler.
- InGodsName 8y ago
  There is also a sunk cost fallacy which keeps people trapped.
  - mroche 8y ago
    Sunk cost or costly effort? There are a more than a handful of large of technologies, frameworks and libraries used in my industry which would have to be ported/rewritten and supported from C++ before anyone would think twice before using an alternate language. Particularly when speed is the name of the game (in terms of integration, not just compiled binaries). There are hundreds of C++ libraries employed daily that would be non-trivial to port.
    - shmerl 8y ago
      Things are being rewritten, and those which are still not, can be used by combining languages.
  - adrianN 8y ago
    It's not a fallacy if you either have to manage two language stacks or rewrite huge codebases. Those things are expensive.
oscargrouch 8y ago
I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end. C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and you can even see this reasoning being used as a reason why they created Go). Then Go showed up with simplicity and a good story in performance and memory, deploying simple binaries in a world of complex server infrastructure paved out by Java was a very handy and right on time approach. The problem with Rust now, is that it is target the system programming, in a era of system programming renaissance given the whole mobile app scenery. The problem is; there is already a lot of C++, C, Java, Objective C and Swift code there, so it will be hard to have a good reason to rewrite complex stuff with a lot of man hours in it in Rust. Every language needs a platform. C is here because of Unix, C++ because of Unix, games and early 2000 and 90's era startups. Java and C# because of bussiness software, Go because of the cloud, Ruby and PHP; because of webservers, Rails an blogs, Python for educational purposes, Data Science, ML and now AI. Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable. Its really tough, and if Rust dont find a platform to grow it will be very hard to advance any further. But, there's always new tech waves and tools that will marry perfectly with them. Lets see which languages are able to be a perfect fit for them in years to come. But right now Rust will depend a lot of the community it already formed to keep sharp and maybe be lucky to surf one of those waves.
- dan00 8y ago
  > Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable. For existing software it certainly is less about rewriting it but extending it in Rust. Thanks to not having a runtime and being quite easy to create a shared library with a C-ABI, pretty much any software written in any language could be extended with code written in Rust.
jniedrauer 8y ago
Go is still a very simple language. It's not just social engineering. Compare it to Python, which is another "simple" language that you can be dangerous in on day one. As you gain experience in Go, you learn idiomatic ways to do things and memorize the core library, but the fundamental mechanics don't change. As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 different ways to build a distributable package, then start extending __getitem__ and __setitem__ and adding decorators to everything and before you realize what you've done, you've torn apart the laws of physics and your code has nightmarish side effects lurking around every corner.
- sevensor 8y ago
  > As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 different ways to build a distributable package, then start extending __getitem__ and __setitem__ and adding decorators to everything and before you realize what you've done, you've torn apart the laws of physics and your code has nightmarish side effects lurking around every corner. Alternatively, you glimpse the chthonic horrors lurking at the end of that path, purge your code of hidden mutable state, and use Python to write straightforward procedural programs.
jurip 8y ago
This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf
- nabla9 8y ago
  Guy's point was that the language should be designed to be grown grown by users, not by language designers. > We need to put tools for language growth in the hands of the users. Guy's previos work with Common Lisp is epitome of this. There are three kind of macros in the language: reader macros, macros and compiler macros. They give the tools for the user to extend the language. There is just 25 or so core primitives in the 'core' language and the runtime. The rest 900+ functions and symbols are basically the standard library (the fact that they are slapped into the same package and they extend the core in a ways that other languages can't hides the simplicity of the language somewhat).
- cageface 8y ago
  I think this is a really appealing idea but so far nobody’s managed to build a successful language this way. I’d love to see a mainstream language designed on these principles myself but I think it’s not going to be an s-expression based language.
  - ramchip 8y ago
    Whether it’s mainstream is debatable, but I think Elixir is a really successful example of extensible language, and indeed it managed to do this without s-expressions. Various libraries extend the language for HTTP routing, parsing, DB queries, property testing, static analysis, etc. It makes possible a lot of experimentation by the wider community, and not just the group of core language developers. The creator has repeated this philosophy a few times: > There is very little reason for an Elixir v2.0 with breaking changes. The language was designed to be extensible and if we need to do major changes to the language to improve the language itself, then we failed at the foundation. https://elixirforum.com/t/what-would-you-like-to-see-in-elixir-2/15912/21 https://elixirforum.com/t/what-would-you-like-to-see-in-elix... > A big language does not only fragment the community and makes it harder to learn but it is also harder to maintain. It is also why the language was designed to be extensible: so the community could build what is necessary without a push to make everything part of the language. https://elixirforum.com/t/questions-about-property-testing-stream-data/9445/33 https://elixirforum.com/t/questions-about-property-testing-s... > We also understand there is a limited amount of features we can add to the language before making the journey too long or the language too big. Adding something now means not including something else later. As an exercise, let’s see a counter example of when we didn’t add something to the language: GenStage. [...] https://elixirforum.com/t/questions-about-property-testing-stream-data/9445 https://elixirforum.com/t/questions-about-property-testing-s...

shmerl 8y ago

That social engineering strategy only helps in the short term (short on the language scale, which can still be many years). If you get a convoluted language in result, in the long term it will increasingly irritate programmers, who will anyway start looking for objectively better alternatives. So Rust took the right approach IMHO.

cageface 8y ago
What tends to happen is that you bring out a simplified, cleaned-up version of the popular language of the day. People then flock to that new language and start making feature requests. Over time that language becomes as complex and inelegant as the language it replaced and you can start the whole cycle all over again. The move from C++ -> Java -> Go is a perfect example of this cycle.
- e3b0c 8y ago
  C is a language designed to enable more efficient communication between the computer and the programmer in mind. C++ is a language designed to enable more communication between the compiler and the programmer. Go is a language designed to enable more efficient communication between programmers.
  - pjmlp 8y ago
    C was a language designed by two developers without background in language design that got lucky, because Bell Labs wasn't allowed to sell UNIX thus it ended up licensing it for a symbolic price to universities. C was hardly efficient in the 80s micro-computers, and outside Bell Labs people were doing compiler optimization research in languages like PL.8 and similar. Had Bell Labs been allowed to sell UNIX and history would certainly looked much different.
    - e3b0c 8y ago
      When talking about "efficient communication" between the computer and the programmer, it does not necessarily imply the characteristics of the runtime performance. For instance, Fortran is very performant in numerical computing, even outperforming C, but it has difficulty in accessing I/O mapped registers or implementing an interrupt handler, a jump table, or just cleaning a particular chunk of memory addresses.
      - pjmlp 8y ago
        Another urban legend from C yearly days. There was plenty of research in system languages since the early 60's outside Bell Labs, with OSes being written in Algol, Pascal and PL/I variants. "Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization...The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue.... Seibel: Do you think C is a reasonable language if they had restricted its use to operating-system kernels? Allen: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve. By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are ... basically not taught much anymore in the colleges and universities." -- Fran Allen interview, Excerpted from: Peter Seibel. Coders at Work: Reflections on the Craft of Programming
- klodolph 8y ago
  I don’t think Java and Go will ever, combined, reach the complexity of C++. The reason why older languages are complex and inelegant is because our understanding of how to create simple yet useful languages has increased, not because older languages accumulate much complexity.
  - adrianN 8y ago
    Wanting to do what the new languages can do without breaking backwards compatibility is a big reason why C++ got so complicated. C++98 isn't all that complex, but if you want to learn C++20 you still have to learn every language feature that was developed in the last thirty years and how they all interact.
    - pjmlp 8y ago
      Just like wanting to learn Python 3.7 means learning about 500 PEPs and how they interact across each Python release (major.minor, during the last 25 years and alternatives to CPython.
      - adrianN 8y ago
        Well Python 3 broke compatibility so you don't have to start at Python 0.1 alpha, but yes, completely understanding Python is also no easy task. I write Python almost every day and have taught courses using it, but I know of features that I don't understand. There are probably more that I'm not even aware of.
    - klodolph 8y ago
      I would disagree with the claim that “C++98 isn’t all that complex.” It was so complex that any project I found using it would restrict itself to some arbitrary subset, just to keep complexity under control. Java has gone through years of backwards-compatible changes, and is still wonderfully simple compared to early versions of C++. C++ started with a mess of different features and hasn’t really gotten worse. If anything, C++11 is simpler than C++98 from a user’s perspective, even though it’s not from an implementer’s perspective. One of the big differences is that Java and Go have straightforward context-free grammars, mostly, and you can whip up a working parser in no time. C++ is a bit of a beast, by comparison (hence keywords like “typename”). C++ also has the complex overloads and template system. I think people underestimate how complex these things are when they are learning C++, and how complex their interactions are. Then there’s the preprocessor. You can kind of argue that these are just an accumulation of changes, but other languages contemporary with C and C++ do not suffer from these complexities, so the argument falls flat. By comparison, Go and Java rely on reflection or code generation more, and these are a bit simpler.
InGodsName 8y ago
There is also a sunk cost fallacy which keeps people trapped.
- mroche 8y ago
  Sunk cost or costly effort? There are a more than a handful of large of technologies, frameworks and libraries used in my industry which would have to be ported/rewritten and supported from C++ before anyone would think twice before using an alternate language. Particularly when speed is the name of the game (in terms of integration, not just compiled binaries). There are hundreds of C++ libraries employed daily that would be non-trivial to port.
  - shmerl 8y ago
    Things are being rewritten, and those which are still not, can be used by combining languages.
- adrianN 8y ago
  It's not a fallacy if you either have to manage two language stacks or rewrite huge codebases. Those things are expensive.

oscargrouch 8y ago

I dont think that by looking only to features we can understand this very well. Go was very lucky to be launched when cloud computing fever was catching up, and people were being burned for using techs like Java for this end. C++ were very performant, and unlike Java not a memory hog, but for this sort of tasks it was deemed to complex. Besides the ammount of people that were able to program in it was limited (and you can even see this reasoning being used as a reason why they created Go). Then Go showed up with simplicity and a good story in performance and memory, deploying simple binaries in a world of complex server infrastructure paved out by Java was a very handy and right on time approach. The problem with Rust now, is that it is target the system programming, in a era of system programming renaissance given the whole mobile app scenery. The problem is; there is already a lot of C++, C, Java, Objective C and Swift code there, so it will be hard to have a good reason to rewrite complex stuff with a lot of man hours in it in Rust. Every language needs a platform. C is here because of Unix, C++ because of Unix, games and early 2000 and 90's era startups. Java and C# because of bussiness software, Go because of the cloud, Ruby and PHP; because of webservers, Rails an blogs, Python for educational purposes, Data Science, ML and now AI. Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable. Its really tough, and if Rust dont find a platform to grow it will be very hard to advance any further. But, there's always new tech waves and tools that will marry perfectly with them. Lets see which languages are able to be a perfect fit for them in years to come. But right now Rust will depend a lot of the community it already formed to keep sharp and maybe be lucky to surf one of those waves.

dan00 8y ago
> Now what about Rust? Its trying to eat some lunch from C and C++. But a lot of code and value is already there in C and C++, where rewriting it in Rust just for some ocasional added value here and there is not reasonable. For existing software it certainly is less about rewriting it but extending it in Rust. Thanks to not having a runtime and being quite easy to create a shared library with a C-ABI, pretty much any software written in any language could be extended with code written in Rust.

jniedrauer 8y ago

Go is still a very simple language. It's not just social engineering. Compare it to Python, which is another "simple" language that you can be dangerous in on day one. As you gain experience in Go, you learn idiomatic ways to do things and memorize the core library, but the fundamental mechanics don't change. As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 different ways to build a distributable package, then start extending __getitem__ and __setitem__ and adding decorators to everything and before you realize what you've done, you've torn apart the laws of physics and your code has nightmarish side effects lurking around every corner.

sevensor 8y ago
> As you gain experience in Python, you develop a preference for virtualenvwrapper and experiment with 300 different ways to build a distributable package, then start extending __getitem__ and __setitem__ and adding decorators to everything and before you realize what you've done, you've torn apart the laws of physics and your code has nightmarish side effects lurking around every corner. Alternatively, you glimpse the chthonic horrors lurking at the end of that path, purge your code of hidden mutable state, and use Python to write straightforward procedural programs.

jurip 8y ago

This is what Guy Steele's Growing a Language talk was all about: "I should not design a small language, and I should not design a large one. I need to design a language that can grow. I need to plan ways in which it might grow—but I need, too, to leave some choices so that other persons can make those choices at a later time." https://www.youtube.com/watch?v=_ahvzDzKdB0 https://www.youtube.com/watch?v=_ahvzDzKdB0 or as PDF: https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf https://www.cs.virginia.edu/~evans/cs655/readings/steele.pdf

nabla9 8y ago
Guy's point was that the language should be designed to be grown grown by users, not by language designers. > We need to put tools for language growth in the hands of the users. Guy's previos work with Common Lisp is epitome of this. There are three kind of macros in the language: reader macros, macros and compiler macros. They give the tools for the user to extend the language. There is just 25 or so core primitives in the 'core' language and the runtime. The rest 900+ functions and symbols are basically the standard library (the fact that they are slapped into the same package and they extend the core in a ways that other languages can't hides the simplicity of the language somewhat).
cageface 8y ago
I think this is a really appealing idea but so far nobody’s managed to build a successful language this way. I’d love to see a mainstream language designed on these principles myself but I think it’s not going to be an s-expression based language.
- ramchip 8y ago
  Whether it’s mainstream is debatable, but I think Elixir is a really successful example of extensible language, and indeed it managed to do this without s-expressions. Various libraries extend the language for HTTP routing, parsing, DB queries, property testing, static analysis, etc. It makes possible a lot of experimentation by the wider community, and not just the group of core language developers. The creator has repeated this philosophy a few times: > There is very little reason for an Elixir v2.0 with breaking changes. The language was designed to be extensible and if we need to do major changes to the language to improve the language itself, then we failed at the foundation. https://elixirforum.com/t/what-would-you-like-to-see-in-elixir-2/15912/21 https://elixirforum.com/t/what-would-you-like-to-see-in-elix... > A big language does not only fragment the community and makes it harder to learn but it is also harder to maintain. It is also why the language was designed to be extensible: so the community could build what is necessary without a push to make everything part of the language. https://elixirforum.com/t/questions-about-property-testing-stream-data/9445/33 https://elixirforum.com/t/questions-about-property-testing-s... > We also understand there is a limited amount of features we can add to the language before making the journey too long or the language too big. Adding something now means not including something else later. As an exercise, let’s see a counter example of when we didn’t add something to the language: GenStage. [...] https://elixirforum.com/t/questions-about-property-testing-stream-data/9445 https://elixirforum.com/t/questions-about-property-testing-s...