TehPers @ TehPers @beehaw.org

Posts

0

Comments

818

Joined

2 yr. ago

Python can also be used for large codebases (thanks uv), but I agree that Rust is better suited to the job.

I agree here. I always find it difficult to navigate a Go codebase, especially when public members just seem to magically exist as opposed to being explicitly imported.

Quoting OpenAI:

Our goal is to make the software pieces as efficient as possible and there were a few areas we wanted to improve:

• Zero-dependency Install — currently Node v22+ is required, which is frustrating or a blocker for some users
• Native Security Bindings — surprise! we already ship a Rust for linux sandboxing since the bindings were available
• Optimized Performance — no runtime garbage collection, resulting in lower memory consumption
• Extensible Protocol — we've been working on a "wire protocol" for Codex CLI to allow developers to extend the agent in different languages (including Type/JavaScript, Python, etc) and MCPs (already supported in Rust)

Now to be fair, these dashes scream "LLM generated" for their entire post. Regardless, if these really are their reasons:

• Zero-dependency Install - there are a ton of languages where this is true. Self-contained installs are possible in Python, C#, Rust, C++, etc. Go is one option here too, but doesn't really provide anything more than the rest of these languages.
• Native Security Bindings - they supposedly already do this in Rust
• Optimized Performance - this seems overblown on their part in my opinion, but no runtime GC seems to constrain us to C, C++, Rust, and some others like Zig. Go, C#, Python, etc all do runtime GC. Regardless, in my opinion, runtime GC doesn't actually matter, and all of these options have enough performance (yes even Python) for what they need.
• Extensible Protocol - this is doable in many languages. It seems to me here that they already have some work in Rust that they want to use.

As for the difficulty in making a CLI, clap makes CLIs dead simple to build with its derive macro. To be clear, other languages can be just as easy (Python has a ton of libraries for this for example including argparse and Typst).

Personally, if I were to choose a language for them, it'd be Python, not Go. It would have the most overlap with their users and could get a lot more contributors as a result in my opinion. Go, on the otherhand, may be a language their devs are less familiar with or don't use as much as Rust or other languages.

On the other hand, I'd love to see more Muslim representation in our government, especially if it can keep this flamboyant (so-called) Christian nonsense in check.

If everything got updated like this, then that's an awesome change. What made Aero so nice was that it didn't interfere with legibility, while Glass threw legibility out the window. Striving for a proper foreground to background contrast ratio should be the bare minimim for a company like Apple, and this improves that significantly.

I agree, it's hard to tell what is needed here. But to add - if you're looking to leave your country, then finding a community of people who have done that will be your best resource to start with.

If you're looking for mental health resources outside of your country, in the US we are paying $150/session out of pocket (for a highly specialized therapist that insurance won't cover because insurance is a scam), but there are plenty of resources online to get you started and almost certainly a free or low cost program depending on your circumstances.

If you're looking for an education or a higher paying job, you may be able to pick up experience and learn on the job depending on the field, and you can also contract on the side for many jobs if you're able to self-teach from online resources (web dev comes to mind here).

If you're looking for some other specialized kind of help, you'd need to be more specific about the problem. It doesn't have to be as specific as "I live in Pakistan and want to move to Norway but Pakistan issues visa in an absolutely absurd manner" or whatever, but "moving from one country to another" would probably be enough (for example - I don't know your specific circumstances).

Beans is insane, but rotation might fix that deck. Overlord Beans will still be a deck, but you lose Leyline Binding, and Ride's End isn't close to being a replacement.

I could see Beans being banned, but I think I would be willing to see what it does post-rotation first.

Omniscience is strong but gets bodied by GY hate. It's just too hard to run counters to decks other than aggro because while Omniscience wins on turn 4, these aggro decks win on turn 3 (or practically win, just short a burn spell). I don't think it needs anything done to it. It also isn't really new to have a fast combo deck. The consistency is the main issue, and I'd rather see Ephara's Dispersal banned before Omniscience or Abuelo's Awakening. If standard slows down enough for a control deck to exist, it'll naturally push Omniscience combo down the tier list.

WOTC tried too hard to sell cards and ended up breaking standard to the point that no new sets can even make an impact anymore. I know they won't fix it if the previous B&R says anything, but IMO they need to go full Eldraine on this format and ban a ton of cards before it'll be fixed.

I don't see the problem? This format looks super diverse. You have the red aggro deck, the blue-based aggro deck (with red), and the fast paced combo decks (that are blue/red aggro decks).

Plus, to quote WOTC directly:

Standard is flourishing

Honestly this is probably one of the few foreign hacking campaigns they could crowdsource funds for from the target country. Imagine if they had a Patreon to keep it going.

(Yes)

