HN user

rpep

291 karma

https://rpep.dev/about https://github.com/rpep

Posts3
Comments100
View on HN

In practice the library ecosystem is just way behind Python. Maybe after you’re trying to optimise once you’ve worked out how to do stuff, but even the Langchain Go port is wayyyyy behind.

I live in a city with trams in the UK and that’s not how it works. There are sections that run on dedicated train lines, and sections where it runs on the street. Where it runs on the streets, priority is given over cars by switching traffic lights to red. Once the tram has passed onto the road it switches back to green so you can end up following the tram in your car.

It’s interesting because BBC Sounds replacing iPlayer Radio was one of the worst redesigns I’ve ever seen for discoverability. Even now, several years on, it’s considerably worse. Whatever the technical merits of the migration, finding radio programmes became much much harder, all while they push podcast content.

You cant use the embeddings/vector search stuff this refers to in self hosted anyway, it’s only implemented in their Atlas Cloud product. It makes it a real PITA to test locally. The Atlas Dev local container didn’t work the same when I tried it earlier in the year.

working for Rolls Royce in the middle of nowhere

Most people I know who ended up at RR live in Nottingham or the Peak District and commute in to Derby. Appreciate that’s perhaps not as exciting as London but it’s hardly a shit hole up here.

Agree on pay though. I work for a different engineering conglomerate (foreign owned) and I applied for a HPC role at RR a couple of years ago and the salary was £20k lower. The disparity would be even more now.

I’m 33, in the U.K. and my marginal tax rate is currently 66.7%, because the support you get for having children gets withdrawn between £60000 and £80000. If a promotion came up I would take it but it’s also at a point where I’m considering already dropping down to four days a week because of this. I don’t live in London so my life is very affordable. Save myself money on children’s nursery for a few years too…

https://taxpolicy.org.uk/2024/03/10/infographic_marginal_rat...

It depends on how much you want to rely on Mixins and using Serializer classes to do more than just serialise JSON. Neither of those are compulsory to use, and the more you lean into them the more inheritance you’re forced to do as soon as you need to customise the behaviour.

Bonds are much less risky too. So when interest rates were low, it made sense for investors to put money into companies because with bonds you got a tiny return guaranteed vs a high risk but potentially large payoff.

Now, bonds are guaranteeing a 5%+ return, so a non-profitable business is much less attractive as a proposition.

ModelManagers are directly coupled to one model though. You mix concerns if you need to reference other models in them.

For e.g. say you have a User model and a corresponding “Profile” model. If you need to create the profile object when the user is created, it doesn’t really feel appropriate to put that in a UserModelManager directly coupled to the User object. This is the example given from the Hacksoft Django style guide to advocate creating a service layer.

In terms of the abstraction, I totally agree and tend to be pretty pragmatic about this sort of thing.

CBV doesn't require you to do anything in particular other than implement retrieve/list/etc. methods on the GenericViewSet as needed, and get/post/etc. on GenericAPIView. You can use the convenience methods in Django and mixins, but as soon as you get beyond a simple case, they start to become a hindrance.

The only thing beyond that that I'd recommend is specifying a get_serializer_class method since it simplifies your boilerplate and plays well with drf-spectacular for generating your API documentation. I generally don't use ModelSerializer unless the logic is very simple, I've been meaning to write a blog post for a long while about avoiding it when your data model is split across two database tables.

I disagree with the idea of not having a service layer at all, because in practice, changing your data model in some way is actually pretty common, even if the API remains the same so the data coming in/out isn't changing. I've had to split models into multiple parts to add audit history on certain fields, create notifications on object creation or modification (possible but hard to follow and a visibility problem when using signals), change the normalisation on fields, etc. etc. and at this point, turning to a service layer is much more appropriate than putting methods on the model since often the data is split across multiple database tables. I also would advocate this in projects where it's Django + DRF since you generally want exactly same logic to be run through whether submitting via a form or submitting via an API.

I've also found that it's good practice to impose boundaries between apps so that they are not strongly coupled together but communicate through an interface. That way, if you need to split an app out into its own project at some point, the migration is significantly easier from a code perspective, since the implementation of the interface function is all that needs changing on the consumer side.

I had exactly the same thing last year with a previous long departed staff member having forked django-flex-fields into their personal GitHub and having made substantial changes. Porting to Django 3.2 then became a huge and costly project in itself as a result.

It’s considerably more onerous than just compiling to a single/multiple microarchitecture(s) though. Plus when you do this, you need to split out this code to be conditionally compiled so that you can support other architectures like ARM.

I dont much like this article since SIMD is not “niche” as the author says, even if people aren’t aware of it. It’s hard to pick up a single piece of software and say that “yes my overall workload overall will improve” by turning it on, but if you are aware of it, it will speed up most non-branching loop operations via auto-vectorisation.

Having had to work on software that did runtime dispatch for SIMD - there is a small performance cost to this. For most software it’s just not worth it. Compiling multiple versions is preferable but more confusing for users, and more costly for the developer in CI and build time. There are therefore good reasons not to support multiple microarchitectures and picking one released 12 years ago is a good compromise. I wouldn’t at all advocate picking AVX512 but this is not that - almost all consumer and professional grade hardware sold in the last 10 years supports AVX, and it’s unreasonable to expect vendors to continue supporting an ever shrinking niche…

I’ve experimented with it a bit and found it can’t really do anything you might consider specialist.

If I ask it detailed questions about the topic I did my PhD on, it can’t answer correctly. I worked on fluid dynamics for a couple of years in my first role, and there is a well known algorithm called SIMPLE for computing time evolution of steady state problems, and it couldn’t generate code for this even with lots of playing with prompts.

I do web stuff more these days and I couldn’t get it to output a fully working React hook in Typescript that POSTs with Axios; there was always some sort of type error.

It’s hard to say without specifics but most BLAS/LAPACK implementations today aren’t written in Fortran, they just provide a Fortran interface - it’s worth noting that BLAS/LAPACK original implementations were written in the 1970s in Fortran but they are not generally used today because other libraries with the same interface have been written that provide better performance. The open source implementations OpenBLAS and Atlas are written in C and commercial cuBLAS, rocBLAS and MKL are C++. This is also true for many other OSS scientific libraries I’ve used - Sundials, FFTW, etc.

In terms of column vs row major order - the underlying implementation will have its own default way of doing it (depends on the implementation) but you can if necessary recast matrix operations in such a way as to avoid actually doing transposes in the interface layer with the other language. so there’s not really a performance penalty as no additional work is done. CuBLAS and MKL’s BLAS implementation even let you pass parameters in about your input data’s memory layout.

Python has been around since early 90s and it’s main implementation was written in C though. It’s always had first class support for writing C extensions so it’s not illogical that wrapping functions written in other languages interface with it by targeting that C API.

All the processor specific libraries I’ve used could be called from either language family. This was certainly case for Cray LibSci libraries (which for e.g. supported Fortran BLAS and LAPACK interfaces and the equivalent C wrapper CBLAS) and MKL. Because they’re the same underlying library there is no performance difference.

What sort of architecture and libraries are you making use of where this is the case?