HackerTrans
TopNewTrendsCommentsPastAskShowJobs

rockmeamedee

387 karmajoined 15 वर्ष पहले

comments

rockmeamedee
·3 दिन पहले·discuss
For Bun to not have torched its reputation among its users, it would have had to publish this blog post _before_ pressing merge on that PR.

That's what underlies most of the vitriolic reaction to the events, it was done really in a really rash way.

All they had to do was a)not gaslight people about your intentions when they found the branch b)publicly post the intent to do this, and then c)publish a doc like this one right before merging, ideally leaving the branch open for like a week in case anyone in the "community" finds things to fix.

Then those UB/Miri issues others found would have been "yay collaboration" boosts instead of negative issues that prove that the approach was risky/unthoughtful.

If you're going to cross a rubicon, maybe tell people a)that you actually want to do it, b)why you want to do it and c)what it looks like after you've done the rewrite.
rockmeamedee
·7 दिन पहले·discuss
Reminds me of the "mathematical proof that there is no least interesting number". Because if there was a "least interesting number", that would make it interesting: it would have this unique property of being "the least interesting".

Here each candidate for "least interesting art" loses that property in much the same way, becoming interesting by being not_viewed_much.
rockmeamedee
·पिछला माह·discuss
I don’t understand. Gitoxide exists and is great.

It might have missing pieces, but it’s easier to vibecode any needed networking additions to Gitoxide (which is maintained) than to just go and burn tokens trying to clone all of git again.

Git wants to add Rust. Gitoxide is a multi year project that’s going to be more maintained than an ad-hoc “it says it passes the test” vibeclone.

I’m not even against vibecloning things when it’s useful, but this shows no benefits. Git is a beloved tool that few people dislike, it’s not like vinext (people disliking the vendor lock-in they have with nextjs).

Also execs should keep in mind that “we burned thousands of dollars on tokens to re-create this beloved software so we can have our own copy”, even without the copyright/licensing argument, just isn’t something positive that the community will react positively to.

It doesn’t feel nice to see your favourite works cloned for no benefit. We’re past the “it was an experiment to see how far AI can go” stage now.
rockmeamedee
·पिछला माह·discuss
https://github.com/amedeedaboville/mish A mosh clone that uses QUIC as the transport layer so it can do both “unreliable datagrams” like UDP and also a TCP-like reliable stream, so it has scrollback buffer.

Also QUIC means the crypto is handled for me, no need to trust the LLM to hand roll its own crypto.

Cool Rust libraries enable this like alacritty for the terminal, and being able to have russh (rust implementation of ssh) means it works even if ssh isn’t installed (eg on windows which og mosh never supported).

Claude tested this thing forwards and backwards: e2e tests, simulated (foundationDB like) tests for the network and for tokio async thread ordering, 12 different fuzzing targets, even some light model checking on the protocol itself. Each fuzzing round found bugs.

Except for a few “it may have bugs, I have only proven it correct” scenarios I’d say it’s looking like it’ll be as trustworthy as (maybe more than?) the original. I’m really happy with it.
rockmeamedee
·4 माह पहले·discuss
What does this mean, that you can take Kimi and RL finetune it a little more and blow the big AI shops out of the water?

Would this have been extensively fine tuned, beyond what Anthropic/OAI would do themselves?

I guess this is Cursor's own benchmark, so you can finetune on your own dataset and get better results on your own specific tasks I guess.
rockmeamedee
·4 माह पहले·discuss
I had no idea, but this "wiggle" is required for an optimal approximation, it's called the "equioscillation property" [https://en.wikipedia.org/wiki/Equioscillation_theorem].

For a polynomial P (of degree n) to approximate a function F on the real numbers with minimal absolute error, the max error value of |P - F| needs to be hit multiple times, (n+2 times to be precise). You need to have the polynomial "wiggle" back and forth between the top of the error bound and the bottom.

And even more surprisingly, this is a necessary _and sufficient_! condition for optimality. If you find a polynomial whose error alternates and it hits its max error bound n+2 times, you know that no other polynomial of degree n can do better, that is the best error bound you can get for degree n.

Very cool!
rockmeamedee
·6 माह पहले·discuss
I'm interested in the topic, and the book cover looks great, so I'll probably read it.

But it seems a bit "Maintenance: For Boys". The items mentioned on this page are "the maintenance of sailboats, vehicles, and weapons", and "Soviet tanks, or tricked-out Model Ts".

No mention that for millenia we were mending our clothes, cleaning our houses, maintaining our food systems.

The reason this book sounds interesting is that maintenance is systematically undervalued, and basically in our human history pushed onto women and the lowest social classes. But the marketing material seems to highlight only the "sexy" stuff like weapons and vehicles. Where's the maintenance of washing our hands, washing our clothes, cleaning our streets?

There's this artist, Mierle Laderman Ukeles, who was the "Artist in Residence" at NYC's department of sanitation in the 70s, and tried to use conceptual art as a way to highlight the work of the department and make "maintenance art" a thing. I'm interested in that kind of re-valuing of maintenance.

I bet this book will be interesting, I just don't like the framing as "Maintenance: Of Everything" since it's clearly not the whole story. Hopefully part 2 has a broader scope and mindset.
rockmeamedee
·पिछला वर्ष·discuss
Idk man. It's a nice idea, but it has to be 10x better than what we currently have to overcome the ecosystem advantages of the existing tech. In practice, people in the frontend world already use Apollo/Relay/Tanstack Query to do data caching and querying, and don't worry too much about the occasional overfetching/unoptimized-ness of the setup. If they need to do a complex join they write a custom API endpoint for it. It works fine. Everyone here is very wary of a "magic data access layer" that will fix all of our problems. Serverless turned out to be a nightmare because it only partially solves the problem.

At the same time, I had a great time developing on Meteorjs a decade ago, which used Mongo on the backend and then synced the DB to the frontend for you. It was really fluid. So I look forward to things like this being tried. In the end though, Meteor is essentially dead today, and there's nothing to replace it. I'd be wary of depending so fully on something so important. Recently Faunadb (a "serverless database") went bankrupt and is closing down after only a few years.

I see the product being sold is pitched as a "relational version of firebase", which I think good idea. It's a good idea for starter projects/demos all the way up to medium-sized apps, (and might even scale further than firebase by being relational), but it's not "The Future" of all app development.

Also, I hate to be that guy but the SQL in example could be simpler, when aggregating into JSON it's nice to use a LATERAL join which essentially turns the join into a for loop and synthesises rows "on demand":

  SELECT g.*, 
         COALESCE(t.todos, '[]'::json) as todos
  FROM goals g
  LEFT JOIN LATERAL (
    SELECT json_agg(t.*) as todos
    FROM todos t
    WHERE t.goal_id = g.id
  ) t ON true
That still proves the author's point that SQL is a very complicated tool, but I will say the query itself looks simpler (only 1 join vs 2 joins and a group by) if you know what you're doing.
rockmeamedee
·3 वर्ष पहले·discuss
Like a non-toy version of this: https://artsandculture.google.com/story/ar-synth/7AUBadCIL5T...
rockmeamedee
·9 वर्ष पहले·discuss
I just finished watching this talk "ClojureScript for Skeptics" (https://www.youtube.com/watch?v=gsffg5xxFQI) that laid out the pros of ClojureScript and completely sold me on trying it out. Weird seeing this article about Clojure dying right after, too.

In this talk I watched, the speaker argues for ClojureScript for SPAs because it has: * an excellent standard library (great functional programming so no need for lodash or other hacks, no issues with things like map(Integer.parse), solid date support, etc) * Go-level easy concurrency * Immutable types built-in for a fast React experience (immutable.js by default) * built-in Google Closure Compiler for optimizing, (also with sourcemaps and devtools) * built-in tree-shaking (only import what you use) from Google Closure Compiler * built-in code-splitting (don't import the code for the settings page on the home page, automatically load it when the user goes there), also from Google Closure Compiler

And the talk is from 2015! So there's probably been even more added I don't know about yet.

Then again, in 2017 I feel like we have an embarrassment of riches of programming languages. I'm already playing around with Elixir (loving it), wanna try out Rust's zero-cost everythings, and have finally finishing learning Haskell on my back burner.