Recent submissions

Comment · 11 days ago
I assume you mean jsdoc + tsc in js type checking mode (tsc --allowJs --checkJs --strict)?

inty infers more - including generics (parametric polymorphism), while tsc is more of a simpler local inference.

inty is more strict - it accepts less programs than tsc would. This is mostly on purpose (to our benefit) as some of those programs have unsound code like array covariant (downcasting array members of the wrong type). tsc makes it easier to slip through these bugs.

And if tsc + jsdoc is good then the same question remains (do we really need the TypeScript language?)

Comment · 11 days ago
Comment · 2 months ago
You still need the distro maintainers to cooperate. And the packaging itself can be highly involved (as in the case of rust dependencies on Debian)
Comment · 2 months ago
Exactly. It's ironic that the end result is "windows is easier". Ugh.
Comment · 2 months ago
Still need to handle automatic upgrades. That's my plan. I was wondering if there's a better way...
Comment · 2 months ago
Comment · 2 months ago
If I don't make my program easy to install, many people won't even try it.

Being responsive to maintainers doesn't help if maintainers never reach out or even actively refuse to package your software.

Comment · 2 months ago
It's a problem for my potential users. I don't get this "it's not your job to distribute your own software".
Comment · 2 months ago
Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update
Comment · 2 months ago
I do publish deb files in the GitHub release page. Will take a look at aptly / reprepo
Comment · 2 months ago
"Someone else's job" doesn't help getting the software into my user's hands.

I need a solution that works for my users regardless.

Comment · 2 months ago
cargo install (the equivalent command here) is available. Downsides:

- very slow

- need to install prerequisites

- not possible on many machines (to weak, not enough disk for running builds)

Many users don't want to deal with this

Comment · 2 months ago
Hi, I'm the author of this post (and of Fresh). I've spent a lot of time getting it distributed cleanly to Linux users of all distros, and it's an uphill battle. I'm curious how other solo maintainers are dealing with this problem. Is a self updating static binary a reasonable solution?
Comment · 5 months ago
(Fresh maintainer here)

Fresh itself has a few dozen direct dependencies. About 33 of those already exist on Debian. It boils down to these missing dependencies:

- The entire oxc toolchain — oxc_allocator, oxc_ast, oxc_codegen, oxc_diagnostics, oxc_isolated_declarations, oxc_parser, oxc_semantic, oxc_span, oxc_transformer

- rquickjs, rquickjs-serde (the QuickJS plugin engine)

- ts-rs

- jsonc-parser

- rust-i18n (this one has an open ITP)

If we build Fresh without plugins enabled, it's just the last three.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton