897 karma · joined August 26, 2022
But there's nice stuff under performance and security.
Ctrl+F gemini returns only 2.
@dang change this clickbait headline. original title is " Android 17 is here". I suggest "Android 17 is here - Android Developers Blog" since its a dev focused post.
you can? that's why go.sum exists. you can also use the replace directive for more advanced scenarios.
So they exist in many rescensions across India each with their own edits and interpolations. Some attempt has been made to create "critical" editions by taking the intersection of existing manuscripts but since there's no expectation of fidelity in transmission, we will never know what the original stories were.
So you can get even the western indologists to agree the battle of 10 kings mentioned in Rigveda very likely happened, and a Vasishtha and a Vishwamitra and a Trasadasyu existed in real life. However the epics leave out or conflict in many details with the aforementioned Vedic texts. Eg: a shantanu finds mention in Rigveda, a Parikshit and Janamejaya are mentioned in later samhitas. However there's no mention of pāndavas, kāuravas or a grand scale war. Neither there is a mention of a vyāsa / krishna dvaipayana in vasishtha's lineage in the accurately transmitted texts. It's very difficult to take Mahābhārata as an accurate historical document.
Eg: Indra would have a much larger role in original versions of mahābhārata and rāmāyana compared to Hindu popular conscience. In Ramayana he defeated kabandha, lent weapons to Rāma, and the hero is frequently compared to him as "Indra among men" - making him technically the most mentioned God in Valmiki's text (https://manasataramgini.wordpress.com/2017/02/12/the-ramaya%...).
In Mahabharata he fights equally with the krishna-arjuna in the burning of khandava episode until a truce is reached (and for reasons beyond the present redactions of the epic and owing to his prominence as ārya national god, the new capital of pāndavas is named.... Indraprastha!).
This kind of stuff is virtually unknown to AI, which reinforces the present pop understanding of the epics, which is to say super shallow and not very interesting.
Numbers 31.17-18
Define the interface and functions and let the AI fill in the blanks.
Eg: I want XYZ class with methodFoo and methodBar which connects to APIabcd and fetch details. Define classes for response types based on API documentation at ...., use localLibraryXYZ for ABCD.
This is the way I found to work well for me. I maintain a tight grip over the architecture, even the low level architecture, and LLM writes code I can't be bothered to write.
I find tab completions very irritating. They're "almost" correct but miss some detail. I'd rather review all of that at once rather than when writing code.
(you can theoretically pass "reload": true (or similar option) in launch.json for auto reload, tho I haven't felt the need to use that in my workflows.)
I find that Python decorators can do as much magic as an annotation processor - due to the dynamism of Python. Annotation processors, in most cases, produce a new class based on annotations on existing class / interface. The injection of that class is done by the DI container (unless it's a standalone annotation processor like mapstruct).
> And using any modern framework relies on these a lot.
To be fair to language designers, it's hard to avoid code generators. And they're a compelling thing compared to building proxy objects / DI / decorator / dataclass etc.. kind of functionality in language and getting it wrong.
> ... then you have to dig into source to figure out
Agree. It's not a "boring technology" yet.
> For all it's called micronaut, the produced packages are pretty huge.
How huge? And jlink or graal vm? Just curious.
> A lot of this seems to be down to hibernate,
With micronaut atleast, I remember using Micronaut Data JDBC. Anything is better than hibernate.
> In general I think that serverless is such a different paradigm from a long-running server.
Agreed.
what did you dislike? Pervasive DI? Annotations? configuration mess?
2. """You define Pydantic models for your API, then define separate ORM models for your database, then write converters between them.""" So you could've written something that let you convert between two. That would not warrant a whole new ORM.
3. """But infrastructure stuff like SQL generation, connection pooling, and row serialization is where a systems language makes sense."""
This makes no sense to me (except row serialization - maybe, but you're incurring a messagepack overhead instead). Unnecessary native dependency.