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

does that mean this data center was way overprovisionedo or that grok is barely used and they could potentially kill it and just use claude?

That's pretty interesting. I was thinking about starting a new pet project and was considering doing it in Rust to learn as I never tried anything with it and after some small pocs I had the feeling it was too verbose to my taste, but wasn't sure it was just me and/or my lack of experience with Rust. Still, wonder if it's still worth it to give a shot considering other positive elements of the language.

Verbosity aside, whether or not Rust is a good fit depends on what you are doing. The language design is broadly optimized for low-level application code, like command-line utilities. If that is the use case then you are likely to have a good experience.

For high-performance and high-reliability systems code, Rust is much more of a mixed bag. In a systems context it lacks the ability to easily and ergonomically express idiomatic constructs important for safety and performance that are trivial to express in e.g. C++. When you run into these cases it can get pretty ugly.

Most people don't write this kind of systems code. What most people call "systems code" is really more like low-level applications code, where Rust excels. It is software like highly-optimized kernel-bypass database engines and similar where the limitations start to show.


It’s worth learning, in my opinion, but I’ve been writing it professionally for the better part of a decade, so my opinion may be a bit skewed.

It’s my favorite language to write, and it gets much easier over time. As a first approximation, if you’re doing something and it feels insanely difficult like the GP is talking about, try to think of a different way to do it rather than fighting it. There’s usually a way to do almost anything, but it’s more pleasant to lean into the grooves the language pushes you towards.


Rust is definitely very verbose. I think it's a fine choice -- probably even the best choice -- if you're doing systems code or if performance is your most important feature. If not, I would pass.

> performance

or less ressource hungry software


Some say verbose, some say explicit. I had the complete opposite reaction to Rust than this other person, and I don’t think I’m particularly smart so I don’t think it’s purely a matter of intelligence. Even asynchronous rust is pretty easy once you get the hang of it.

this. I really enjoyed the Niri approach when I discovered it and missed something similar for my mac. This is the best implementation I have tested so far, and while there are definitely some quirks, at least in my case I feel it completely usable as a daily driver(love the tabbed columns) kudos to maintainer and contributors


not only Safari, several other apps such as Music (which also has several annoying quirks) never understood why they did not get their own lifecycle if they have dedicated teams for each of those apps


If you're interested, it's to reduce cost. It's incredibly expensive to build something like Music or Maps. If each version is tied to an OS version, it keeps you from having to explode your testing and fixing cycle over time.


This is especially notably when you want to support all the latest OS features.

My company keeps the testing cycle smaller by only adding new OS-dependent features to its mobile app when the minimum supported OS version gets incremented and a feature is supported in every supported OS version. That means that the iOS app is only now getting features that were added in iOS 15 in 2021.


And what about the companies that thought that advertising (sorry, suggesting) their product through this channel was a good idea?


Don't assume they were in on it. Microsoft plays very weird games with platform access and traffic.


agree. I guess it's a force of habit, but I am so used to the cmd+<whatever> (specially copy & paste) shortcuts, that I configured them into my linux desktop to behave the same way


sorry, still don't get no tests as an excuse to go faster. obviously ymmv, but you will need to test your implementation somehow, and manual testing usually takes more time than running your automated tests. no need to over test, but definitely tests doesn't mean it will slow you down, unless you don't know how to test, which in that case, that's totally up to you.


I am in the same boat. I would like to buy a new m5, but being forced to keep Tahoe is preventing me to get it until they fix this clusterfuck


they already have...


Using something like duckdb could help in scenarios like this one?


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

Search: