HN user

freekh

136 karma
Posts0
Comments112
View on HN
No posts found.

This has been my theory for a while: during this autumn Apple will release a version of Apple Intelligence that runs locally and works better than ChatGPT. They will do this because 1) they do not have an offering in AI yet 2) they have amazing hardware that even now almost can pull it off on open models and this will not be possible to replicate on android for a long time (presumably)

This will crush OpenAI.

Note: I am not talking about coding here - it will take a while longer but when it is optimized to the bone and llms output has stabilized, you will be running that too on local hardware. Cost will come down for Claude and friends too but why pay 5 when you can have it for free?

I am working on the «ultimate dev ex» CMS: https://val.build/docs

GitHub: https://github.com/valbuild/val

Intro video: https://youtu.be/83bnYGIsm5g?si=5LN7dxnARrS4jNEx

What sets it apart is that it 1) stores content in TS / JS files 2) is a fully fledged CMs. It is designed to be nice to work with from the start a project (and the structure of your app changes all the time) -> when everyone works on individual PRs -> to the end when the project is decommissioned.

It needs no cloud APIs, no DBs nor caching. No query language to learn. No sign up to get started. It is fully TypeSafe and needs no type generation. You can rename and refactor content from you IDE. It works amazingly with Cursor and friends (local content and schema + strong typesafty + validation)

Currently reqs are: Nextjs and GitHub.

APIs are pretty stable. UI is in the process of a revamp. Will do a proper show hn some time in the near future.

It's entirely possible that we do become obsolete for a wide variety of programming domains. That's simply a reality…

It is not a reality since it has not happen. In the real world it has not happened.

There is no reason to believe that the current rate of progress will continue. Intelligence is not like the weaving machines. A software engineer is not a human calculator.

I really liked this article. I think all of these points, in particular the conclusion of cost vs benefit could be the same whether you were talking about formal methods or web apps. This way of seeing things, with an engineering perspective, is the exact same we (at least I) see it but we mostly do web apps.

So cool. Have wanted to add an extra battery on my Yuba Spice Curry, but it is so expensive. Love the fact that it is possible to replace the individual cell. Been annoyed that ebikes are not as serviceable as normal bikes. Signed up now :)

Even is also a common Norwegian name. Since you can have multiple first names too, you can be named Odd Even or even <sic> Even Odd.

I do that (via termux) with a onyx max boox 3. Works pretty well. I had some quality issues (got 2 dead lines on 2 devices so far) with the actual device but support has been very, very supportive so far so globally I'm very happy

It is not count() that is slow, it is iterating through the rows that is / can be slow :)

For me, the trick to basic understanding of perf in PG was exactly this: it is all about limiting the amount of rows you have to iterate over. It is true for count() but also for every other operation you do.

PG is surprisingly non-magical (at least in my experience) in that you won't get much perf for free, but on the other hand you can reason about perf & optimize pretty reliably once you come to terms with this.

Anecdoctally this happened to me the other day in my Haskell backend: had a recursive function (in the IO monad) that every ten second would take a connection of my connection pool (and since it was recursive) would not give it back to the pool. Of course it was a stupid bug, but it was hard to figure out because it would take a while before it got to that point and once it was there every call to the backend would block then timeout. I like functional programming, and yes: it was in the IO monad so not pure, but I think most applications ends up in some stateful monad even if your stack is built for functional stuff... This was 'not at scale' but it as a Haskell project it is fairly big. Point being: yes, pure apps will not havr this predicament, but even with a stack built for pureness I can see it happen quite often. Running software is messy...