For the best experience on desktop, install the Chrome extension to track your reading on news.ycombinator.com
Hacker Newsnew | past | comments | ask | show | jobs | submit | history | roflcopter69's commentsregister

Of course the "wait 7 days" are not a silver bullet, but it gives automated scanners plenty of time to do their work. Those automated scanners surely catch this `eval(base64.decode("..."))` stuff that some of those attacks used so in my book this dependency cooldown is a net win. I guess the skilled malicious actors will then up their game but I think it's okay to kick off an arms race between them and the security scanners in the dependency world.

That's a good point. In some level I'd prefer the delay to happen on publication of the package itself. Do any of these scanners have cryptographic attestations or similar?

I tried Swift a few months ago in a project that made use of a bunch of bigger dependencies and I was instantly shocked by the compilation times. It's quite unimaginable to me using Swift for everyday work because of that. Especially when coming from the fast compile times of Go. But it's really unfortunate because I really enjoyed writing Swift because it feels like a very well made language. But iterating on some code and trying to get quick feedback is pure pain.

Tuist is necessary for substantial projects

About the lag, I didn't bother looking into it, but I suspect they log every single action you do and require that the request to their servers was confirmed before allowing to do the next action. They probably face a lot of traffic right now, which could cause the lag. Just speculation though.

I can't help myself but see this as a very strangely written article that does not meaningfully contribute anything? Did the author didn't bother to do some basic research and just dumped a bunch of thoughts, speculation and questionable code/command snippets?

To quote from https://docs.modular.com/mojo/roadmap/

  Mojo may or may not evolve into a full superset of Python, and it's okay if it doesn't.

Definitely pixi imo. At least for me it works just as well as uv and imo does even more than uv by giving you the ability to mix dependencies from pypi.org and Conda. And the great thing about Conda is that they still build PyTorch for Intel Macs or OpenCV for macOS 11+ which is not the case for the wheels you'll find on pypi.org so it's really great if you want to build software that is shipped to a variety of old platforms.


Can highly recommend pixi. It really is the "uv but for Conda" and actually quite a bit more imo. Don't know how relevant this is for you, but many packages like PyTorch are not being built for Intel Macs anymore or some packages like OpenCV are built such that they require macOS 13+. That's usually not too much of a problem on your most likely pretty modern dev machine but when shipping software to customers you want to support old machines. In the Conda ecosystem, stuff is being built for a wide variety of platforms, much more than the wheels you'd find on pypi.org so that can be very useful.

So I can really recommend you trying pixi. You can even mix dependencies from pypi.org with the ones from Conda so for most cases you really get the best of both worlds. Also the maintainers are really nice and responsive on their Discord server.


+1 for Conda. I also have to mention pixi (https://github.com/prefix-dev/pixi) which kinda is a uv for the Conda ecosystem. Highly recommend!


Maybe a bit of a weird analogy, but y'all know about the basic advice to not come back to your abusive ex? Don't trust Microsoft to always respect you as an user, even if they now are trying to tell you they'll change and do so again. It's all just damage control PR speak.


Thanks for working on this mr_Fatalyst, this looks very promising. I'll keep an eye on this. Can't wait to dump the mess that is SQLAlchemy. Btw, you're getting a lot of stars on GitHub right now ;)


Thanks, appreciate the support (^_^)!


This is the way. For now, pyright it's also 100% pyright for me. I can recommend turning on reportMatchNotExhaustive if you're into Python's match statements but would love the exhaustiveness check you get in Rust. Eric Traut has done a marvellous job working on pyright, what a legend!

But don't get me wrong, I made an entry in my calendar to remind me of checking out ty in half a year. I'm quite optimistic they will get there.


Say what you will about Microsoft, but their programming language people consistently seem to make very solid decisions.


Microsoft started as a programming language company (MS-BASIC) and they never stopped delivering serious quality software there. VB (classic), for all its flaws, was an amazing RAD dev product. .NET, especially since the move to open-source, is a great platform to work with. C# and TS are very well-designed languages.

Though they still haven't managed to produce a UI toolkit that is both reliable, fast, and easy to use.


For big codebases pyright can be pretty slow and memory hungry. Even though ty is still a WIP, I'm adopting it at work because of how fast it is and some other goodies (e.g. https://docs.astral.sh/ty/features/type-system/#intersection...)


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

Search:

HN For You