Hacker News Reader

Comment by kamranjon | Hacker News Reader

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).

View on HN

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

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.

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

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

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

So can deno

https://docs.deno.com/runtime/reference/cli/compile/

As does node, https://nodejs.org/docs/latest/api/single-executable-applica...

And even without that, high-quality module systems and tooling make your code extremely portable, for both Bun and Deno. I run a Deno server for a small project and I don't host it on Deno Deploy

Which- this is one of my favorite things about this ecosystem, and especially these projects! It's Just Code, with a single system dependency, and you can run it in one place just as easily as any other

But that means you can't corral devs into your own hosting service, which makes it a tough business to make money in

IMO these kinds of projects just can't work as a startup. They need to be either community-led, or incubated within a larger business that uses them instead of trying to sell them

Hopefully one or both can make a transition if/when their business model fails to take off

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.

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.

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.

Correct and the Patterns are repeating. Cycles. These are all transitive things. Reminder to keep some old-heads around, for perspective.

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.

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.

Reply on news.ycombinator.com