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

Yeah I've used it today quite heavily and I genuinely feel it's given me the best AI workflow yet, and I say this coming from Jetbrains + Claude Code.

Personally I felt having immediate access to the VSCode extension ecosystem to be a huge boon and I quickly got a setup to my liking.


Have you tried Cursor though? To me, that is the system to beat.


I haven't no. I could be wrong but I always saw Cursor as more of a low-code tool whereas Claude Code + IDE as the more professional combo.


AI integration into all aspects of the IDE is the killer feature of Cursor for me. Also access for $20 a month to every important model out there, and once you go over your credits, they grant you about another $25 in free credits and then you can work pretty much unlimited in Auto mode where it automatically picks the model for you.


I've been using it today and honestly I'm impressed. I seem to be the exception when I say I don't care it's a vscode fork. Having access to the extension ecosystem seems like a boon to me and I could quickly get a setup to my liking to rival my current Jetbrains Claude Code setup.

It seems to streamline my existing Claude Code workflow with a much better UI. The tab complete seems the best I've experienced and the text/image selection, adding comments and iterating on a plan is genius.

Depressing to see everyone here unable to see the forest for the trees.


I agree! It's great. Until you hit the limit, then there's literally no path to continue.

I would happily pay 20 or whatever for 4x limits. I'm very curious what they end up offering. My major reservation is side project vibes. I think it's hard to believe on this long term unless Google themselves adopt it.


I think hitting limits is a common complaint I see across all the AI tools. I used it with Gemini Pro and didn't hit such limits.


How is it compared to Cursur though?


I haven't used Cursor sorry.


This is a common sentiment because so many people use ORMs, and because people are using them so often they take the upsides for granted and emphasise the negatives.

I've worked with devs who hated on ORMs for performance issues and opted for custom queries that in time became just as much a maintenance and performance burden as the ORM code they replaced. My suspicion is the issues, like with most tools, are a case of devs not taking the time to understand the limits and inner workings of what they're using.


haha, thank you for summarising my thoughts on python package management... and very few people have mentioned poetry which is what we and most teams I know use.


I use poetry as well, but lately I've been looking at uv and had to actively stop myself because it'd be the 3rd tool I migrated to in the last 3 years.

Rust programmers seem to be lousy with ECS frameworks that never get used in any games but seem hell bent on proving that rust is the best language for game programming, and python programmers seem to break out in a case of "packaging tool building". I don't know what causes this. Perhaps some sort of pathological thinking that "I can do better"?

I really like python (and I like rust too), but if I were to take an honest look at the python packaging and environment ecosystem, I'd think that I'm being trolled. I lived through the age of setuptools.py, and while it was not good, at least there was only one approach really. Now we have a bazillion approaches that are all good, and zero consensus on what to use. Each individual tool is much better than what we had before, but the landscape has become so fractured that as a whole it's a complete shitshow.


Rust has no GUI game yet, and it’s the last heavy bastion of C++.

Therefore, I think it’s because so many Rust programmers were C++ programmers they would like to move another major stronghold over.

Pure speculation though.


The first project I built to learn rust - we are talking 2018 - was an ECS. I was speaking of personal experience in that particular jibe :)

Happily, I haven't yet been afflicted by a strong urge to build python packaging tools and inshallah I will escape this dreadful fate.


It's funny because OPs solution was his docker-compose-anywhere, which is exactly what, from my experience, I've seen so many start-ups running with. Sure it works while you're running an MVP but it's incredibly brittle for running something in production as soon as the application grows in complexity. IMO the primary draw of k8s isn't necessarily "infinite scalability" but its resilience.

I sometimes wonder how many of these post boil down to "I don't want to learn k8s can I just use this thing I already know?".


Additionally, from the website itself:

> What are the sources for the information in the database?

> InfluenceWatch

> Wikispooks

> SourceWatch

> On Think Tanks

> Conservative Transparency

> ProPublica

> Duke Reporters’ Lab


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

Search: