Readit News logoReadit News
silverwind commented on Go is still not good   blog.habets.se/2025/07/Go... · Posted by u/ustad
xyzzyz · a day ago
Go was designed by some old-school folks that maybe stuck a bit too hard to their principles, losing sight of the practical conveniences.

I'd say that it's entirely the other way around: they stuck to the practical convenience of solving the problem that they had in front of them, quickly, instead of analyzing the problem from the first principles, and solving the problem correctly (or using a solution that was Not Invented Here).

Go's filesystem API is the perfect example. You need to open files? Great, we'll create

  func Open(name string) (*File, error)
function, you can open files now, done. What if the file name is not valid UTF-8, though? Who cares, hasn't happen to me in the first 5 years I used Go.

silverwind · a day ago
> What if the file name is not valid UTF-8, though

They could support passing filename as `string | []byte`. But wait, go does not even have union types.

silverwind commented on Node.js is able to execute TypeScript files without additional configuration   nodejs.org/en/blog/releas... · Posted by u/steren
rmonvfer · 6 days ago
I’m not a heavy JS/TS dev so here’s an honest question: why not use Bun and forget about node? Sure I understand that not every project is evergreen but isn’t Bun a much runtime in general? It supports TS execution from day 1, has much faster dependency resolution, better ergonomics… and I could keep going.

I know I’m just a single data point but I’ve had a lot of success migrating old node projects to bun (in fact I haven’t used node itself since Bun was made public)

Again, I might be saying something terribly stupid because JS/TS isn’t really my turf so please let me know if I’m missing something.

silverwind · 6 days ago
Node is much more stable than bun. bun has numerous crash bugs, something that is unheard of with Node.
silverwind commented on We shouldn't have needed lockfiles   tonsky.me/blog/lockfiles/... · Posted by u/tobr
CognitiveLens · 17 days ago
The automatic ci/cd suggestion sounds appealing, but at least in the NPM ecosystem, the depth of those dependencies would mean the top-level dependencies would constantly be incrementing. On the app developer side, it would take a lot of attention to figure when it's important to update top-level dependencies and when it's not.
silverwind · 16 days ago
Could aggregate the incrementing to for example 1 per day.
silverwind commented on Everything to know about UniFi OS Server   deluisio.com/networking/u... · Posted by u/codydeluisio
silverwind · 20 days ago
So this is basically a new version of the unifi controller software?
silverwind commented on Modern Node.js Patterns   kashw1n.com/blog/nodejs-2... · Posted by u/eustoria
solarkraft · 20 days ago
Both are very common Typescript patterns.
silverwind · 20 days ago
Maybe common in some legacy code bases. I recommend running with `erasableSyntaxOnly` for new code bases.
silverwind commented on Debian switches to 64-bit time for everything   theregister.com/2025/07/2... · Posted by u/pseudolus
jeroenhd · a month ago
You can recompile your kernel to work around the 100k-ish command line length limit: https://stackoverflow.com/questions/33051108/how-to-get-arou...

However, that sounds like solving the wrong end of the problem to me. I don't really know what a 4k JPEG worth of command line arguments is even supposed to be used for.

silverwind · a month ago
There's numerous examples of useful long commands, here is one:

    perl -p -i -e 's#foo#bar#g' **/*

silverwind commented on Show HN: Tsbro – TypeScript for the browser, no build step   github.com/stagas/tsbro... · Posted by u/stagas
orta · a month ago
tsc's code is mostly the type-checker, you want to look for a "transpiler" here, so embedding either swc, esbuild, sucrase or the like to handle the process of converting for you. I've never heard of one written in C++ but that may exist.
silverwind · a month ago
swc exists as wasm which any browser should be able to execute.
silverwind commented on NPM stylus package contained malicious code and was removed from the registry   npmjs.com/package/stylus/... · Posted by u/vandot
dale_lakes · a month ago
The malicious code had nothing to do with the stylus package. One of the maintainers of stylus published malicious code in another package, and GitHub / npmjs response was to nuke ALL packages that he was a maintainer of, including stylus.
silverwind · a month ago
The sensible action would be to remove only the malicious packages and suspend that account.
silverwind commented on Why is the Rust compiler so slow?   sharnoff.io/blog/why-rust... · Posted by u/Bogdanp
rednafi · 2 months ago
I’m glad that Go went the other way around: compilation speed over optimization.

For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.

I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.

But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.

silverwind · 2 months ago
You can have the best of both worlds: A fast, but sloppy compiler and slow, but thorough checkers/linters. I think it's ideal that way, but rust seems to have chosen to needlessly combine both actions into one.
silverwind commented on The time is right for a DOM templating API   justinfagnani.com/2025/06... · Posted by u/mdhb
hsn915 · 2 months ago
What we need is not templating. What we need is a native implementation of a virtual dom.

More specifically, a native implementation of the "patch" function:

    patch(target_dom_node, virtual_dom)
Where `virtual_dom` is just a plain-data description of the DOM.

Most of the "slowness" of the DOM come from its requirement to be a 90's era Java style object hierarchy.

Don't call it "templating". Just call it "virtual dom". Everyone knows what that means.

silverwind · 2 months ago
Virtual DOM is a useless abstraction, there are numerous libs that perform fine without it.

u/silverwind

KarmaCake day578April 6, 2013View Original