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

Same. Sentences structured like these tip me off:

- Here's the thing nobody tells you about fitting singularities

- But here's the part that should unsettle you

- And the uncomfortable answer is: it's already happening.

- The labor market isn't adjusting. It's snapping.


There’s also https://onedev.io/ which deserves a mention. I’ve never personally used it but it looks promising.


I too have made similar observations regarding pydantic and FastAPI.

I was evaluating various Python async http frameworks and landed on a similar stack:

- attrs/cattrs for models - starlette+uvicorn for HTTP/websocket - validation I’m still on the fence about. I’ll see how far I get with the built in validators offered by attrs. I use voluptuous at work and generally like the DX but it’s in maintenance mode.

This is purely personally preference, I’m sure devs using fastapi+pydantic are more productive in the long run. It almost feels like I’m hand rolling my own fastapi implementation but at the same time I don’t want to be too locked in to frameworks like that.

Ive been burnt by magic frameworks that do too much behind the scenes and there’s something nice about fully understanding what’s going on when you hand stitch libraries yourself.


If you like cattrs, you _might_ be interested in trying out my msgspec library [1].

It works out-of-the-box with attrs objects (as well as its own faster `Struct` types), while being ~10-15x faster than cattrs for encoding/decoding/validating JSON. The hope is it's easy to integrate msgspec with other tools (like attrs!) rather than forcing the user to rewrite code to fit the new validation/serialization framework. It may not fit every use case, but if msgspec works for you it should be generally an order-of-magnitude faster than other Python options.

[1]: https://github.com/jcrist/msgspec

</blatant-evangelism>


This looks like exactly what I've been looking for. I just want strong typing, json <-> struct and validation. Seems like it ticks all the boxes + speed benefits which is always nice. I especially find it useful that I can use messagepack for internal service chatter but still support json for external stuff and dump astuple to sqlite.


Depending on how far in you are, starlite/litestar has good documentation and offers another "batteries included" framework. Performance wise it's about the same and the stack is about the same. Fastapi suffers from the "one solo dev in Nebraska" paradigm (check out open prs and old tickets). For me the main draw of litestar is the batteries + better docs + more active development with multiple developers vs most other python web frameworks.


+1 for litestar[1]. The higher bus-factor is nice, and I like that they're working to embrace a wider set of technologies than just pydantic. The framework currently lets you model objects using msgspec[2] (they actually use msgspec for all serialization), pydantic, or attrs[3], and the upcoming release adds some new mechanisms for handling additional types. I really appreciate the flexibility in modeling APIs; not everything fits well into a pydantic shaped box.

[1]: https://litestar.dev/

[2]: https://github.com/jcrist/msgspec

[3]: https://www.attrs.org/en/stable/


I haven't heard of Starlite or Litestar before. Is one a fork of the other? Their documentation intro text is identical:

> {Litestar|Starlite} is a powerful, flexible, highly performant, and opinionated ASGI framework, offering first class typing support and a full Pydantic integration. > > The {Litestar|Starlite} framework supports Plugins, ships with dependency injection, security primitives, OpenAPI schema generation, MessagePack, middlewares, and much more.


starlite was the original name, it was recently renamed to litestar due to comments about how easily confused "starlette" and "starlite" are.


data point in favor of the renaming: while reading GP, I've assumed that "starlite" is a typo for "starlette."


I’ve seen this suggested elsewhere but without content I don’t see this working out.


The clone could use the slurped up reddit content from the various archive efforts prior. Then the clone could encourage, thru these third party apps, users to submit new content to itself, rather than to reddit.


I’ve had to stop using tmux on macOS (MacBook Pro 2018).

For some reason I kept getting extreme slowdowns/laggy behaviour when using neovim.

I’ve seen this thread: https://github.com/tmux/tmux/issues/353

I tried everything in the thread and still end up with a laggy terminal. For now I just use iterm2 with tabs but I miss my tmux.

On my personal Linux laptop, I never encounter the same lag with the same setup.


iTerm2 actually offers nice interfacing with tmux. If you run `tmux -CC` it will start a tmux session that iTerm abstracts away letting you split and switch panes as you normally would in iTerm, but still allowing you to join the tmux session on another terminal.

https://iterm2.com/documentation-tmux-integration.html


That looks interesting, I’ll have to give that a try thanks!


I also have a similar project partially done but lost steam (eatplants.app). I always think I should just finish it to make it functional.

My thinking is that logging food is annoying (weighing and tracking food you ate). I want to make a more fluid way of just selecting recipes or food and encourage a more scalable/intuitive way of eating.

Looks like a cool project you’ve built there.


I found this app a few months ago from another HN comment. Unfortunately it was slow and unresponsive. I started looking for other options and found TablePlus which I’m loving so far.

Hope they can improve, might give it another go once I have time.


This is blowing my mind. I felt like you were specifically talking about my place of work. Turns out (based on your github link in your profile), you did work there haha!

The 7 repos are gone now and a k8s cluster has replaced the swarm service. Deployments are a bit easier to manage now. It's still such slow development process to add a simple API endpoint, especially if that API has to call other DAOs. It's crazy because I feel like it's completely normalized here that dev work takes 300% longer than it should for simple features.


https://github.com/marcj/css-element-queries

I’ve had pretty decent success using this library.


> my former company's webpack builds were 30+ minutes for a relatively simple site

I’m genuinely curious what simple site would cause a 30+ minute build? Is it just one of those things that grow over time?


I wasn’t a frontend developer, so I’m not familiar with the details, but it seemed to be pretty slow from the start, but compounded as our app grew in size. I.e., there was some large coefficient associated with our web pack configuration.


How large was the bundle at the end? I'm not going to claim that webpack is fast for large applications, but I've never seen a build take longer than 3 minutes and this is for applications where our own source code was at the MB scale.


I don’t recall. We split it into multiple bundles in hopes of improving speed, but I don’t know the sizes in any case.


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

Search: