3 ms·

I use Deno all the time... but it might not be exactly how it's marketed... Anytime I need to etl some data or transform a bunch of JSON or things of this natu

I use Deno all the time... but it might not be exactly how it's marketed... Anytime I need to etl some data or transform a bunch of JSON or things of this nature - I use Deno. It's like a glue language for me at this point. I don't need to focus on configuration or any setup like this - I just create a new dir and I'm off. This article seems very hyperbolic to me - I still find a bunch of features within deno really helpful and there is still a ton of activity on Deno itself (Had a release yesterday) and many of the internal and community libraries in it's ecosystem like Postgres and Redis (which both had a release within the last week).

edoceo 1y ago
I read this same thing 25+ years ago. But we said Perl not Demo. Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.
- 9d 1y ago
  I'll never understand how anyone ever liked Perl. I remember before PHP came out and Perl + CGI was what all the forums used, and that kind of made sense before Node.js + TypeScript + Nginx were a thing (maybe). But for scripts? I mean, I guess that it makes sense as a sort of bash on steroids, but at that point, why not have something more structured? Then again, that's around the time that Lua, Ruby, Python etc were all being invented, and for that exact use-case, to be a better scripting language that bash or Perl. But... why even use Perl as an intermediate step? Why not just say "hmm, bash is too simple for this... I'll write a --" oh, I think I get it now. Your only option was Perl for a while, if you didn't want to write a full fledged C or C++ script, which would be much more verbose and unforgiving.
  - xyzzy123 1y ago
    Perl's sweet spots were CGIs & sysadmin. The advantage for sysadmin was easier portability in the days when there were a ton of flavours of UNIX systems. The ergonomics & distribution of Perl in the 90s were unmatched, Ruby, Python, Lua were niche in comparison. The other killer feature was CPAN, the Perl community basically invented language package management and everyone else copied it.
    - edoceo 1y ago
      Correct and the Patterns are repeating. Cycles. These are all transitive things. Reminder to keep some old-heads around, for perspective.
  - pjmlp 1y ago
    It is a safer C, as Perl traditionally exposed the whole UNIX/POSIX API surface, and most tasks that grew out of a simple shell script didn't need to be written in straight C with all its issues managing strings and arrays. Eventually Python became a better alternative, however for me it was mostly because I had enough of sigils, the way reference works and the hacky way of doing objects with blessed references. And as the sibling comment points out CPAN. The previous generation of Nokia NetAct infrastructure software as originally written for HP-UX, was a mix of CORBA C++ and Perl, and by 2007, it was still the main implementation. Nowadays it has been rewriten into Java.
  - tpm 1y ago
    Perl is a great language in the right hands. In a previous job the whole software system for a successful gambling company (sans the publicly available website, that was PHP and later Java) ran on Perl, central server and hundreds of branch servers (and clients), the branch software was able work autonomously if the connection to the central one was down. Everything was fast, stable and there was a total of 4 of us working on it (2 with PhDs). Right about when I was leaving it was decided there will be a transition to Java (won't go into the reasons for that) and the last programmer headcount I know of was more then 20.
brundolf 1y ago
It's amazing for scripting, I use it for that all the time too. Just the basic premise of "we can have nice things [static types and a standard library] in scripts" is lovely I hope it doesn't die, but I always thought the business model was going to be tough. Bun seems to be eclipsing Deno for sure, mainly due to its embrace of any and every syntax/feature/ecosystem, which makes me sad because Deno's opinionated stance was what had me so excited to begin with
- teg4n_ 1y ago
  Deno has at least attempted to have a business model. Oven/Bun has none in sight and I am having a hard time seeing how they will be any more successful with getting people to pay them money.
  - brundolf 1y ago
    My understanding was it was basically the same business model: make a runtime people love, add some APIs that node doesn't have, and then offer an integrated hosting platform which supports all of those out of the box and hope people pick it instead of running their code elsewhere We shall see
    - teg4n_ 1y ago
      One problem with that strategy is Bun can compile your whole server into a single executable. that’s like the simplest thing in the world to host
      - Imustaskforhelp 1y ago
        to be honest, that single executable is nothing but the bun runtime packed with the code. Theoretically a better approach could be (if we are talking about serverless providers supporting bun) is that we can compile it into bytecode and then just run a command with bun to run that bytecode and it would be faster. And to be honest, this feature is also available in deno and maybe its even coming to node IIRC, but bun supports bytecode in the executable whereas deno doesn't. I am never trying deno again, I liked their security model but it has really messed up with my ~/history and I had to type so much context to get suggestions and simple minute changes (lets say I don't want --A and I want in one command --net-only and in the second command some different flag and now I can't really see my suggestions, I don't know maybe a skill issue but when I wrote a deno code which required me to write code and I had atleast ran it 50 times while developing it. Yeah it was a nightmare, never trying that again

edoceo 1y ago

I read this same thing 25+ years ago. But we said Perl not Demo. Use the right tool. Right means reasonable and productive. Let folk who don't ship argue stack. While they're flapping, you are sailing.

9d 1y ago
I'll never understand how anyone ever liked Perl. I remember before PHP came out and Perl + CGI was what all the forums used, and that kind of made sense before Node.js + TypeScript + Nginx were a thing (maybe). But for scripts? I mean, I guess that it makes sense as a sort of bash on steroids, but at that point, why not have something more structured? Then again, that's around the time that Lua, Ruby, Python etc were all being invented, and for that exact use-case, to be a better scripting language that bash or Perl. But... why even use Perl as an intermediate step? Why not just say "hmm, bash is too simple for this... I'll write a --" oh, I think I get it now. Your only option was Perl for a while, if you didn't want to write a full fledged C or C++ script, which would be much more verbose and unforgiving.
- xyzzy123 1y ago
  Perl's sweet spots were CGIs & sysadmin. The advantage for sysadmin was easier portability in the days when there were a ton of flavours of UNIX systems. The ergonomics & distribution of Perl in the 90s were unmatched, Ruby, Python, Lua were niche in comparison. The other killer feature was CPAN, the Perl community basically invented language package management and everyone else copied it.
  - edoceo 1y ago
    Correct and the Patterns are repeating. Cycles. These are all transitive things. Reminder to keep some old-heads around, for perspective.
- pjmlp 1y ago
  It is a safer C, as Perl traditionally exposed the whole UNIX/POSIX API surface, and most tasks that grew out of a simple shell script didn't need to be written in straight C with all its issues managing strings and arrays. Eventually Python became a better alternative, however for me it was mostly because I had enough of sigils, the way reference works and the hacky way of doing objects with blessed references. And as the sibling comment points out CPAN. The previous generation of Nokia NetAct infrastructure software as originally written for HP-UX, was a mix of CORBA C++ and Perl, and by 2007, it was still the main implementation. Nowadays it has been rewriten into Java.
- tpm 1y ago
  Perl is a great language in the right hands. In a previous job the whole software system for a successful gambling company (sans the publicly available website, that was PHP and later Java) ran on Perl, central server and hundreds of branch servers (and clients), the branch software was able work autonomously if the connection to the central one was down. Everything was fast, stable and there was a total of 4 of us working on it (2 with PhDs). Right about when I was leaving it was decided there will be a transition to Java (won't go into the reasons for that) and the last programmer headcount I know of was more then 20.

brundolf 1y ago

It's amazing for scripting, I use it for that all the time too. Just the basic premise of "we can have nice things [static types and a standard library] in scripts" is lovely I hope it doesn't die, but I always thought the business model was going to be tough. Bun seems to be eclipsing Deno for sure, mainly due to its embrace of any and every syntax/feature/ecosystem, which makes me sad because Deno's opinionated stance was what had me so excited to begin with

teg4n_ 1y ago
Deno has at least attempted to have a business model. Oven/Bun has none in sight and I am having a hard time seeing how they will be any more successful with getting people to pay them money.
- brundolf 1y ago
  My understanding was it was basically the same business model: make a runtime people love, add some APIs that node doesn't have, and then offer an integrated hosting platform which supports all of those out of the box and hope people pick it instead of running their code elsewhere We shall see
  - teg4n_ 1y ago
    One problem with that strategy is Bun can compile your whole server into a single executable. that’s like the simplest thing in the world to host
    - Imustaskforhelp 1y ago
      to be honest, that single executable is nothing but the bun runtime packed with the code. Theoretically a better approach could be (if we are talking about serverless providers supporting bun) is that we can compile it into bytecode and then just run a command with bun to run that bytecode and it would be faster. And to be honest, this feature is also available in deno and maybe its even coming to node IIRC, but bun supports bytecode in the executable whereas deno doesn't. I am never trying deno again, I liked their security model but it has really messed up with my ~/history and I had to type so much context to get suggestions and simple minute changes (lets say I don't want --A and I want in one command --net-only and in the second command some different flag and now I can't really see my suggestions, I don't know maybe a skill issue but when I wrote a deno code which required me to write code and I had atleast ran it 50 times while developing it. Yeah it was a nightmare, never trying that again