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

Im confused. Are you asking how to make money or how to spend your time if money was not a concern?

Answering the second question - I can find 48hours worth of things to do in a 24 hour day and none of them would be about work or just lazying around (nothing wrong with it). Life has so much to offer!!! Yeah AI can produce things. But theres a reason id consume human generated art. And thankfully real deep mastery still takes effort and passion!!


I mean duh? At the very least wouldnt one just show upt to their job for the "non work related" activities? Or work becomes your "passive income"?


Did they? I can get a 70" "smart"-tv for a few hundred bucks with a crap load of bloatware. But I cannot get the same TV that is "dumb" at anywhere near that price point (I just want a bunch of HDMI ports that I can connect other devices into - including my laptop). Those cost a lot more from what I recall. And part of this was due to TVs being a great port-key to grab your viewing habits etc?


Oh man so many things. I wrote a bunch of cool things a few years ago (and recently too) but have been scared to publish - mainly because even though ive used them in production, I felt publishing means having high quality docs etc. So now the biggest vibe-coding use case is to bring everything I wrote in the past to be "publish-ready".

Here are a few things:

Notations - A carnatic music notation parser, editor and renderer for the web https://github.com/panyam/notations

Galore - A LR parsing playground and library (used by Notations DSL above) https://github.com/panyam/galore

A few protoc plugins (I am very much grpc proto first):

protoc-gen-go-wasmjs (https://github.com/panyam/protoc-gen-go-wasmjs) - A protoc plugin for creating wasm bindings out of your grpc services so you can have your "go based backend logic" on the browser:

protoc-gen-dal (https://github.com/panyam/protoc-gen-dal) - A converter between protoc messages and datastore messages so you avoid writing API <-> DB Models.

Weewar (https://github.com/turnforge/weewar) - A clone of a favorite game of my from the 2000s just for fun. Still in progress.

Plenty more but just dusting off old things has been my biggest thing lately and in the process building tooling to standardize my next gen of apps/sites etc.


There are different degrees of "ai wrote all my code". A very crappy way of doing it is to keep on one shotting it expecting it to "fall on the right solution" - very much infinite monkeys, infinite typewriters scenario.

The other way is to spend a fair bit of time building out a design and ask it to implement it while verifying what it is producing then and there instead of reviewing reams of slop later on. AI still produced 100% - just that it is not as glamorous or as marketing friendly of a sound bite. After all which product manager wants to understand refactoring or TDD or SOLID or design principles etc?


I really don't understand the fetishisizing of the demise of software engineers. Are other knowledge workers like doctors or lawyers going to be exterminated by AI? Or is there even a fantasizing of their demise? The only reason I can think of is shmchaudenfreud (it is relatively barrierless to get into and pays pretty well) and more importantly imo doesn't have cabals like other professions do.

Btw I love using my Claude code to crank out product but I don't get off looking for the day when engineers are a dead breed!


> I really don't understand the fetishisizing of the demise of software engineers.

I don't think it's "fetishisizing," it's fear. You have a bunch of comfortable software engineers suddenly realizing they may be in for the same fate as travel agents and blue-collar factory workers.


Doctors and lawyers are also going away, it’s just harder to see as they’re not exposed as much to this technology yet, it’ll be more of a “flip a switch” moment for them.

Doctors might fare better since there are laws and regulations that require them.


Frankly I really don't know what id don't not in tech. Closest I van think of is some kind of mathematician but don't even know what those "jobs" look like. Academia might be another. But these are all tech adjacent aren't they?


This. Companies are chomping at the bits about developer productivity and how they can do 10x more. What is not clear even if they can fire 90% of their engineers (assuming the 10x productivity gain is real), how are they expecting that even a tiny sliver of that 90% cannot replicate the products - with AI? And if we are in such a world how are those companies' valuations justified any more?

I am really excited at indie software again!


Author here. For those wondering - Claude Code was used but not in the "generate me this huge X with a single shot prompt after 8 hours of thinking" mode :).


I really like the idea of it. My dream has always been to work with "types" first and foremost across any and all languages (yep it is a dream). And little tools like these are really nice to see push that boundary.

One feedback - if you are truly comparing with "other" tools - you should be looking at grpc and protoc plugins. I have used to great effect for things like:

1. Generating wasm bindings for grpc services

2. Generating "data access layer" types so you can choose how a api proto is transformed to a data domain type and vice versa

3. MCP bindings for APIs

4. GraphQL/BFF bindings with multiple services

5. All of the above "across" langauges.

The tooling is fantastic and extensible - if you are ok to start with a proto view of your world - it sounds wierd and like an N+1 problem but once you are used to it it is surprisingly fun (ok we may have different ideas of fun)


I totally agree a proto first approach to your types can pay back in dividends if you need to serialize over different wires.

This project admittedly was developed to solve a specific need in an existing codebase with a lot existing types.

The codebase is also mostly maintain by the backend Golang engineers. Letting them use their native type system increases adoption and buy in.


Totally - The other really nice thing about Golang "type-system" ecosystem is their native ast in the stdlib. You can do so many amazing things from there. Infact if you pledge your life to Go (which I think I have atleast for now) starting from Go and generating everything outwards is not necessarily a bad strategy.


On this “types first across languages”, I’ve been hacking on something in that vein called Kumi (typed calculation schemas compiled to Ruby/JS). Tiny demo here https://kumi-play-web.fly.dev


Hot damn. Id love to hear the origin story of this.


I am still thinking about some blog post about all the journey but I have never wrote one of those, but see here some write-up I did on a reddit post https://www.reddit.com/r/Compilers/s/osaVyUgvUf


GraphQL has been my holy grail for this. Easy to grok, easy to build types for various languages and keep everything in sync.


GraphQL is awesome if you are a frontend engineer. GraphQL is terrible if you are a backend engineer - https://bessey.dev/blog/2024/05/24/why-im-over-graphql


Eh, a lot of those problems have solutions, and some are more theoretical.

Yes, if you design your graph to allow something like `tags -> relatedTags -> relatedTags` ad infinitum you can let your clients build a performance problem. So why not have just a top-level `getRelatedTags(tagName)` query? Or a `getRelatedArticles(articleId)` query? Just because you can have things nested doesn't mean you need to have all the things nested.

The bulk of our REST API is backed by some Rails gem, which allows for a `fields` param. Those `fields` can be deep. As in you could write `getComments?id=1234fields=user.orders`, but do you know what we do? Don't expose `orders` as a field on `User`.


> Don't expose `orders` as a field on `User`.

Why not use Open API then?


- I've never found any openapi/ swagger generated client as easy to use as a graphql client

- graphql solves a lot of other problems when querying microservices

- graphql gives us PR-level alerts on whether any schema changes are safe

- graphql actually manages our front-end query caching / updating quite nicely


Type-first is cool. But I think I'll always aim to avoid gRPC, at least in part because grpc-web was so completely broken. I also have an instinctive aversion to binary formats. YMMV, just my PoV.


I’ve had a lot of success with grpc web. Had to patch a couple of things along the way. My biggest misgiving is thinking having bigints would be a good idea (it is not a good idea). Aside from that though, I’ve been happy with it. What felt broken to you?


One thing I still struggle to this day is the float/long conversion from json <-> proto. It somehow works and I still untangle the feeling of magic.


Its generated "TypeScript"... wasn't.


+1 Couple of things I really hate about proto - No generics/templates. No composition of services or mixins (you do have composition in messages but that feels very limited). Also the clunkiness around having to declare more things (try a repeated map field or a map of repeated fields).

My comment about protos was just the spec (and was seperating the binary formats as a different concern). But your concerns are pretty valid.


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

Search: