4 ms·

Yes, the limitation is rarely the programming language, it is the programmer. Also, when you do the rewrite you have already solved the domain problem that you

Yes, the limitation is rarely the programming language, it is the programmer. Also, when you do the rewrite you have already solved the domain problem that you did not fully understand when implementing it the first time.

hyperpallium 10y ago
"Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it. But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage. > deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant
- jpgvm 10y ago
  Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.
  - fetbaffe 10y ago
    I could use the exact same arguments but for PHP.
    - noir_lord 10y ago
      Which is why I still often use PHP. For my usages its a reasonable language.
    - jpgvm 10y ago
      Not quite, I omited here that it is also statically typed and is a future proof language. Mainly because these are properties already shared with Java. However this is not true of PHP. PHP is a great velocity language, provided you have a small(er) team or are willing to commit to additional controls on how you write your PHP (document types/structure of arguments mainly) to ensure that your PHP code is able to be read quickly by other developers. Personally I prefer Go here because it enforces good readability by default and therefore scales better with team size.
      - fetbaffe 10y ago
        Readability is not problem in PHP either. Follow PSR-1, PSR-2 and PSR-4 and use a command like tool like codesniffer in your build step to guarantee code standard on each commit (or use Upsource) And in PHP7.x you have even more type hinting than before and with an IDE like PHPStorm refactoring is a breeze. And with the release of PHP7, PHP is future proof. The community will continue improve it with the major features, they have shown it. Interest in the language have increased. More RFCs is contributed to the language than before. https://wiki.php.net/rfc https://wiki.php.net/rfc Multiple teams on a large code base is not really a problem in modern PHP. I do it every day. We follow modern design patterns, code reviews, code coverage over 80% of the system (old as new code). New code is probably over 95% coverage. Deploys regularly multiple times every week. Almost all (>95%) of my problems stem from design decisions made in the past, not the language itself. I'm not saying that you should not use Go (or Java). Both are fine languages. Use the right tool for the job. If you don't do a realtime stock trading system or some embedded system, but some web stack, I can't really see that the majority of the problems stem from language choice (whatever you choose). It is in the team, the culture, the understanding of the domain. There should be your focus. Personally, the most two important things I look for in a language/platform is tooling and community.

hyperpallium 10y ago

"Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it. But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage. > deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant

jpgvm 10y ago
Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.
- fetbaffe 10y ago
  I could use the exact same arguments but for PHP.
  - noir_lord 10y ago
    Which is why I still often use PHP. For my usages its a reasonable language.
  - jpgvm 10y ago
    Not quite, I omited here that it is also statically typed and is a future proof language. Mainly because these are properties already shared with Java. However this is not true of PHP. PHP is a great velocity language, provided you have a small(er) team or are willing to commit to additional controls on how you write your PHP (document types/structure of arguments mainly) to ensure that your PHP code is able to be read quickly by other developers. Personally I prefer Go here because it enforces good readability by default and therefore scales better with team size.
    - fetbaffe 10y ago
      Readability is not problem in PHP either. Follow PSR-1, PSR-2 and PSR-4 and use a command like tool like codesniffer in your build step to guarantee code standard on each commit (or use Upsource) And in PHP7.x you have even more type hinting than before and with an IDE like PHPStorm refactoring is a breeze. And with the release of PHP7, PHP is future proof. The community will continue improve it with the major features, they have shown it. Interest in the language have increased. More RFCs is contributed to the language than before. https://wiki.php.net/rfc https://wiki.php.net/rfc Multiple teams on a large code base is not really a problem in modern PHP. I do it every day. We follow modern design patterns, code reviews, code coverage over 80% of the system (old as new code). New code is probably over 95% coverage. Deploys regularly multiple times every week. Almost all (>95%) of my problems stem from design decisions made in the past, not the language itself. I'm not saying that you should not use Go (or Java). Both are fine languages. Use the right tool for the job. If you don't do a realtime stock trading system or some embedded system, but some web stack, I can't really see that the majority of the problems stem from language choice (whatever you choose). It is in the team, the culture, the understanding of the domain. There should be your focus. Personally, the most two important things I look for in a language/platform is tooling and community.