Rust does not check arrays at compile time if it cannot know the index at compile time, for example in this code:

 rs

    
fn get_item(arr: [i32; 10]) -> i32 {
    let idx = get_from_user();
    arr[idx] // runtime bounds check
}

  

When it can know the index at compile time, it omits the bounds check, and iterators are an example of that. But Rust cannot always omit a bounds check. Doing so could lead to a buffer overflow/underflow, which violates Rust's rules for safe code.

Edit: I should also add, but the compiler also makes optimizations around slices and vectors at compile time if it statically knows their sizes. Blanket statements here around how it optimizes will almost always be incorrect - it's smarter than you think, but not as smart as you think at the same time.

What's wrong with 3.13?

Rust's memory safety guarantees only work for Rust due to its type system, but another language could also make the same guarantees with a higher runtime cost. For example, a theoretical Python without a GIL (so 3.13ish) that also treated all mutable non-thread-local values as reentrant locks and required you to lock on them before read or write would be able to make the same kinds of guarantees. Similarly, a Python that disallowed coroutines and threading and only supported multiprocessing could offer similar guarantees.

Converting CSV to JSON is probably just a matter of translating column names to property and wrapping them all in a list. But if that's the case, it may be worth opening an issue on FreeTube to have the docs and code updated.

Yes

Are you suggesting that Rust can perform compile time array bounds checking for all code that uses arrays?

I'll answer this question: no.

But it does make some optimizations around iterators and unnecessary bounds checks written in code at least.

But yes it does runtime bounds checking where necessary.

C, C++, and Rust come to mind as other languages with sizes as part of an array's type. This is necessary for the compiler to know how much stack memory to reserve for the values, and other languages that only rely on dynamically sized arrays and lists allocate those on the heap (with a few exceptions, like C#'s mostly unknown stackalloc keyword).

Do you mean memory safety here? Because yes, for memory safety, this is proven. E.g. there are reports from Google that wide usage of memory-safe languages for new code reduces the number of bugs.

Memory safety is such a broad term that I don't even know where to begin with this. Memory safety is entirely orthogonal to typing though. But since you brought it up, Rust's memory safety is only possible due to its type system encoding lifetimes into types. Other languages often use GCs and runtime checking of pointers to enforce it.

Then, first, why don't the claims that statically compiled languages come with claims on measurable, objective benefits? If they are really significantly better it should be easy to come up with such measures?

Because nobody's out there trying to prove one language is better than another. That would be pointless when the goal is to write functional software and deliver it to users.

I have seen no such report - in spite of that they now have 16 years of experience with it.

I have seen no report that states the opposite. Google switched to Go (and now partially to Rust). If they stuck with it, then that's your report. They don't really have a reason to go out and post their 16 year update on using Go because that's not their business.

And just for fun, Python itself is memory safe and concurrency bugs in Pyhton code can't lead to undefined behaviour, like in C.

Python does have implementation-defined behavior though, and it comes up sometimes as "well technically it's undocumented but CPython does this".

Also, comparing concurrency bugs in Python to those in C is wildly misleading - Python's GIL prevents two code snippets from executing in parallel while C needs to coordinate shared access with the CPU, sometimes even reordering instructions if needed. These are two completely different tasks. Despite that, Rust is a low level language that is also "memory safe", except to an extent beyond Python - it also prevents data races, unlike Python (which still has multithreading despite running only one thread at a time),

Go is neither memory safe...

?

...nor has it that level of concurrency safety

That's, uh, Go's selling point. It's the whole reason people use it. It has built-in primitives for concurrent programming and a whole green threading model built around it.

If you concurrently modify a hash table in two different threads, this will cause a crash.

This is true in so many more languages than just Go. It's not the case in Python though because you can't concurrently modify a hash table there. The crash is a feature, not a bug. It's the runtime telling you that you dun goof'd and need to use a different data structure for the job to avoid a confusing data race.

It's not hard to find articles explaining the benefits of using TypeScript over JavaScript or type hints in Python over no type hints online. It's so well known at this point that libraries now require type hints in Python (Pydantic, FastAPI, etc) or require TypeScript (Angular, etc) and people expect types in their libraries now. Even the docs for FastAPI explain the benefits of type hints, but it uses annotated types as well for things like dependencies.

But for a more written out article, Cloudflare's discussion on writing their new proxy in Rust (which has one of the strictest type systems in commonly used software programming languages) and Discord's article switching from Go to Rust come to mind. To quote Cloudflare:

In fact, Pingora crashes are so rare we usually find unrelated issues when we do encounter one. Recently we discovered a kernel bug soon after our service started crashing. We've also discovered hardware issues on a few machines, in the past ruling out rare memory bugs caused by our software even after significant debugging was nearly impossible.