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

hey thanks for mentioning that skill, I hadn't heard of it before but I just ran it on a non trivial codebase I've been planning to refactor and it did a great job.

I don't use a lot of "skills" so if there are others you've started using frequently I'd be curious to learn about them.


> From the perspective of high level application development, I can't see a technical use case for a language other than Rust.

Bit of a red flag if you really can't.


I know, haha. It's a bit of an absolute statement but as far as all of the features I look for in the context of creating scalable and maintainable software (especially in the age of agent-assisted coding) - Rust has been the most productive, least frustrating language I have worked with.

It's basically TypeScript but runtime exceptions are impossible. If it compiles, it works - so the _only_ thing you worry about is how you organised your code (abstractions, domains, etc) and if the logic is correct.

It saves a lot of time in PR reviews because you only really complain about logic or code organization.

By contrast, C#, Go, Java all have runtime exceptions for things like null pointers and race conditions. That means, when reviewing code, you have to be on the lookout for those things in addition to the logic and structure.

On the single threaded side, TypeScript is great, but JavaScript runtime performance and resource utilization is obscene. With Rust basically being TypeScript but without those limitations (and also natively supporting more frontend frameworks without transpilers), what is the use case for TypeScript (other than legacy software already being written in JavaScript or TypeScript)?

You can write Rust with your eyes closed and it'll probably work.


This is giving real "if all you have is a hammer" vibes.

I also have years of experience with Rust, but I moved off Rust a few years back simply because I'm sick of the anemic stdlib and lack of mature ecosystem around anything even one inch off the beaten path. Cargo is a shitshow and Rust forces you into an npm-like experience for a whole bunch of functionality that ought to be included in the box. You're juggling libraries with versions like 0.1.2 of which there's seven, none of which are feature complete and five of which are semi abandoned. Then you run into the orphan rule trying to fix or extend any of them.

I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.


> I kind of think some other language will come along, take the borrow checker, take all the type conveniences that Rust stole from OCaml that make Rust so nice, glue it all to a Python/Go/dotnet style fat stdlib, complete with an optional GC for all the things that don't actually need bare metal performance (just stick an arena in stdlib), and Rust will feel like a clunker by comparison.

That'd be a dream to me.


To turn bad short writing into good long writing you must necessarily change the content of the writing, not just the shape.


But this is the same with coding. The reason that AI can write code from a description that is shorter than the output is in large part because it makes decisions about the behavior that were unspecified in your prompt. We accept this for coding apparently, I guess because those decisions are often unimportant. We might accept it for writing too. I hope not.


Not necessarily. Poorly worded, ambiguous, confusingly ordered writing can be massively improved without changing the core content. Better setups and explanations can be longer without changing the message or meaning.

Look at it the other way, could you take a good longer message you’ve written and make it shorter and less readable for your audience while still making sense to you and containing the key points?


wasn't it thoreau who said "Not that the story need be long, but it will take a long while to make it short"

personally, I think there's a time and place for short versus long, just like there's a time and place for a 45mins TV episode versus a 2 hour marathon movie.


I'm looking in the same space: have you found anything else you're considering beyond OpenViking?


There are many more labs than that, and humans aren't designing unique scraping processes per domain.


This presupposes the ability to get a credit card and the confidence of sufficient funds when that auto payment hits.


If the alternative was paying cash, cash has an even more demanding level of confidence of sufficient funds required and it applies earlier with no flexibility.


No it applies at whatever time you choose - it's the most flexible option for a person whose wealth fluctuates frequently around a low baseline.


I don’t think I understand.

If I pay cash for everything and my cash level fluctuates down to $0 temporarily, how do I buy something right then?


  confidence of sufficient funds when that auto payment hits
How is this different than paying with cash or debit?


Because cash and debit allow you to pick the time in the month when you happen to have the ability to pay for something.

Frankly these questions astound me, do y'all really know no low income folks?


You can always use a credit card as a debit card. Pay it off to zero every day. Indeed with the very low limit cards people with bad credit can get, you kind of have to pay it down faster than the bill comes if you want to keep using it.


With cash: you must have the money when you make the purchase.

With card: you can set the cash aside at the time of purchase to pay when the card bill is due.

How does the card give you less flexibility or make it harder to pay for?


With cash you can't overcommit - you can only spend what you have - with card you can. If you are poor, overcommitting is very tempting as otherwise you will be going without things you need/want. But that temptation leads to debt.


True, cash is good if you lack discipline. For such a person, more flexibility leads to less because they misuse it in a way that reduces flexibility. It's a footgun for these people.


The incentives for developing juniors have become misaligned as the expected stay in a company dwindled from decades to years to maybe year.

It would make sense to develop juniors if most of their comp was a four year vest but that doesn't happen until later. And in your first year or two you're usually a net negative... This is even more true with AI.


Are they "tolerating" it? They literally have no choice.


They have a choice in brands at the very least.


I thought all car brands did this


Hm, the page is unreadable on brave on dark mode.


> reason vibe coding specifically prohibits reading the generated code

Wait what? Are there rules to vibe coding now? Are we no true Scotsmanning slop now?


The term vibe coding actually originated from a tweet from Andrej Karpathy and so there is actually a sort of definition of the term. He said vibe coding is where you "forget the code exists":

https://x.com/karpathy/status/1886192184808149383?lang=en

So if you "read the diff" it isn't vibe coding, at least not by Karpathy's definition.

Obviously it's not a "rule" and you can still call it vibe coding if you want to. Maybe the meaning of the term has evolved since his tweet anyway.


Well, that's literally what "vibe coding means", no?


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

Search: