OmarIsmail

This article is amazing. I think any engineer outside of programming language builders would get something incredibly useful for it.

Not enough engineers engage with the concept of code and programming and as an industry we suffer for it. The beginning of this post does a phenomenal job of simplifying very basic but high level concepts as “what is a function” “what is a tag”.

99% or programmers don’t think about these things like this, and so get confused when these building blocks are manipulated and presented in seemingly strange ways like React components or server components or whatever. By breaking down these concepts (functions, blueprints) and having rebuilding them with simple definitions it allows the reader to start their mental model fresh and go from there.

This is a masterclass in technical communication.

Who gives a shit if it’s long. In fact I’m glad it’s long because every sentence is gold. These are deep subjects and foundational to programming and so ya, talking about them like this can take a few words.

99% of people who take the time to really read and process this post will come away as noticeably improved developers. That kind of bang for the buck is rare!

On a relative and even absolute basis the wealthy will lose substantially more money.

On a personal quality of life basis the middle class will get hit the hardest. It will impact retirement timelines, vacations, home renovations, car purchases, etc. seeing their 401k go down will make them feel poorer and want to save more and thus reduce their discretionary spending and reducing the amount of fun and entertainment they enjoy.

This is me. And fingers crossed it’ll be an uneventful few days for us both :)

You can make an exception for the pager duty providers number. That will it will always make a sound no matter what.

Mighty as an idea was cool and interesting and I hope the tech survives and continues to be developed. Fat clients have their place in the world but a solution like Mighty allows for a lot of the benefits of a fat client without a lot of the downsides.

I think this is a really interesting decision from Suhail and one not taken lightly. I think this decision is another data point that AI-infused applications are a potential new “tech platform” and we’re at the beginning of a new “mega cycle”. I.e. web2 2002-2010, mobile 2010-2020.

Folks shouldn’t be spending much energy on thinking about how Mighty may have gone wrong (and seriously the negative analysis is so boring and lame), and instead think about the new AI opportunity.

I'm going through this right now. At dayjob we have a lot of internal dependencies and libraries that are created sufficiently far from me that I treat them as third party and when things go wrong (which they do a lot) it's a nightmare to debug and work through. Easily half a day gone.

So for sideproject I'm going mostly bespoke and using very little 3rd party libraries. The result of that is there's sooooooo much boiler plate to write and it's very boring and it's hard to be motivated and productive to get through it. What's keeping me going is that once the boilerplate is done - it's mostly the foundational level of data queries + endpoints - then I shouldn't really have to touch that stuff again.

My conclusion is that there's no great answer.

Using lots of libraries is like riding a horse. It'll start moving right away but you don't have full control and you gotta find the right way to get it to do what you want, and may have to fight it if it really doesn't want to. Vs building most things yourself is like building a car. You don't go anywhere for a long time as you're building it, but once you've built it you can move very quickly and if anything goes wrong you can easily pop the hood and fix/change things up.

I think for long lived projects it's better to build the car, but also be disciplined in writing very good code + documentation. The initial build out sucks hard but that pain will get amortized over a very long future and ultimately be worth it.

And for absolutely required dependencies go with paid services. Specifically paid services where the company's primary focus _is_ providing that service. They are financially and existentially motivated to give good service, and are usually good about keeping backwards compatibility while usually staying on top of security/modernization upgrades without requiring work on your own end. A managed database is a good example of this kind of paid dependency.

The different module syntax is the problem. If we just had the standard import/export syntax from the beginning I think 99% of problems would be avoided.

Even that blogstatic "guide" is just one page.

It seems to me you're throwing a bunch of barely-built stuff at the wall to see what has traction to then actually build out. I don't think HN is a good way to do that. This now feels like a waste of everyone's time.

The idea is solid but as someone who is in the market for something like this, the product doesnt currently inspire confidence. Specifically, you’re a tool to create User Guides and yet you haven’t created a user guide for your own site. If you don’t have user guides for your own service that indicates a few possibilities:

- the tool is too difficult to use for even yourself to be worth it

- you don’t use your tool deeply so you don’t have intuitive understanding of what is needed to be improve

- you don’t actually take user guides seriously and think they are important for a company to provide

When looking at this kind of service I’m evaluating on two levels: my customers experience, and my authoring experience. By not having your own user guide filled out I’m unable to evaluate the end customer experience (search, navigation, etc).

I know you’re in beta, but I don’t know why you’d do a show HN without at least having your own user guide filled out. A big wasted opportunity.

Environment is one of the factors for my preference for fake meats, but the much bigger factor is the ethical one. Both at the fundamental level of “killing an animal for food is bad” and the larger “modern animal farming is monstrous and inflicts incalculable suffering”.

I still enjoy a burger and I can do that relatively guilt free. Totally worth it for me.

Also, this space is still very young so I expect it to improve dramatically over the coming years. Which is a great aspect about fake meats. They are a technology that can evolve and improve a great deal. Technological development with regular meat appears to result in worse treatment for animals, not a direction I want to support.

> Nowhere will a training set featuring pictures of naked children be legal.

Appropriately from the recent news stories, but it's easy to imagine at least portions of such pictures being available for medical diagnostic purposes. I've sent pictures of my children to my doctor, so presumably in the future it's easy to imagine sending pictures to an AI to diagnose which would require a suitably fleshed out (pardon the pun) training set.

We do a decent job of banning child pornography.

And bringing the two ideas together, is child pornography that is provably created by an AI still illegal?

That actually sounds pretty cool! If that's _not_ what Flow is, I hope somebody does roll with that idea.

The secret is that if you’re good enough pretty much any company can be what you want. Most people don’t really know what they’re doing so if you are good and just build stuff that is useful I’ve found that people don’t really get in your way.

If you try to ask for permission and write up docs, etc etc then it’s a pain, but if you just _do_ it resistance becomes a lot less.