7 ms·

Just for the kicks, I tried using deno for a task at my day job. We had a need to extract records from a database into a textual format to be processed by othe

Just for the kicks, I tried using deno for a task at my day job. We had a need to extract records from a database into a textual format to be processed by other tools later. This is the typical task for a throwaway script which can be written in basically any scripting language. There is nothing in the task that called out for deno but I wanted to try it out and so I did. I basically worked on the script iteratively, doing small changes, running it, checking the output, fixing things and running again. No bundler, no complex NPM tasks. Just a simple spaghetti JS and a single binary engine to run it. It was a very refreshing experience. Using URL imports was pretty nice, I really like working like that since my preferred JS environment is not NodeJS but the browser. I can see myself transitioning all those small tools and throwaway scripts I'd do in NodeJS to Deno. People relying on NodeJS for servers and tooling for their client-side webapps might need to wait a bit longer, but for doing small tasks and scripts, I think it is quite ready and better than NodeJS IMHO. These are also good projects to give you a feel for the new runtime.

jfkebwjsbx 6y ago
For small scripts there are many languages out there which are better, with a proper standard library and pre-installed runtimes in virtually every machine. Why would someone want to use a new language and a new runtime in production scripts is beyond my understanding. Just write Python for those. Even Perl, awk or sh would be better options, and that is saying something...
- searchableguy 6y ago
  Well I can think of few. For one, if you are writing a script with external dependencies, it's more work than deno to distribute them. For python, you would need pip. Can you install any script from arbitrary urls using pip? I am not sure but I don't think you can. You also have to declare your deps for pip to figure out. With deno, it's just deno run -A url to script since dependencies are declared in the code with their respective url or file location.
  - jfkebwjsbx 6y ago
    The whole point of Python is that you don't need external dependencies for "small tasks and scripts". A production "script" requiring downloads of third-party code from external servers is already a red flag, by the way.
    - searchableguy 6y ago
      You can setup your own mirrors which don't update without audits. Any competent company would do. And I wasn't implying that production scripts shouldn't be self contained. Just placing my 2 cents on why.
      - jfkebwjsbx 6y ago
        How is maintaining mirrors of third-party code any easier, reliable, secure or maintainable than just running Python? Mind you, your Python runtime has been vetted by the Python Foundation, your upstream vendor and your company; is used by many other companies and does not require any network connections to run.
    - candu 6y ago
      One could extend that logic to argue that all package managers are red flags: after all, you're downloading third-party code from external servers; you just happen to be doing it ahead of time, rather than at runtime. In principle, there's no reason why the same supply-chain security mitigations npm and other package managers / repositories have put in place could not also be applied in this case: you just apply them at download time, same as before, except now it might result in a runtime error instead of an npm install failure. (No idea if deno does this in its current state, tbh.) Agree, however, that blindly executing third-party code without somehow vetting it is a security risk. Also, re: Python - there's a reason why libraries like requests exist; while the Python Standard Library is pretty comprehensive, the APIs it exposes are not always the most intuitive. You might be surprised at how often people pull in helper libraries to work around some of its warts - now, one could argue that maybe they shouldn't do that and should just know the built-in modules better, just as one could argue that functionality is useless unless combined with usability.
- woah 6y ago
  Python 2 or 3?
  - VWWHFSfQ 6y ago
    whichever one is on your computer
    - woah 6y ago
      Sounds like that directly invalidates the use case of small portable scripts.
      - VWWHFSfQ 6y ago
        not really. its perfectly easy to write scripts that work with py2 and 3
  - jfkebwjsbx 6y ago
    Both work. 1) Your distribution vendor most likely supports both and allows you to install both at the same time. 2) Your company has probably a policy for that. 3) Small Python scripts are trivial to make compatible with both major versions. 4) Python 2 is deprecated but supported. Just write Python 3 for new code.
    - hisham_hm 6y ago
      Python 2 was EOL this year. Short answer should be just "Python 3" by now.
- mmargerum 6y ago
  Go is my tool of choice for scripting now. Compiles fast and has an extensive standard library. I've tried using node in the past but all of the async handling turned me off. I prefer go's way of implementing concurrency with go routines.
  - jfkebwjsbx 6y ago
    Go isn’t scripting, it is compiled, which defeats the purpose.
    - lghh 6y ago
      Why does it being compiled defeat the purpose?
      - jfkebwjsbx 6y ago
        The point of scripts is to easily automate tasks without the need for a heavy infrastructure behind them in the target. If you have to install/run a pipeline every time you modify them (like C or Rust or Go or TypeScript), or you need to sort out distribution (if you use binaries compiled in another machine), or it takes a long time to compile & run (like Rust or C++), or you need to install a heavy runtime (like a JVM or .NET or v8), it defeats the purpose.
        earthboundkid 6y ago
        Go can `go run script.go` without more ceremony than that. But there are other tradeoffs: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SysadminGoVsPython https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SysadminGo...
        jfkebwjsbx 6y ago
        That compiles and then runs the resulting binary, so you still need the Go infrastructure and the latency. Go is without doubt a better candidate for scripting than things like Rust or C++, but it cannot compete with the ubiquitous and featureful Python or built-in Unix tools (even more ubiquitous, but less featureful and quite dated).
- doctorOb 6y ago
  This is a bit like saying "why would someone take a ferrari to the corner store, a honda sedan works just fine". The implementation of the task at hand is without consequence, their boss just wants X to happen even if it gets done by hand. I love these opportunities because I can use a language that I'm not getting paid to write for the 99% of of my day job. Coincidentally this happens to be python for me but i'll defend parent's right to do it in brainfuck if it makes them smile :)
BiteCode_dev 6y ago
I've felt exactly that while testing Vite (https://github.com/vitejs/vite https://github.com/vitejs/vite) this morning from Evan You, author of VueJS. Standard install, nothing to configure, instant hot reload + modern code and tooling yet no perceivable latency for anything. It felt like suddenly I could enjoy front end dev. So I get the appeal of Deno. But I know this ability to put arbitrary URLs as dependancies in the code are going to be terribly missused and abused. I can see all the tutorials that will start including them, the bad architecture decisions that will spread them accross all files, the interns that will use localhost there, the typo and domain squatting or black SEO, the rise of people just telling you to put an URL from their site (the same that tell you to curl that bash script), the split from npm, the hardship of scanning/mapping/updating dependancies, the mismatch betwen running and installing bitting you, the undebuggable tickets because of proxies/antivirus/firewalls, the cloud hosting potential for failures, some twisted scenario leading to a DoS... I know it will cause horrible technical debt down the road. My spider dev sense is tickling and I'm not going to touch this tech for 5 years, until I either see my prediction unfold, and be completly disproved by its success (but I doubt it, I've been really good in the last 10 years at spotting bad technical choices). There is a reason we have been using separation of concerns since the down of time. Declaring dependencies, installing them and importing them are 3 different concerns. They should not mix.
- miohtama 6y ago
  I am not expert on Deno. But what other frameworks and browsers are doing is to include a hash in the URL. E.g. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... Should not Deno to force the same behaviour to ensure there is less attack surface thru dependencies? I see Deno is taking security seriously.
  - BiteCode_dev 6y ago
    Sure, this will remove one problem: type/domain squatting. All the other ones remain. I can't wait for Stackoverflow spamming to get the scammers answer with a legit solution + url + hash at the top of Google search when typing the name of the package. Before that, you'd install from npm. But now, any URL is fair game. I'll get the pop corn.

jfkebwjsbx 6y ago

For small scripts there are many languages out there which are better, with a proper standard library and pre-installed runtimes in virtually every machine. Why would someone want to use a new language and a new runtime in production scripts is beyond my understanding. Just write Python for those. Even Perl, awk or sh would be better options, and that is saying something...

searchableguy 6y ago
Well I can think of few. For one, if you are writing a script with external dependencies, it's more work than deno to distribute them. For python, you would need pip. Can you install any script from arbitrary urls using pip? I am not sure but I don't think you can. You also have to declare your deps for pip to figure out. With deno, it's just deno run -A url to script since dependencies are declared in the code with their respective url or file location.
- jfkebwjsbx 6y ago
  The whole point of Python is that you don't need external dependencies for "small tasks and scripts". A production "script" requiring downloads of third-party code from external servers is already a red flag, by the way.
  - searchableguy 6y ago
    You can setup your own mirrors which don't update without audits. Any competent company would do. And I wasn't implying that production scripts shouldn't be self contained. Just placing my 2 cents on why.
    - jfkebwjsbx 6y ago
      How is maintaining mirrors of third-party code any easier, reliable, secure or maintainable than just running Python? Mind you, your Python runtime has been vetted by the Python Foundation, your upstream vendor and your company; is used by many other companies and does not require any network connections to run.
  - candu 6y ago
    One could extend that logic to argue that all package managers are red flags: after all, you're downloading third-party code from external servers; you just happen to be doing it ahead of time, rather than at runtime. In principle, there's no reason why the same supply-chain security mitigations npm and other package managers / repositories have put in place could not also be applied in this case: you just apply them at download time, same as before, except now it might result in a runtime error instead of an npm install failure. (No idea if deno does this in its current state, tbh.) Agree, however, that blindly executing third-party code without somehow vetting it is a security risk. Also, re: Python - there's a reason why libraries like requests exist; while the Python Standard Library is pretty comprehensive, the APIs it exposes are not always the most intuitive. You might be surprised at how often people pull in helper libraries to work around some of its warts - now, one could argue that maybe they shouldn't do that and should just know the built-in modules better, just as one could argue that functionality is useless unless combined with usability.
woah 6y ago
Python 2 or 3?
- VWWHFSfQ 6y ago
  whichever one is on your computer
  - woah 6y ago
    Sounds like that directly invalidates the use case of small portable scripts.
    - VWWHFSfQ 6y ago
      not really. its perfectly easy to write scripts that work with py2 and 3
- jfkebwjsbx 6y ago
  Both work. 1) Your distribution vendor most likely supports both and allows you to install both at the same time. 2) Your company has probably a policy for that. 3) Small Python scripts are trivial to make compatible with both major versions. 4) Python 2 is deprecated but supported. Just write Python 3 for new code.
  - hisham_hm 6y ago
    Python 2 was EOL this year. Short answer should be just "Python 3" by now.
mmargerum 6y ago
Go is my tool of choice for scripting now. Compiles fast and has an extensive standard library. I've tried using node in the past but all of the async handling turned me off. I prefer go's way of implementing concurrency with go routines.
- jfkebwjsbx 6y ago
  Go isn’t scripting, it is compiled, which defeats the purpose.
  - lghh 6y ago
    Why does it being compiled defeat the purpose?
    - jfkebwjsbx 6y ago
      The point of scripts is to easily automate tasks without the need for a heavy infrastructure behind them in the target. If you have to install/run a pipeline every time you modify them (like C or Rust or Go or TypeScript), or you need to sort out distribution (if you use binaries compiled in another machine), or it takes a long time to compile & run (like Rust or C++), or you need to install a heavy runtime (like a JVM or .NET or v8), it defeats the purpose.
      - earthboundkid 6y ago
        Go can `go run script.go` without more ceremony than that. But there are other tradeoffs: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SysadminGoVsPython https://utcc.utoronto.ca/~cks/space/blog/sysadmin/SysadminGo...
        jfkebwjsbx 6y ago
        That compiles and then runs the resulting binary, so you still need the Go infrastructure and the latency. Go is without doubt a better candidate for scripting than things like Rust or C++, but it cannot compete with the ubiquitous and featureful Python or built-in Unix tools (even more ubiquitous, but less featureful and quite dated).
doctorOb 6y ago
This is a bit like saying "why would someone take a ferrari to the corner store, a honda sedan works just fine". The implementation of the task at hand is without consequence, their boss just wants X to happen even if it gets done by hand. I love these opportunities because I can use a language that I'm not getting paid to write for the 99% of of my day job. Coincidentally this happens to be python for me but i'll defend parent's right to do it in brainfuck if it makes them smile :)

BiteCode_dev 6y ago

I've felt exactly that while testing Vite (https://github.com/vitejs/vite https://github.com/vitejs/vite) this morning from Evan You, author of VueJS. Standard install, nothing to configure, instant hot reload + modern code and tooling yet no perceivable latency for anything. It felt like suddenly I could enjoy front end dev. So I get the appeal of Deno. But I know this ability to put arbitrary URLs as dependancies in the code are going to be terribly missused and abused. I can see all the tutorials that will start including them, the bad architecture decisions that will spread them accross all files, the interns that will use localhost there, the typo and domain squatting or black SEO, the rise of people just telling you to put an URL from their site (the same that tell you to curl that bash script), the split from npm, the hardship of scanning/mapping/updating dependancies, the mismatch betwen running and installing bitting you, the undebuggable tickets because of proxies/antivirus/firewalls, the cloud hosting potential for failures, some twisted scenario leading to a DoS... I know it will cause horrible technical debt down the road. My spider dev sense is tickling and I'm not going to touch this tech for 5 years, until I either see my prediction unfold, and be completly disproved by its success (but I doubt it, I've been really good in the last 10 years at spotting bad technical choices). There is a reason we have been using separation of concerns since the down of time. Declaring dependencies, installing them and importing them are 3 different concerns. They should not mix.

miohtama 6y ago
I am not expert on Deno. But what other frameworks and browsers are doing is to include a hash in the URL. E.g. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres... Should not Deno to force the same behaviour to ensure there is less attack surface thru dependencies? I see Deno is taking security seriously.
- BiteCode_dev 6y ago
  Sure, this will remove one problem: type/domain squatting. All the other ones remain. I can't wait for Stackoverflow spamming to get the scammers answer with a legit solution + url + hash at the top of Google search when typing the name of the package. Before that, you'd install from npm. But now, any URL is fair game. I'll get the pop corn.