Hacker News: _sinelaw_

New comment by _sinelaw_ in "Tsrs: A Port of TypeScript to Rust"

_sinelaw_ — Tue, 20 Oct 2026 20:54:38 +0000

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

New comment by _sinelaw_ in "Tsrs: A Port of TypeScript to Rust"

_sinelaw_ — Tue, 20 Oct 2026 20:10:54 +0000

Or we can just drop TypeScript completely and type-check JavaScript directly.

With HM-style type inference, row-polymorphism, sum types, type classes for overloading + operations, recursive types for object methods, and type annotations for edge cases.

I've been working on this since before TypeScript existed. Latest incarnation: https://github.com/sinelaw/inty

Demo: https://sinelaw.github.io/inty/ (you may need to reload once)

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:40:13 +0000

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)

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:35:54 +0000

Exactly. It's ironic that the end result is "windows is easier". Ugh.

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:34:04 +0000

Still need to handle automatic upgrades. That's my plan. I was wondering if there's a better way...

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:32:07 +0000

Flathub (not sure if these are the same people behind Flatpak) makes it clear they don't welcome these types of submissions:

https://docs.flathub.org/docs/for-app-authors/requirements

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:25:58 +0000

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.

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:23:08 +0000

It's a problem for my potential users. I don't get this "it's not your job to distribute your own software".

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:20:22 +0000

Sure, I already do offer deb/rpm via GitHub release page. My problem is ensuring users have an easy way to update

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 13:04:50 +0000

I do publish deb files in the GitHub release page. Will take a look at aptly / reprepo

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 12:52:02 +0000

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

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 11:47:17 +0000

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

New comment by _sinelaw_ in "I hate packaging my software for Linux"

_sinelaw_ — Wed, 12 Aug 2026 11:42:40 +0000

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?

I hate packaging my software for Linux

_sinelaw_ — Wed, 12 Aug 2026 11:33:48 +0000

Article URL: https://getfresh.dev/docs/blog/packaging-for-linux/

Comments URL: https://news.ycombinator.com/item?id=49270764

Points: 101

# Comments: 150

New comment by _sinelaw_ in "$100 to a Debian Developer who can get Fresh Editor into Trixie"

_sinelaw_ — Wed, 03 Jun 2026 13:21:30 +0000

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

New comment by _sinelaw_ in "Ask HN: Are you using an agent orchestrator to write code?"

_sinelaw_ — Fri, 13 Feb 2026 06:36:38 +0000

The harder problem is conflicting design choices, or duplicating similar infra. It means I need to be much more involved in steering individual agents and planning up front (waterfall style), which limits the parallelism further

New comment by _sinelaw_ in "Ask HN: Are you using an agent orchestrator to write code?"

_sinelaw_ — Fri, 13 Feb 2026 05:53:25 +0000

I did when just starting on a new project, it was working well when I had many new components to implement. But as the project matured and stabilized every new feature is cross-cutting and it's impossible to parallelize the work without running into conflicts (design conflicts, where two agents would add similar overlapping mechanisms, and also the usual code conflicts, touching the same files). Also, with project maturity I'm much more concerned about keeping it stable and correct, which is hard to do with parallel agents running amok.

New comment by _sinelaw_ in "Termux"

_sinelaw_ — Mon, 02 Feb 2026 14:05:56 +0000

It even runs Fresh so you can have a mini VSCode-like experience on your phone (pkg update && pkg install fresh-editor)

New comment by _sinelaw_ in "Show HN: PNANA - A TUI Text Editor"

_sinelaw_ — Thu, 29 Jan 2026 09:03:39 +0000

Let me know if you still have issues, I'll look into it

New comment by _sinelaw_ in "Threat actors expand abuse of Microsoft Visual Studio Code"

_sinelaw_ — Thu, 22 Jan 2026 11:45:52 +0000

Is this 'task' feature really useful? I'd say applications like IDEs and text editors should not have automatic arbitrary execution of code in the first place. 'eval' should be blocked and extensions/plugins should have only very limited power to execute external logic (such as processes for LSP) or require allowlisting manually every process.