5 ms·

I don’t think this theory holds much water. Go code is very opinionated but still flexible; it seems to be C but with superpowers and great tooling out of the

by pm90 8y ago

I don’t think this theory holds much water. Go code is very opinionated but still flexible; it seems to be C but with superpowers and great tooling out of the box. A whole bunch of complex software is written and in production using go; I don’t think it limits the productive/clever engineers from doing what they would do with Java.

danpalmer 8y ago
Interesting. You could be right! My experience with Go is very limited, but I tend to see interesting abstractions built with other languages. Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases. In Go, everything just tends to be functions and structs, and the lack of expressiveness make it difficult to do anything with nicer ergonomics. I would agree that it is C with superpowers in some respects though. > A whole bunch of complex software is written and in production using go This is true, but my point isn't that you can't write the software, just that it might have been better code in another language (easier to understand, reason about, more reliable, more maintainable?). The biggest benefit along these lines that Go seems to have is that lots of other software is written in it, which comes back to a similar argument as Java.
- vertline3 8y ago
  It's a replacement for c plus plus. Python, Ruby all those things are higher level. Haskell is different paradigm. It's apples and oranges
  - danpalmer 8y ago
    >It's a replacement for c plus plus. Python, Ruby all those things are higher level. Ok then, Rust or Swift. These are both replacements for C/C++ and the same applies. > Haskell is different paradigm I don't think this is a reason to reject it. That paradigm might allow for better solutions to the problems.
    - vertline3 8y ago
      Ugh. Not going to wrestle with a pig, I'll get dirty and he'll enjoy it
      - danpalmer 8y ago
        I'm sorry, did I misunderstand your point? I'm not saying these things to troll, this is my honest opinion. I'll admit, Haskell is probably a poor choice for other reasons, but in many ways I think Rust and Swift are better languages than Go for the things Go is commonly used for.
        vertline3 8y ago
        Youre okay it's 5 am I've been up all night. I agree with the thoughts that Rob Pike can be opinionated, and that can be good and bad. There was a website cat-v I used to go to and cat-v harmful stuff software.the site really likes plan9 and go and Rob Pike. I feel it gives some insight, but I think it's bad to be too opinionated as this cat-v site can be
  - skohan 8y ago
    I would argue that Swift, a compiled, strongly typed language, is more a C++ replacement than it is comparable to Python or Ruby. The only "higher level" aspect would be largely hands-off memory management, but go is in the same boat there.
    - vertline3 8y ago
      Right, Swift is an apple thing though. I generally like Apple's choices, but stay away from walled gardens, so can t go too deep into its merits.
      - skohan 8y ago
        It was an apple thing. It's now an open-source, community driven language. It's very usable on Linux for server-side applications, and with Swift for Tensorflow it's going to become increasingly relevant in data science and machine learning. edit: Swift is no more an "apple thing" than go is a "google thing"
        vertline3 8y ago
        Great to hear, sounds like they were both designed to solve similar issues with cpp
        kjeetgill 8y ago
        Huh, I was under this mistaken impression too. I know many, many, companies and projects using go as a foundation, but I don't think I've heard of any using swift. Any I should read up on?
        ncmncm 8y ago
        I.e. Swift is an apple thing, go is a google thing... and c# is a microsoft thing, and java is an oracle thing. I am happy to have never been obliged to use any of them, and I expect my odds of needing to use any of them in the future are strictly decreasing. Rust might not really be a mozilla thing anymore. But is it entirely a coincidence that Firefox had become a lot crashier since they started shoehorning rust code into it?
- skywhopper 8y ago
  Different problem domains have different cost/benefit analyses. I write in several languages daily depending on the problem I’m trying to solve. Go may not be right for most problems. But it works really well in the right situations. If you need something performant, efficient, easy to deploy, and easy and fast to build, Go checks those boxes. Deploying complex software written in Ruby, Python, Node, or Java can be a major pain, with thousands of files and dependency hell, or build-in-place which has its own set of risks. Versus deploying a single binary file, that runs faster, in less memory, more stably, and takes orders of magnitude less time to build? The other languages will need to be a lot better than they currently are to win that fight.
- kjeetgill 8y ago
  > Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases > easier to understand, reason about, more reliable, more maintainable I find DSLs obfuscating, buggy, and unmaintainable. I know we're going to agree to disagree here, as I'm a fan of the Java, Go, C, or even Python side of things, I find most DSLs are a nightmare. Maybe we work on vastly different software. Most DSLs, imho, are usually better off removed. It's part of a class of code smells I like to call: Sound concepts applied too liberally and out of context. It's the same sin as the "Architect Astronauts" of Java Enterprise FizzBuzz Design Pattern overload. Python and monkey patching abuse. JavaScript and framework explosion. C++ had operater overload abuse. Every language seems to go through it's awkward teen years and finds a good balance eventually, so I don't mean to rag on DSLs. The problem is: DSLs usually work well when the problems are well defined, common, and relatively static. SQL comes to mind. BLAS/numpy like programs. If the DSL models business or application ideas, those will grow and shift. If I find myself fixing bugs in the compilers, I need a different language. That's what DSLs end up as: half-designed specs I need to fix.
  - nwmcsween 8y ago
    DSLs are just embedded languages, if they suck it's due to the DSL or the expressiveness of the language used to create it.
- divan 8y ago
  > everything just tends to be functions and structs Out of curiosity, what else do you need that can’t be done with “functions and structs”?
YeGoblynQueenne 8y ago
>> A whole bunch of complex software is written and in production using go And also in Java, javascript, COBOL, FORTRAN, R, and many other languages that are associated in software developer circles with all sorts of developer-unfriendly nastiness. The truth is that most programming languages we use today are a bit shit, because they have to make hard choices to overcome limitations of hardware and, well, human brains. In my view, the real reason programmers are highly valued is because we can endure the hardship of using those primitive tools and make them shine despite their inherent limitations, not because we are so brilliant we can't keep ourselves from programming the equivalent of the Capella Sistina in the process of gluing together a bunch of library interfaces. Otherwise- well, you can write complex software in Brainfuck, if you really put your mind to it. Hell, a whole bunch of very complex software is written in assembly languages. So what? That's a testament to the ability of humans to express themselves in very restricted formalisms, not to the quality of those formalisms.
- notafraudster 8y ago
  It is unusual to see R in a list of languages characterized as being developer unfriendly, at least in this century. Best in breed metaprogramming and code introspection tools, an excellent debugger and profiler, a wide ecosystem of accessible books written by core language developers, an excellent (although I agree difficult to submit to) central package repository, high quality data serialization options, built-in report-making tools, huge and high quality standard library (even moreso if you consider the tidyverse a standard library), easy to use and efficient ways to dispatch to other languages, etc. There are a bunch of weird language quirks, most stemming from its legacy as a reimplementation of S in the early days, but I would be surprised if it was viewed as developer-unfriendly.
  - ams6110 8y ago
    I'm a developer of 20+ years and I found R to be unfathomable. By that I mean so arbitrary and inconsistent that I quickly gave up on thinking it was worth my time.
  - YeGoblynQueenne 8y ago

by pm90 8y ago

danpalmer 8y ago

Interesting. You could be right! My experience with Go is very limited, but I tend to see interesting abstractions built with other languages. Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases. In Go, everything just tends to be functions and structs, and the lack of expressiveness make it difficult to do anything with nicer ergonomics. I would agree that it is C with superpowers in some respects though. > A whole bunch of complex software is written and in production using go This is true, but my point isn't that you can't write the software, just that it might have been better code in another language (easier to understand, reason about, more reliable, more maintainable?). The biggest benefit along these lines that Go seems to have is that lots of other software is written in it, which comes back to a similar argument as Java.

vertline3 8y ago
It's a replacement for c plus plus. Python, Ruby all those things are higher level. Haskell is different paradigm. It's apples and oranges
- danpalmer 8y ago
  >It's a replacement for c plus plus. Python, Ruby all those things are higher level. Ok then, Rust or Swift. These are both replacements for C/C++ and the same applies. > Haskell is different paradigm I don't think this is a reason to reject it. That paradigm might allow for better solutions to the problems.
  - vertline3 8y ago
    Ugh. Not going to wrestle with a pig, I'll get dirty and he'll enjoy it
    - danpalmer 8y ago
      I'm sorry, did I misunderstand your point? I'm not saying these things to troll, this is my honest opinion. I'll admit, Haskell is probably a poor choice for other reasons, but in many ways I think Rust and Swift are better languages than Go for the things Go is commonly used for.
      - vertline3 8y ago
        Youre okay it's 5 am I've been up all night. I agree with the thoughts that Rob Pike can be opinionated, and that can be good and bad. There was a website cat-v I used to go to and cat-v harmful stuff software.the site really likes plan9 and go and Rob Pike. I feel it gives some insight, but I think it's bad to be too opinionated as this cat-v site can be
- skohan 8y ago
  I would argue that Swift, a compiled, strongly typed language, is more a C++ replacement than it is comparable to Python or Ruby. The only "higher level" aspect would be largely hands-off memory management, but go is in the same boat there.
  - vertline3 8y ago
    Right, Swift is an apple thing though. I generally like Apple's choices, but stay away from walled gardens, so can t go too deep into its merits.
    - skohan 8y ago
      It was an apple thing. It's now an open-source, community driven language. It's very usable on Linux for server-side applications, and with Swift for Tensorflow it's going to become increasingly relevant in data science and machine learning. edit: Swift is no more an "apple thing" than go is a "google thing"
      - vertline3 8y ago
        Great to hear, sounds like they were both designed to solve similar issues with cpp
      - kjeetgill 8y ago
        Huh, I was under this mistaken impression too. I know many, many, companies and projects using go as a foundation, but I don't think I've heard of any using swift. Any I should read up on?
      - ncmncm 8y ago
        I.e. Swift is an apple thing, go is a google thing... and c# is a microsoft thing, and java is an oracle thing. I am happy to have never been obliged to use any of them, and I expect my odds of needing to use any of them in the future are strictly decreasing. Rust might not really be a mozilla thing anymore. But is it entirely a coincidence that Firefox had become a lot crashier since they started shoehorning rust code into it?
skywhopper 8y ago
Different problem domains have different cost/benefit analyses. I write in several languages daily depending on the problem I’m trying to solve. Go may not be right for most problems. But it works really well in the right situations. If you need something performant, efficient, easy to deploy, and easy and fast to build, Go checks those boxes. Deploying complex software written in Ruby, Python, Node, or Java can be a major pain, with thousands of files and dependency hell, or build-in-place which has its own set of risks. Versus deploying a single binary file, that runs faster, in less memory, more stably, and takes orders of magnitude less time to build? The other languages will need to be a lot better than they currently are to win that fight.
kjeetgill 8y ago
> Ruby, Haskell, Swift, JS, even some Python – I see engineers building DSLs and architectures that strongly fit particular use-cases > easier to understand, reason about, more reliable, more maintainable I find DSLs obfuscating, buggy, and unmaintainable. I know we're going to agree to disagree here, as I'm a fan of the Java, Go, C, or even Python side of things, I find most DSLs are a nightmare. Maybe we work on vastly different software. Most DSLs, imho, are usually better off removed. It's part of a class of code smells I like to call: Sound concepts applied too liberally and out of context. It's the same sin as the "Architect Astronauts" of Java Enterprise FizzBuzz Design Pattern overload. Python and monkey patching abuse. JavaScript and framework explosion. C++ had operater overload abuse. Every language seems to go through it's awkward teen years and finds a good balance eventually, so I don't mean to rag on DSLs. The problem is: DSLs usually work well when the problems are well defined, common, and relatively static. SQL comes to mind. BLAS/numpy like programs. If the DSL models business or application ideas, those will grow and shift. If I find myself fixing bugs in the compilers, I need a different language. That's what DSLs end up as: half-designed specs I need to fix.
- nwmcsween 8y ago
  DSLs are just embedded languages, if they suck it's due to the DSL or the expressiveness of the language used to create it.
divan 8y ago
> everything just tends to be functions and structs Out of curiosity, what else do you need that can’t be done with “functions and structs”?

YeGoblynQueenne 8y ago

>> A whole bunch of complex software is written and in production using go And also in Java, javascript, COBOL, FORTRAN, R, and many other languages that are associated in software developer circles with all sorts of developer-unfriendly nastiness. The truth is that most programming languages we use today are a bit shit, because they have to make hard choices to overcome limitations of hardware and, well, human brains. In my view, the real reason programmers are highly valued is because we can endure the hardship of using those primitive tools and make them shine despite their inherent limitations, not because we are so brilliant we can't keep ourselves from programming the equivalent of the Capella Sistina in the process of gluing together a bunch of library interfaces. Otherwise- well, you can write complex software in Brainfuck, if you really put your mind to it. Hell, a whole bunch of very complex software is written in assembly languages. So what? That's a testament to the ability of humans to express themselves in very restricted formalisms, not to the quality of those formalisms.

notafraudster 8y ago
It is unusual to see R in a list of languages characterized as being developer unfriendly, at least in this century. Best in breed metaprogramming and code introspection tools, an excellent debugger and profiler, a wide ecosystem of accessible books written by core language developers, an excellent (although I agree difficult to submit to) central package repository, high quality data serialization options, built-in report-making tools, huge and high quality standard library (even moreso if you consider the tidyverse a standard library), easy to use and efficient ways to dispatch to other languages, etc. There are a bunch of weird language quirks, most stemming from its legacy as a reimplementation of S in the early days, but I would be surprised if it was viewed as developer-unfriendly.
- ams6110 8y ago
  I'm a developer of 20+ years and I found R to be unfathomable. By that I mean so arbitrary and inconsistent that I quickly gave up on thinking it was worth my time.
- YeGoblynQueenne 8y ago