3 ms·

> Dev builds are just as annoying with Golang as Ruby or Python. Hm, I'm pretty sure I can take any Go project out there and build it in a matter of minutes on

by bpizzi 8y ago

> Dev builds are just as annoying with Golang as Ruby or Python. Hm, I'm pretty sure I can take any Go project out there and build it in a matter of minutes on my current OS (depending on the build time of course). Just a matter of setting the environment on the right compiler binary and retrieving dependencies (which just came better 2 weeks ago with 1.11's modules). I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question: https://stackoverflow.com/questions/2812471/is-there-a-python-equivalent-of-rubys-rvm https://stackoverflow.com/questions/2812471/is-there-a-pytho.... Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.). > In fact build awkwardness is orthogonal to static vs dynamic typing. I said "interpreted languages' ecosystems", not "dynamically typed languages". I think you're mixing concepts here (or just maybe you're adding info not directly related to my comment).

dbdjfjrjvebd 8y ago
I can build any python project in 10 mimutes (and not pollute my global environment). I can't do that with Go or C or C++ or Ruby or php. I can if they are dockerised.
- bpizzi 8y ago
  Sorry I can't follow you (no offense really). You said at first "Dev builds are just as annoying with Golang as Ruby or Python" and now you're saying "I can build any python [...] I can't do that with [...] Ruby"?
  - dbdjfjrjvebd 8y ago
    I mean that I am knowledgable about Python builds. You are knowledgable about Golang. Neither skill is special. With Docker I don't need to learn as much about FooLang's build process to contribute to a project using FooLang.
    - bpizzi 8y ago
      Thanks, it gets clearer. As a matter of fact I'm both knowledgeable in building things in Python and Go, Node and PHP too. And others. But, admittedly, for 'big' things I tend to lean on Go nowadays (edit: mainly because I need to deliver on-premise, OS-aware applications). It seems like you think there's a "build process" with Go because you're accustomed to python/pyenv (or whatever is your env manager of choice), in which cas you need to known that there's no such thing with Go. The two following course of actions are the same: - "apt-get docker; docker pull {project-url}; docker start {project-url}" - "apt-get golang; git pull {project-url}; go run .go" (the last Go 1.11 will take care of dependencies at build time) You can't as easily do "apt-get python; git pull {url}; python .py", unless the program is really simple, because there's such questions as "python2 or 3?" or "pyenv, virtualenv or anaconda?", obligatory XKCD here: https://xkcd.com/1987 https://xkcd.com/1987. But it's totally ok not to bother learning the compilation command of a given project's language and rely on Docker, really I'm ok with that, doing it myself from time to time. My initial point was on app delivery to final users.
      - ric2b 8y ago
        You're right that the multiple solutions for Python make things confusing and prevent you from using the same method for every project, hopefully we'll start to standardize on pipenv, which makes the process: "apt install python3 python3-pipenv; git pull {url}; pipenv sync; python3 .py" pipenv sync sets up a virtual env and pulls all the dependencies.
icebraining 8y ago
Just a matter of setting the environment on the right compiler binary and retrieving dependencies Which is exactly how it works in Python. I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question: That SO question is about a tool for "setting the environment on the right compiler binary and retrieving dependencies". But you can also do it manually just fine; that's how I usually did it, in fact. Just retrieve the dependencies to a directory and call Python with PYTHONPATH set to it. Pyenv is essentially the same as Go's new modules tool, it's just not called through the same binary as the interpreter/compiler. Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.). Yes; with Python, you can both run directly from source without wasting time compiling after each change, or you can produce a standalone binary (dependent only on libc) for distribution, using a tool like PyInstaller. Plain old compiled based languages are much more limited.
- bpizzi 8y ago
  > Yes; with Python, you can both run directly from source without wasting time compiling after each change As I said, interpreted languages have their uses, of course. My initial point was about delivery to end users.
  - icebraining 8y ago
    And my point, which you cutoff early, is that with Python you can have both.
    - bpizzi 8y ago
      Yes, you can have everything in every language. After all it's turtles all the way down. What makes us successful as software engineers, in the end (and IMHO), is the efficiency level at which we reach our goals. To my eyes, when deliverability is the goal, then a language where native (cross)compilation is first class citizen is the most efficient path. But don't get me wrong, Python is really great and still a good choice for that scenario (I'm thinking of dropbox, for ex).

by bpizzi 8y ago

dbdjfjrjvebd 8y ago

I can build any python project in 10 mimutes (and not pollute my global environment). I can't do that with Go or C or C++ or Ruby or php. I can if they are dockerised.

bpizzi 8y ago
Sorry I can't follow you (no offense really). You said at first "Dev builds are just as annoying with Golang as Ruby or Python" and now you're saying "I can build any python [...] I can't do that with [...] Ruby"?
- dbdjfjrjvebd 8y ago
  I mean that I am knowledgable about Python builds. You are knowledgable about Golang. Neither skill is special. With Docker I don't need to learn as much about FooLang's build process to contribute to a project using FooLang.
  - bpizzi 8y ago
    Thanks, it gets clearer. As a matter of fact I'm both knowledgeable in building things in Python and Go, Node and PHP too. And others. But, admittedly, for 'big' things I tend to lean on Go nowadays (edit: mainly because I need to deliver on-premise, OS-aware applications). It seems like you think there's a "build process" with Go because you're accustomed to python/pyenv (or whatever is your env manager of choice), in which cas you need to known that there's no such thing with Go. The two following course of actions are the same: - "apt-get docker; docker pull {project-url}; docker start {project-url}" - "apt-get golang; git pull {project-url}; go run .go" (the last Go 1.11 will take care of dependencies at build time) You can't as easily do "apt-get python; git pull {url}; python .py", unless the program is really simple, because there's such questions as "python2 or 3?" or "pyenv, virtualenv or anaconda?", obligatory XKCD here: https://xkcd.com/1987 https://xkcd.com/1987. But it's totally ok not to bother learning the compilation command of a given project's language and rely on Docker, really I'm ok with that, doing it myself from time to time. My initial point was on app delivery to final users.
    - ric2b 8y ago
      You're right that the multiple solutions for Python make things confusing and prevent you from using the same method for every project, hopefully we'll start to standardize on pipenv, which makes the process: "apt install python3 python3-pipenv; git pull {url}; pipenv sync; python3 .py" pipenv sync sets up a virtual env and pulls all the dependencies.

icebraining 8y ago

Just a matter of setting the environment on the right compiler binary and retrieving dependencies Which is exactly how it works in Python. I'm pretty sure too I'll very quickly run into dependencies hell by picking randoms ruby/python programs. Just take a look at that SO question: That SO question is about a tool for "setting the environment on the right compiler binary and retrieving dependencies". But you can also do it manually just fine; that's how I usually did it, in fact. Just retrieve the dependencies to a directory and call Python with PYTHONPATH set to it. Pyenv is essentially the same as Go's new modules tool, it's just not called through the same binary as the interpreter/compiler. Interpreted languages have their uses, of course, but there's a clear difference in both ease of deployment and development between the realms of interpreted languages (Ruby/Python/PHP/etc.), VM/IL/JIT based languages (JVM/.NET/etc.) and 'plain old' compiler based languages (C/C++/Rust/Go/etc.). Yes; with Python, you can both run directly from source without wasting time compiling after each change, or you can produce a standalone binary (dependent only on libc) for distribution, using a tool like PyInstaller. Plain old compiled based languages are much more limited.

bpizzi 8y ago
> Yes; with Python, you can both run directly from source without wasting time compiling after each change As I said, interpreted languages have their uses, of course. My initial point was about delivery to end users.
- icebraining 8y ago
  And my point, which you cutoff early, is that with Python you can have both.
  - bpizzi 8y ago
    Yes, you can have everything in every language. After all it's turtles all the way down. What makes us successful as software engineers, in the end (and IMHO), is the efficiency level at which we reach our goals. To my eyes, when deliverability is the goal, then a language where native (cross)compilation is first class citizen is the most efficient path. But don't get me wrong, Python is really great and still a good choice for that scenario (I'm thinking of dropbox, for ex).