Hacker Newsnew | past | comments | ask | show | jobs | submit | bitbasher's commentslogin

I generally vibe code with vim and my playlist in Cmus.

Man I was vim for life until cursor and the LLMs. For personal stuff I still do claude + vim because I love vim. I literally met my wife because I had a vim shirt on and she was an emacs user.

I literally installed librewolf for the first time on my fresh Debian install. Couldn’t have had better timing!

The problem is in the unknowns. The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty. The unknowns in a Rust implementation means a crash/denial of service.

I know which I prefer.


There is no "arbitrary code execution and all kinds of nasty" in the Fil-C version and it profits from the decades spent fixing all the logic bugs, races, environment variable mess in coreutils.

Meanwhile, the Rust version of course is vulnerable to all of those: https://ubuntu.com/security/notices/USN-7867-1


> The "unknowns" in a C implementation means arbitrary code execution and all kinds of nasty.

In Fil-C?


isnt it x86_64 exclusive?

https://github.com/pizlonator/fil-c?tab=readme-ov-file#requi... says that the current implementation only targets Linux+x86_64 but that they see no reason it couldn't be portable.

But you're in the wrong (sub)thread; this (sub)thread is about whether it's safe.


ah, sorry about that and thanks for the link

As if Microsoft/GitHub (closed source platform) care about open source or free software…

Once you use CGO, portability is gone. Your binary is no longer staticly compiled.

This can happen subtley without you knowing it. If you use a function in the standard library that happens to call into a CGO function, you are no longer static.

This happens with things like os.UserHomeDir or some networking things like DNS lookups.

You can "force" go to do static compiling by disabling CGO, but that means you can't use _any_ CGO. Which may not work if you require it for certain things like sqlite.


You can definitely use CGO and still build statically, but you do need to set ldflags to include -static.

You can even cross-compile doing that.

Yes, indeed, I do.

You don't need CGO for SQLite in most cases; I did a deep dive into it here.

https://til.andrew-quinn.me/posts/you-don-t-need-cgo-to-use-...


> Which may not work if you require it for certain things like sqlite.

there is cgo-less sqlite implementation https://github.com/glebarez/go-sqlite it seems to not be maintained much tho


You're linking to a different version - this is the one that most people use https://github.com/modernc-org/sqlite

Yes and no, the package above is a popular `database/sql` driver for the same SQLite port you linked.

> This happens with things like os.UserHomeDir or some networking things like DNS lookups.

The docs do not mention this CGO dependency, are you sure?

https://pkg.go.dev/os#UserHomeDir


I was surprised too, that I had to check the docs, so I assume the user was misinformed.

Perhaps I misremembered or things changed? For instance, the os/user results in a dynamicly linked executable: https://play.golang.com/p/7QsmcjJI4H5

There are multiple standard library functions that do it.. I recall some in "net" and some in "os".


os.UserHomeDir is specified to read the HOME environment variable, so it doesn’t require CGo. os/user does, but only to support NSS and LDAP, which are provided by libc. That’s also why net requires CGo- for getaddrinfo using resolv.conf

There are at least a couple of ways to run SQLite without CGO.

I think the standard answer here is modernc.org/sqlite.

Careful, you're responding to the author of a wasm-based alternative.

No need to be careful. I won't bite. ;)

I remember when my greatest fear was sql injection. It’s great to see we have become more secure with our technology.

> It's a red flag for sure.

The first red flag was the repeated screenshots featuring Theo Browne, as if his thoughts or ideas carry any kind of authority.


I always used flash messages instead of toasts. I'm not sure if flash is the right term-- it's the inline message next to or above the form/element that changed or was submitted.

I thought flashes were easier to see (not only for people with special needs). As it turns out, when you make things more accessible, everyone wins.

I went through a phase where I used toasts because it felt like everyone was using them and my product/design was "old". I happily went back to flash messages when I came back to my senses.


Luke Smith had a good video that pretty much summarized what happens with projects such as Bitcoin that have noble goals to begin with; https://www.youtube.com/watch?v=0-lS8Y79L7g

Not sure if it's related-- but anyone else get a buzz or pop in their headphone/spear when loading certain web pages?

I've been curious if this is some form of browser fingerprinting or just crappy speakers.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: