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

can we make everything constant like C# does please

Models.GeminiNano04

boom


That would be like making a constant for every nuget package/version tuple: unworkable because new versions and packages come out all the time.

Or making constants for every device manufacturer you can connect to via web Bluetooth.


What’s the point in JavaScript? At the end of the day that’s still equivalent to Models[“GeminiNano04”]

In C# you can’t compile a reference to Models.Potato04 unless Potato04 exists. In JS it’s perfectly legal to have code that references non-existant properties, so there’s no real developer ergonomics benefit here.

On the contrary, code like `ai.createTextSession(“Potato:4”)` can throw an error like “Model Potato:4 doesn’t exist, try Potato:1”, whereas `ai.createTextSession(ai.Models.Potato04)` can only throw an error like “undefined is not a Model. Pass a string here”.

Or you can make ai.Models a special object that throws when undefined properties are accessed, but then it’s annoying to write code that sniffs out which models are available.


Formatted a bit.


Aiohttp is too risky to code,and it is only good if you are only one working on that project, or you are working with good friends of yours.

Give it in a hands of bad programmer, you are fucked harder than any pornstar I have ever and yet to seen in my 21 year lifespan.

You are right about pip too, I don't know how did they achieve to come with a package manager that is worse than NPM. Such a feat.


pip got frog boiled into it.

Maven is a correct package manager. Maven is able to get a global view of the metadata for all of the packages that conform to the specification so it can find a correct solution for dependencies before it downloads any JARs.

Historically, Python used egg files that required you to run the setup.py (and download dev dependencies) before you knew what the dependencies of a package are. This has the real advantage of being able to change your dependency list based on your environment (say loading a GPU-enabled or platform-specific version of a dependency) but "doing the right thing" would involve doing all this work in isolated environments and doing an awful lot of work.

Thus you get the "optimistic" approach used by pip which is to start installing packages one at a time and hope for the best. There is no correct strategy to recover when it paints itself into a corner.

Almost all pypi packages are wheels now and they just introduced the ability to download just the metadata file (a few years back when I was struggling with Python packaging at a startup I did find you could accomplish the same with two or three http range requests since you can find the superblock and directory information at the end of the wheel and then fetching the metadata is easy.) If a package is only available as an egg you can do what anaconda does which is make a wheel of it for your specific configuration and stash it in your private repository.

We might see a correct system emerge out of this, but...

Python has suffered from people who think an 80% or 90% correct solution is acceptable but that's just wrong. Until ChatGPT came along nobody thought an 80 or 90% sorting algorithm is acceptable. Certainly people could decide they need or don't need certain features (for instance pyenv) but there are certain things that are either wrong or right and you can either invest a finite amount of effort into getting things right or struggle forever pushing bubbles around under the rug.

Python also needs a good answer for environmental variation. For instance there is scikit-learn and there is a version of scikit-learn compiled against Intel's MKL library. The latter package should be tagged as a substitute for the first so that somebody who wants to use it can swap it out without making any changes to the package configuration file (can't do that because you don't want to check those changes into version control.) There are some affordances for packages having optional features but these just aren't adequate to the task.


Yeah I know, even smallest feature "json schema" made my jaw drop in Pydantic. Maybe we had it in V1 too, but it works so seamless now, especially too useful with MongoDB. As you said, there are so many absurdly things that I couldn't even dive in.

...I will tell my boss to use v2 on new project lol.

For the first part, dude my head is aching so hard that its at a point to kill me. I will comeback to you when I am somewhat clear-minded.


Even, it's only enforced in routing functions.

Outside of it, like utility packages, MongoDB or such so, you are not enforced, go with whatever you want.

...guess what my coworkers prefer! urgh.


Yes that is right too.

Dynamic typed languages always feels like I am 6 again, with my crayons all over the place, doing random bullshit go till something sensible comes out.

Good luck finding what is wrong if a bug occurs, good luck if you will refactor it and think how can you replace it, how can you rewrite it without destroying the whole aesthetic of the code. just like my parents trying to figure out how will they renew the wall after I draw a huge chunk of random shit to the wall with my crayons.


Yeah, at least getting used to signings might come useful in the future.


I am trying to work with MWS, and AWS SDK of GoLang horribly fails when tried to use standalone (I only need the signer part), but oh my oh my.

https://github.com/canercetin-randomguy/club-noira/blob/main...

This is only the auth&sign part. and it doesnt work. and it is already 150 LoC. god.


Everything from a business perspective always sounds non-sense to me.

I cant even find a library or language to code front-end, like I am burning my time since six days to find something that is dev-friendly. Everything is just, is it secure or fast? yeah ship it, we dont care about how developers feel about it.

really sad.


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

Search: