HackerTrans
TopNewTrendsCommentsPastAskShowJobs

oparin10

no profile record

comments

oparin10
·12 เดือนที่ผ่านมา·discuss
Apparently, it's not even close.

According to https://hn.algolia.com/:

- "show hn" "nft" – 151 results

- "show hn" "blockchain" – 479 results

- "show hn" "crypto" – 782 results

- "show hn" "llm" – 2,363 results

- "show hn" "ai" – 13,128 results

These numbers were originally posted by the very active user simonw just 9 days ago [0].

Since then, they've increased to:

- "show hn" "llm" – 2,417 (+54)

- "show hn" "ai" – 13,376 (+248)

- "show hn" "vibe coded" – 23 (past month)

That’s about 6 LLM-related and 27 AI-related posts per day, just in the "show hn" category.

When I first saw this thread earlier today, there were 12 AI-related posts on the front page. Even more oddly, threads unrelated to AI somehow still end up getting hijacked by AI-related comments.

I use AI and find it very useful, but I really don’t see the reason to bring it up all the time. Not everything needs to be framed around AI, and constantly forcing it into unrelated discussions just dilutes real conversations. It feels less like enthusiasm and more like obsession.

Honestly, I wouldn’t be surprised if there is a non-negligible amount of astroturfing going on across HN.

[0] – [Data on AI-related Show HN posts - simonw's comment](https://news.ycombinator.com/item?id=44484996)
oparin10
·ปีที่แล้ว·discuss
That tracks. Intel's updated AVX10 whitepaper[1] from a few months back seems to confirm this. It explicitly states 512-bit AVX will be standard for both P and E cores, moving away from 256-bit only configs. This strongly implies AVX-512 is making a proper comeback, not just on servers but future consumer CPUs with E-cores too. Probably trying to catch up with AMD's wider AVX-512 adoption.

[1] - https://cdrdv2.intel.com/v1/dl/getContent/784343 (PDF)
oparin10
·ปีที่แล้ว·discuss
If all you need is a good starting point, why not just use a framework or library?

Popular libraries/frameworks that have been around for years and have hundreds of real engineers contributing, documenting issues, and fixing bugs are pretty much guaranteed to have code that is orders of magnitude better than something that can contain subtle bugs and that they will have to maintain themselves if something breaks.

In this very same post, the user mentions building a component library called Astrobits. Following the link they posted for the library’s website, we find that the goal is to have a "neo-brutalist" pixelated 8-bit look using Astro as the main frontend framework.

This goal would be easily accomplished by just using a library like ShadCN, which also supports Astro[1], and has you install components by vendoring their fully accessibility-optimized components into your own codebase. They could then change the styles to match the desired look.

Even better, they could simply use the existing 8-bit styled ShadCN components[2] that already follow their UI design goal.

[1] - https://ui.shadcn.com/docs/installation/astro [2] - https://www.8bitcn.com/
oparin10
·ปีที่แล้ว·discuss
Yes, I agree, that's likely a big factor. I've had a better LLM design experience using widely adopted tech like TypeScript/React.

I do wonder if the gap will keep widening though. If newer tools/tech don’t have enough training data, LLMs may struggle much more with them early on. Although it's possible that RAG and other optimization techniques will evolve fast enough to narrow the gap and prevent diminishing returns on LLM driven productivity.
oparin10
·ปีที่แล้ว·discuss
I've had the opposite experience. Despite trying various prompts and models, I'm still searching for that mythical 10x productivity boost others claim.

I use it mostly for Golang and Rust, I work building cloud infrastructure automation tools.

I'll try to give some examples, they may seem overly specific but it's the first things that popped into my head when thinking about the subject.

Personally, I found that LLMs consistently struggle with dependency injection patterns. They'll generate tightly coupled services that directly instantiate dependencies rather than accepting interfaces, making testing nearly impossible.

If I ask them to generate code and also their respective unit tests, they'll often just create a bunch of mocks or start importing mock libraries to compensate for their faulty implementation, rather than fixing the underlying architectural issues.

They consistently fail to understand architecture patterns, generating code where infrastructure concerns bleed into domain logic. When corrected, they'll make surface level changes while missing the fundamental design principle of accepting interfaces rather than concrete implementations, even when explicitly instructed that it should move things like side-effects to the application edges.

Despite tailoring prompts for different models based on guides and personal experience, I often spend 10+ minutes correcting the LLM's output when I could have written the functionality myself in half the time.

No, I'm not expecting LLMs to replace my job. I'm expecting them to produce code that follows fundamental design principles without requiring extensive rewriting. There's a vast middle ground between "LLMs do nothing well" and the productivity revolution being claimed.

That being said, I'm glad it's working out so well for you, I really wish I had the same experience.
oparin10
·ปีที่แล้ว·discuss
If you're willing to go the meta programming route, Rust is pretty flexible too. You can literally run python inline using macros.[1]

In my experience as someone that has been using Rust for a few years (and enjoys writing Rust) the biggest issue regarding adoption is that async Rust just isn't there yet when it comes to user experience.[2]

It works fine if you don't deviate from the simple stuff, but once you need to start writing your own Futures or custom locks it gets to a point that you REALLY need to understand Rust and its challenging type system.

[1] - https://github.com/m-ou-se/inline-python

[2] - https://blog.rust-lang.org/images/2024-02-rust-survey-2023/w... | (Full Survey: https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...)