dexterlemmer

Type hints and static typing are completely orthogonal. It is merely more common for the designers of dynamically typed languages to make the mistake of not allowing type hints pretty much every where and requiring them in a library's API (or at least linting for them being missing in the API) than making the same mistake is for the designers of staically typed languages.

> While typing is dynamic, I rarely see this being used, perhaps with the exception of identifying empty variables with None. Most identifiers are born and die the same type. It would be interesting to see how much effect dynamic typing has on the rate of programming errors.

Dynamic typing and changing the type of a variable are orthogonal.

You can change a type with casting, coercion, transmutation, dynamic dispatch, downcasting, reflection, monkeypatching (i.e. simultaneosly using dynamic dispatch and downcasting and reflection). All of these methods are available in Rust, which is a statically typed language.

Some things that some people think are changing the type of a variable in Python is not what it seems, for example:

    # Python
    a = 1
    a = ['h','i'] # `a: int` is unchanged but gets implicitly shadowed by `a: list[str]`
    a[1] = "a"    # We're combining shadowing with weird and inconsistent scoping

translates to the following in Rust:

    // Rust
    #[allow(unused_mut, unused_variables)]
    {
        let mut a = 1;
        let mut a = ["h", "i"]; // Explicit shadowing
        a[1] = "a"; // We're simply calling a mutating operator
    }

Furthermore:

    # Python
    lst: Array[Any] = [1, "2", 3.0] # A heterogeneous list
    for elem in lst:
        print(elem);

translates to the following in Rust:

    // Rust
    // Below `dyn` has nothing whatsoever to do with dynamic typing.
    // ... it is just fluff having to do with the requirements of systems programming.
    // ... (Technically it means we're using vtables to do dynamic dispatch.)
    // ... The `Box` nonsense is more systems dev fluff having to do with memory allocation.
    // ... Of course in Rust, App devs often don't need to worry about such fluff because
    // ... lib devs should provide ergonomic API's, but I'm doing as close as
    // ... possible to a direct translation of the Pyhon code.
    #[allow(unused_mut)]
    let mut lst: Vec<Box<dyn Display>> = vec![
        Box::new(1),
        Box::new("1"),
        Box::new(1.0),
    ];
    for elem in lst {
        println!("{elem}");
    }

The one major difference between the Python code and Rust code above is that `Display` in Rust is a Rust trait (i.e. a typeclass) and typeclasses don't exist in Python.

I don't see the connection between white space in PLs and parenthesis in math.

On the other hand: Let's consider what the Python-like version of math actually look like:

    f(x) = :
        x, if x > 0
        -x/2, if x < 0 and x is even
        0, otherwise

In stead of:

              __
             /
             | x,  if x > 0
    f(x) =  <  -x/2, if x < 0 and x is even
             | 0, otherwise
             \__

The latter is, of course how math actually looks.

> A couple of newlines to create a new paragraph is semantic whitespace, as one newline or a space would not do so. Markdown (although not HN's Markdownesque syntax) even has significant trailing whitespace, which I would object to in a programming language.

A code block is *not* the same as a paragraph. It is the same as a part/chapter/section/subsection/subsubsection. (Think about it.) In formal writing, these are practically always clearly indicated by not just semantic whitespace but also by semantic headers with particular semantic styling as well as semantic numbering. In addition, if you you write these programatically in for example Markdown or LaTeX, you might have semantic whitespace in the markup language but you definitely will have semantic non-whitespace symbols in the markup language.

Next Quote:

    for (i = 1; i < 11; ++i)
        printf("%d ", i);
        printf("%d ", i);

This has nothing to do with the lack of significant white space and everything to do with terrible language design. Here is the *only* valid way to write the above in Rust:

    for i in 1..11 {
        println!("{}", i);
    }
    println!("{}", i);

If you tried:

    for in in 1..11
        println!("{}", i);
        println!("{}", i);

you would get a compiler error because the braces are required around the bodies of all control- and loop structures. Also note that a common class of bugs is avoided in Rust because in Rust the loop condition is not in parenthesis. (Nor are the conditions in `if`s, etc.)

> Also, with Python appealing to new programmers, there'd probably otherwise be plenty of beginner code with no indentation at all.

Which is to say teaching methodology for coding sucks. While you shouldn't overwhelm a beginner with linting errors from a very pedantic linter (to put it mildly), not automatically linting all beginner code for some basic issues like incorrect white space and wEirD_caPS_in_OVERLY_LOOOOOOOONG_idENTIFIERS or `l` `o` `t` `s` `o2` `f` `s2` `h` `o3` `r` `t` `i` `d` `s3` (lots of short identifiers) is, IMHO, a really bad idea.

Furthermore, actually (at least in my experience tutoring C++/Java/C#), bad white space is actually not that common for beginners after the first few lessons. I guess that most humans are used to just automatically write and type semantic white space. Therefore if they see their teacher writing code with white space they'll not only use white space themselves but use it similarly.

On the other hand the identifier issues I've mentioned above are all more common, especially too short and obscure identifiers.

Looking at the examples you've provided, I'm pretty sure the Linux kernel's codebase dwarfs their combined codebases into insignificance. Since it is very hard to not have NP-hard asymptotic complexity when formally verifying a codebase as large and as demanding (in terms of performance, etc) as the Linux kernel, I would expect that if you tried to rewrite Linux in the languages you've mentioned and formally verify the rewrite, you will be able to keep the entire AWS cloud (globally) very busy for a very, very long time. On the other hand, if you were to do the rewrite in Rust and use some hypothetical formally verified Rust compiler to type check it (which is mathematically equivalent to such a formal verification in, say, F* limited to only verifying certain properties), it'll probably type check in minutes or even seconds on the laptop I'm currently writing this reply on.

For a less hypothetical example. RedoxOS has a codebase that dwarfs Sel4 (but it is still much smaller than Linux in turn), yet it type checks with much less compute cost than it takes to formally verify Sel4. Or heck, Redleaf actually formally verifies in a tiny fraction of the time it takes to formally verify Sel4, because the Rust type checker not only significantly reduces the amount of requirements that still needs to be formally verified but also reduces the complexity to verify those requirements to linear to the codebase size due to the restrictions that the Rust type system and module system puts on valid Rust programs (with a little bit of care when writing the code). Of course, until you have a certified Rust compiler there might still be miscompiles of Redleaf and until all the features of Rust used in the Linux kernel is formally specified, we cannot do the same with the Linux kernel as for Redleaf even if somehow all of Linux got rewritten in Rust. But in Rust at least it is conceivably possible given sufficient resources and sufficient time. I very much doubt it will ever be possible without help from a sufficiently expressive and practical type system.

Oh yea. Then there's another problem. Most (all?) of the examples you've mentioned have requirements that are well specified and pretty much set in stone. The requirements fro the Linux kernel... aren't quite as obliging.

Rust was considered for Zircon. The only reason it wasn't chosen was that at the time Rust wasn't yet sufficiently mature for embedded. And it really wasn't.

In the meantime, Google makes extensive use of Rust in new components of both Fuchsia and Android and even rewrites some legacy components where it makes sense.

> Regarding Linus ...

I wouldn't trust Big tech as far as I can throw one of their server farms. That said, I doubt that Linus's spirit is broken and he's simply surrendering to them. Assuming you aren't just ~~trolling~~ tin foil hat farming, I'll answer what I think:

I remember Linus said some years ago (probably ~2019 or 2018) that Rust or something like it in the Linux kernel is inevitable. His reasoning was that the Linux kernel is unlikely to remain maintainable in the long run. Due to the C code in the kernel being very non-standard and due to there being a lot of code in the kernel that got written the way it was for a specific reason and most of it being just unwritten implicit knowledge of the old hands. This makes it very hard to onboard new maintainers and PR's often require significant fixes and significant internal expertise to recognize the need for those fixes and be able to make them. As the old hands grow older, they may not be replaceable.

Furthermore, new bugs are now being discovered in the kernel faster than they can be fixed [1].

If I were to guess, Linus is just hoping that Rust or some other modern safe systems language suitable for kernel development (of which Rust is by far the most mature) could help sustain the kernel's maintainability.

As for why Big tech wants Rust in the kernel. I guess that's because they want total world domination. Which will probably be hard to achieve if any idiot can easily zero-day the kernel their infra all depends on and steal all their secret big data which is "the oil of the age of AI" or rootkit a phone making it harder to surveil it's ~~owner~~ addict. ;-)

> Regarding technical merit ...

Rust is very fundamentally different from "C++ with switches toggled in different ways and a borrow checker on top". I could call Java "Cobol with switches toggled in different ways and inheritance on top" but that wouldn't make them quite that similar as I've made them sound. If you think that Rust isn't fundamentally something drastically different from C++, you either don't have a clue about C++ or don't have a clue about Rust. Rust is holistically designed to be safe, which is the only possible way to actually make a safe language. C++, however modern and with whatever programming best practices and tools, is still fundamentally completely unsafe. It helps reduce security vulnerabilities from very very very unacceptably high to merely very very unacceptably high but in this case better is nowhere near good enough. Rust actually eliminates entire classes of security vulnerabilities (with some manageable caveats).

Another difference is that by the time you've addressed all the reasons typical C++ code is unacceptable in a kernel, you are back at simply C. But you can have high level abstractions and safety and, etc. in Rust inside the Linux kernel. For just one difference, Rust's zero-cost abstractions are actually, you know, zero cost. Unlike C++'s supposedly zero-cost abstractions which have unacceptable (in the Linux kernel) overhead. (For example a move in C++ is potentially very expensive, but at worst it is a memcpy in Rust.) But there are plenty of other reasons mentioned in this thread.

[1]https://lore.kernel.org/dri-devel/20200710103910.GD1203263@k...

1. Yea, a road that was used for target practice during a large-scale NATO training exercise is the same as a road that could do with a bit of maintenance with painted potholes to warn people. After all, they both have potholes.

2. You are cherry picking. He also said "These are hard to locate for most languages; I wouldn't know where to look in case of C." Rust has some advantages from for example Clippy and from a very newcomer-welcoming and helpful community.

3. Rust in kernel would indeed have kernel-specific idioms. But it'll probably be very similar to other embedded Rust and relatively easy for a newcomer to pick up. (Ee'll have to wait and see, but there is good reason to expect this.) C in kernel is known to be very hard for other C developers to pick up.

4. Thanks for the info.

5. But some things are special about Rust that makes testing easy.

6. The kernel doesn't deal much with text and even when it does, it generally doesn't need to deal with encodings (let alone modern encodings). That said, text is really a nightmare in C. Even just ASCII is needlessly complex due to null-terination, badly designed functions and the regular C UB pitfalls. At least you did acknowledge it may indeed be a problem for C compared to Rust.

I could never figure out Githut2.0. Githut1.0 had a much nicer interface and although Rust looked bad on first impression, just moving it left a set period of time (or vice versa moving Go right a set period) showed that Rust actually grew at a very similar rate as Go... until Rust started accelerating by around 2018. I suspect something similar may be the case on Githut2.0 but just too hard to tell. Linear graphs comparing exponential growths can be very deceiving.

In my experience TIOBE is very noisy and bad at predicting long-term trends for languages outside the top-ten or so. And it seems even worse recently due to Covid. Heck Julia recently jumped into the top-20 for a single motnh earlier this year before falling back to the mid 30's. And that isn't even all that uncommon for TIOBE. I think I see a trend of Rust slowly climbing, but it is hard to tell through the noise.

PYPL says Rust has respectable growth and that its growth is remarkably consistent (i.e. it is growing at a near constant expeonential rate until 2018, then slowing down a bit in 2018 and then continuing at a very constant and this time faster exponential growth rate.

Redmonk calls Rust the tortoise language (from the hare and the tortoise story). It's growth is never impressive, but its steadiness in growing is very impressive.

You actually do mention some success stories. Also, Amazon is using Rust for a lot more than Firecracker. A lot of their critical infra is in Rust. Also, rustls is pretty big, IMO. Finally an actually secure implementation of SSH. ;-) (And fast to boot.) The Ferrocene project project is fully open source, paid for in full by donations despite the considerable expense because some of the (very big) high integrity industry really want to use Rust The Linux kernel is seriously considering including Rust and Linus said something like Rust in the kernel is inevitable. The Linux kernel team (and Linus specifically) are notorious for their previously adamant hostility towards any language other than C in the kernel. They are starting carefully with just drivers but that's already way more than for example C++ ever managed. On the CNCF, we have TiKV and Linkerd2 in Rust. These aren't small or unimportant projects although, no, they don't quite match k8s.

Over all. Rust is trying to replace C/C++. That is a very tall order. No previous language have ever come close to where Rust currently is already in that task. But it is not going to happen over night. It is a huuuuuuge task that will take a lot of time and a lot of resources and a lot of mindshifts.

Regarding improvements in the other languages. Sure, but C++20_0000_000 will not come close to some of the advantages Rust already had by 1.0 unless they are willing to break backward compatibility to the point where you can just as well rewrite in Rust. All those languages are fundamentally broken or limited in ways that cannot be fixed or worked around. Rust also have historical baggage already. But it starts from a much better starting point with a lot of lessons learned.

How have unsafety been addressed in C/C++? C++20 is exactly as unsafe as C. It has much better what I call "safeness", but that's like saying by going from 1 to 10 I made progress towards infinity. It reduces some classes of errors, if you know what you are doing and apply considerable discipline. It doesn't eliminate any errors. C++20 is sill based on the C abstract machine, which is to say a DEC11. It is still very hard to do some optimizations that are easy or even trivial in Rust and some that would've been trivial if LLVM didn't miscompile perfectly correct code. C++20 still doesn't have a borrow checker and will never have one remotely as capable as Rust's. C++/Java/C#/Python/... are still OOP with inheritance which is fundamentally at odds with really capable composition which is fundamentally superior in expressive power and fits a lot of domains a lot better. Yes. Those languages can close the gap. They can never catch up. Can they get close enough to reduce the value proposition of the newer languages to the point where the newer languages (or some others even newer than these) won't take and hold a considerable fraction of their market share? I doubt that. But taking the market share of the incumbents will take very long. The network effect is brutal. But sometimes a disruptive technology is too good to stop it from -- eventually -- overcoming that effect. Of course, again exponential growth means what starts slow can quite suddenly explode. Also, when sufficient barriers are overcome or a language gets the rigth killer app it can again explode. May be for Rust that'll be high integrity or the Linux kernel. Consider that Redleaf is already vastly superior (better security, better performance, more features, more portable) and vastly cheaper to develop and verify than sel4 for one impressive achievement. Of course, until we can actually compile Redleaf on a certified rust compiler (probably by next year), Redleaf will remain an academic curiosity. But once we can? I'm no high integrity developer, but it seems the sky's the limit.

Yikes! That was a lot of words! Sorry, but I'm too tired to edit.

Agreed. But it can also mean not actually achieving at all what you set out to do. I don't know if that is the case for Loom specifically, but that seems to be what was implied by the parent comment.

I don't see any such note and it's 8 days later. May be you should check your comment again? Also, while games aren't exactly regular applications performance-wise, I think they fall more under that than embedded or utmost control and while a 1ms delay won't be the end of the world, it'll likely hurt.

I'm getting a bit off topic here, but if you haven't heard about it yet, you might be interested in https://ferrous-systems.com/ferrocene/.

Some quotes from the linked page:

> Ferrocene is a sustainable effort led by Critical Section GmbH, a newly formed Ferrous Systems subsidiary, tasked with making Rust a first-class language for mission and safety-critical systems. Ferrocene produces a qualified Rust compiler toolchain. General availability is expected by the end of 2022.

And also:

> Ferrocene is a vehicle for a versioned Rust and MIR specification, paired with automated verification of Rust semantics. These "runnable specs" give developers in mission-critical and high-security environments a sound, proven, and addressable foundation for building critical libraries, analysis tools, and further system assurances.

And also:

> Critical Section will maintain designated legacy versions of the Rust toolchain and supporting utilities. This support includes backporting fixes of critical language and standard library issues (performance bugs, unsoundness, security) and maintaining key rustc targets, including test cases and platform-specific testing.

And finally:

> Ferrocene is a principled project with much work ahead, requiring cross-industry collaboration and continuous feedback. It has support from crucial industry partners and subject experts, and we're building a thoughtful community.

> Right now, Ferrous Systems and Critical Section are calling for additional partners to join this effort. We're currently looking for partners from diverse industries

If the borrow checker of 1.52.1 "screeches" on every LOC but it compiles on 1.0 then very likely either there's some bug in 1.52.1 that you should report or you code was never correct and should never have compiled in 1.0 in the first place but did due to a compiler bug that since got fixed.

Of course, without more info nobody can tell which of these or even whether it is one of these two or something else.

It's not just the GC, Go's Interfaces are very heavy weight (including in TinyGo). Its green threads are very heavy weight (including in TinyGo)... Oh. And a GC is really unacceptable in a kernel (though not necessarily in the rest of an OS) for all sorts of reasons, not just throughput but also latency and severe issues with FFI and concurrency and frankly how the heck are you even supposed to run a GC without a runtime in the first place? And speaking of which: TinyGo has a massive runtime that requires a sophisticated OS like FreeRTOS already installed on the system, not just for GC but for greenthreads, and, well, everything.

Just because nowadays even MCU's are so powerful that you can just waste an insane amount of resources on TamaGo and just because TamaGo seems to run on custom hardware/firmware that specifically provides it what it needs to directly run on the hardware without help from C/C++/Rust, doesn't mean Go is particularly viable for Android today.

Even more importantly. Google actually wants to use a safe language for Android. Go isn't safe the moment you go parallel/concurrent/async. Go also isn't memory safe for important OS tasks like direct memory access. Go also isn't null safe. Go also isn't typestate safe... Rust have all of the above mentioned safety in all of the above mentioned situations.

I'm no expert in this domain but it seems to me that RedLeaf (implemented in Rust and formally verified) is vastly superior to seL4. AFAIU RedLeaf is orders of magnitude cheaper to formally verify to a much higher standard[1] while also being significantly more performant[2] and that Rust's properties are key to both of those advantages[1,2]. (Note: I only skimmed [2].)

Edit: It seems RedLeaf is immune to meltdown due to its design while seL4 has meltdown mitigations[2]. I would assume the same goes for spectre, but that would be an assumption on my part. (Note again, I've only skimmed [2] so I can easily be wrong here.)

[1]: https://www.ics.uci.edu/~aburtsev/doc/redleaf-hotos19.pdf

[2]: https://www.usenix.org/system/files/osdi20-narayanan_vikram....

It seems like he did. (Or may be someone else's. I didn't check the repo.) Common Lisp is the second slowest on his results table.

Huh? Plenty of CVEs found in C/C++ codebases were introduced decades before they were discovered. In fact, it seems to me that the older a C/C++ codebase is (especially C++), the more bugs is has, simply because improved coding practices and "modern C++" features have a far greater impact than amount of user feedback and experience. But best practices and modern C++ features are just a poor man's (semi-effective) borrow checker. ;-)

More seriously. I agree that you can't call rust-coreutils mature yet. But over time maintenance on it will probably be considerably easier and if it ever gets popular enough to be thoroughly battle-tested, it almost certainly will be more reliable and secure. In addition, odds are that even if still immature, it already has fewer serious bugs. Especially memory safety, but also in things like string-handling since C++ -- and especially C -- string handling is notoriously difficult to get right. Then again, maybe not, since coreutils and presumably also rust-coreutils take the stupid approach that strings are just streams of bytes and there's relatively little the Rust std and compiler can do to fix that mess. Oh, wait! Actually it can help a bit by allowing you to be "flexible" in your interface but also parse and validate at the interface, then use better abstractions internally.

Case in point: OpenSSH vs rustls: OpenSSH is a lot older than rustls, has been extensively battle-tested by a very expert community, has been audited, fuzzed, etc to a significant degree, and we're still now starting to see security experts advising using rustls in stead of openssh, or projects deciding to switch to rustls because rustls is likely (and according to a growing body of real-world experience and evidence) less buggy and more secure than openssh. (And as a bonus it's also faster.) Not all of openssh's issues are due to the language, and neither is rustls's choice of language the only reason for its reliability. But in both cases the implementation language does play a crucial role in their security and reliability.

> Having standard serialization is just gonna be boilerplate and unneccessary for many programs.

And for a lot of programs having to keep generating and parsing strings is just a bunch of unnecessary boilerplate.

> Stream of bytes is the only sane thing to do. Nothing keeps you from not having a flag in your cli programs to choose the input/output format. In fact many programs already has this and json seems pretty popular.

Having an API like this is a great idea... as a thin wrapper on top of a tool with a standardized serde protocol or binary file format. The different API's can be exposed as separate tools or as separate parts of the API of a single tool from a user's POV.

Furthermore: JSON is not just a stream of bytes nor text, neither is CSV, nor any other text format. Handling text as properly typed objects makes a lot of sense.

I have little experience with shells that can work with objects like Powershell. But I'e seen screenshots of new objects-based shell developed in Rust some time ago and it was early days still so I didn't actually even try it out, but looked downright great compared to the current stream of text-based shells of today in terms of ergonomics and capabilities.

Yes and more:

1. Lack of "manual memory management" can be taken as GC (though Rust is neither GC'd nor manual memory managed, it's declaratively memory managed) and a GC is unacceptably expensive for systems programming. Furthermore, until recently GC was also unacceptably bad for FFI. However stable Rust and Haskell with experimental features can nowadays GC across FFI without issue, but I'm still unaware of any other language that can.

2. Lack of "manual memory management" also means lacking direct memory access, etc. This is a problem in systems programming, though you do not need it for all systems programming.

3. Then there's green threads. Early on Rust had them, but they were removed when it was discovered it's theoretically impossible to implement them with acceptably low overhead for a C or even a serious C++ competitor. What's worse, you have to pay the overhead even if you don't use the feature. Nowadays, you can opt in by importing an ecosystem library that provides green threads but mostly people just use futures rather than green threads.

4. Interfaces: Even tinygo's documentation advises avoiding interfaces and tinygo isn't even a C/C++/Rust competitor, it's a micropython competitor.

5. ...

I agree. But this particular example ironically has nothing to do with dynamic typing.

> So what's the type signature of `print()` then?

I like the way Rust makes clear what are the different possibilities:

In Rust we use a macro to handle variadic arguments, but if it was just a case of supporting different types, not of supporting an arbitrary number of arguments we would've had three options for the type signature:

1. Monomorphic duck typing: `fn print(arg: &impl Debug)`. Here the compiler simply generates multiple print functions, one for every type the function gets called on. The exact concrete type is known at compile time.

2. Polymorphic dynamic dispatch (with dynamic sizing) duck typing: `fn print(arg: Box<dyn<Debug>>)`. Here the compiler generates a vtable and allocates on the heap. Only a type approximation is known at compile time, not the exact concrete type, but it still counts as static typing.

3. Dynamic typing: `fn print(arg: Box<dyn<Any>>)`. Note `Any` in stead of `Debug`. Full dynamic typing with the type completely unknown at compile time. Juck! But occasionally useful for prototyping or for FFI with dynamically typed languages.

It has nothing to do with the difference between strong and weak typing and also has nothing to do with the difference between weak and strong typing. It is about Python not disambiguating between variable shadowing and variable reassignment.

Here's a comment of mine that explains why Python is weakly typed: https://news.ycombinator.com/item?id=26354039.

This has nothing to do with either dynamic or weak typing in Python. It's just Python not disambiguating between shadowing and reassignment.

Here's a comment of mine that explains why Python is weakly typed: https://news.ycombinator.com/item?id=26354039.

Python is more strongly typed than JS/Perl, granted. But it is still very weakly typed overall. Here are some examples:

1. if list(): pass # implicit coercion from collection -> None -> bool. (Very uncommon weak typing and a terrible idea.)

2. a = 123; b = 4.5; c = a + b # implicit coercion from int -> float (Common but not universal weak typing. More often hides bugs than helps with ergonomics and readability but sometimes a worthwhile tradeoff.)

3. a = 1 + false # implicit coercion from bool to int (Common weak typing in scientific languages (for masking) and older C-family languages (for bit twiddling). However, that's still bad language design. Libraries/syntax sugar should special case masking and bit twiddling. You should not have global coersion between bool and int.)

4. etc.

Python abounds with corner cases and gotchas. It may have fewer than JS/Perl, but that really isn't saying much. It may hide them until a test or real-world use shows you you've stepped on them but that's not always a good thing.

TLDR; Right now Python is almost always easier for numeric Python beginners than Rust is for numeric Rust beginners and even also more productive. I just don't see Python's ease and productivity advantages remaining if Rust can catch up with Python's ecosystem and toolchain. But we'll have to wait and see if that will happen. And when and if Rust is actually (slightly) more friendly to the numeric computing beginner and much more productive in some numeric/scientific contexts than Python, Python loses its current intermediate language position. Especially if similar improvements happen in other domains.

> Python does this so well because of the extremely full featured and fairly easy to use C API. Advanced programmers can write extension modules for the interpreter and provide APIs to their C libraries via Python, give their types and functions a basically identical syntax to MATLAB and R, and bang, statisticians, engineers, and scientists can easily migrate from what they already know how to use, pay no performance penalty, but do it in a language that also has web frameworks and ORMs. You can do machine learning research and give your resulting predictive models a web API in the same language.

You know what's better than "the extremely full featured and fairly easy to use C API": If your language can itself compete with C/C++ for writing the libraries you need. The only advantage Python has over Rust regarding library ecosystem is the first-mover advantage and that Rust makes obvious how terrible the C API is which means people often invent new Rust libraries rather than reuse the old C libraries. The only advantages Python has over Julia are first-mover and that I doubt Julia-native libraries can truly match highly optimized C/C++/Rust libraries performance-wise in most situations where performance actually even matters.

> But I also recognize the tremendous utility in having a language that can be used for application development but also for numerical computing where static typing isn't really needed because everything is some variant of a floating-point array with n dimensions.

* Some numeric use-cases need to work with more than floating points. May be 2D (complex)/4D/8D numbers, may be dollars, may be durations. You lose all units of measurement and they are often valuable. In Python you cannot indicate "this cannot contain NaN/None". * In an N-D array, N is a (dependent) type, so is the size, so is the shape. Julia got this right but last time I checked it had a nasty tendency to cast the dependent types to `Any` when they got too complex. Imagine if you can replace most `resize` calls with `into` calls and have the compiler verify the few cases you still need resize. In Rust several libraries already use dependent types for these sorts of uses, but lack of important features that are only now starting to approach stable (const generics, GATs) makes them very unergonomic to work with. * I see a lot of complex types that should've been a single column in a dataframe get represented with the full complexity of multi-indexes. Juck! Not only more complex, but far less expressive and more error prone. I haven't yet seen Rust go the extra step and represent a struct as a multi-index to get the best of both worlds, but it's what I would love and Rust definitely has the potential. It's just not a priority yet as we are still just implementing the basics of dataframes first. * Things get even more interesting when you throw in machine learning. As a masters degree student, it took me months (mostly during the summer vacation, so I wasn't going to ask my promoter for help) to figure out the reason I'm getting bogus results is due to a methodological mistake that should have been caught by the type system in a safe language with a well-designed ML library. But here the issue is "safe" and "well designed library" not so much as "statically typed", but a powerful type system is required and the type system would catch the error in milliseconds in stead of hours if the it is static rather than dynamic.

> Forget about looping. Just v1 * v2. It will even automatically use SSE instructions.

Many languages have operator overloading and specialization or polymorphism to enable optimizations. In Rust this is again just a case of libraries providing an optimized implementation with an ergonomic API.

> So the complaints you typically see about dynamic languages simply don't matter. No static typing? Who cares? Everything is a ndarray.

Nope. Everything is not just an ndarray. That often works well enough. But when numeric computing gets more complex, you really want a lot more typing.

> Not when you have an interface directly to highly optimized BLAS and ATLAS implementations that have been getting optimized since the 50s and your code is auto-vectorized without you needing to do anything.

Much of those decades old optimizations are irrelevant or even deoptimizations on modern hardware and with modern workloads. The optimizations needs maintenance. In C/C++ optimizations are very expensive to maintain in Rust we cannot only leapfrog outdated optimizations but also much more cheaply maintain optimizations. Also, as we move into more and more datasets that are medium/large/big (and therefore don't fit into RAM), we're getting more and more optimizations that are very hard to make work over the FFI boundary with Python. The fastest experimental medium data framework at the moment is implemented in Rust and has an incredibly thick wrapper that includes LLVM as a dependency (of the wrapper), since it's basically hot reloading Python and compiling it to a brand new (library-specific) DSL at runtime to get some of the advantages of AOT compilation and to try to fix some of the optimizations that would otherwise be lost across the FFI boundary. Note that means now you need to do a very expensive optimized compile every run, not every release compile of the program, though I guess you can do some caching. Note also that it means maintenance cost of the wrapper quite likely dwarfs maintenance cost of the library implementation which is not a good situation to be in. The fastest currently in production python framework for medium/large data is probably Dask, but to achieve that performance you need to know quite a bit about software engineering and the Dask library implementation and do quite a bit of manual calculations for optimal chunk sizes, optimal use of reindexing, optimal switching back and forth with numpy, etc. and to avoid all the many gotchas where something that expect would work crashes in stead and needs a very complex workaround. In Rust, you can have a much faster library where the compiler handles all of the complexity for you and where everything you think should work actually does work and that library is already available (though not yet production ready).

> Meanwhile, it's also still beginner friendly!

* Is it? I admit it's code (but definitely not its toolchain) is marginally better for programming novices (and that marginally is important). Importantly, remember that novices don't need to learn about borrow checking/pointers/whatever in Rust either and that by the time they're that advanced, they need to worry about it in Python as well but the language provides no tools to help them so in stead of learning concepts, they learn debugging. Rust is lagging in teaching novices mostly due to the lack of REPL and fewer truly novice-friendly documentation, IMHO. * But give Rust a good REPL and more mature library ecosystem and I cannot imagine Python being any more beginner friendly than Rust for numeric computing. (When "everything is just an ndarray of floats" is good enough, the Rust would look identical to the Python (except for the names of the libraries used) but provide better intellisense and package management. When "just an ndarray of floats" isn't good enough, Rust would have your back and help the beginner avoid stupid mistakes Python can't help with or express custom domain types that Python cannot express or at least cannot express without losing the advantages of the library ecosystem.

Don't get me wrong. Right now Python is almost always easier and even also more productive for numeric computing. I just don't see it remaining that way if Rust can catch up with its ecosystem and toolchain. But we'll have to wait and see if that will happen.

I can also think of several other domains where Rust is actually potentially better suited as intermediate language than the competitors: * Rust arguably is already there in embedded if you can get access to and afford a Cortex-M. But I think it might actually be capable of beating mycropython in ease on an arduino one day. (At least for programmers not already experts in Python.) I won't go into my reasoning since this is already getting long. One day embedded Rust might also compete with C in terms of capabilities (the same or better for Rust) and portability (probably not as good as C on legacy hardware but possibly better on new hardware). * I think Rust is already a better language than Go for cloud native infrastructure except for its long compile times and it seems like an increasing number of cloud native infrastructure projects also feel that way. In the meantime new libraries like `lunatic` might be an indication that one day Rust might be able to compete with Go in terms of ease of writing front-ends for beginners. * Looking at what happens in the Rust game libraries space, I think Rust can definitely be a great intermediate language there one day. It already has a library that aims to take on some beginner gamedev/art libraries in languages like JS/processing/Go and at the same time, it has several libraries aiming to be best in class for AAA games.

Interesting. My native language, Afrikaans, has a lot of influence from both Dutch and German (as well as a bit from English and quite a bit from Bantu African languages). We say "eenvoudig" for "simple" and "maklik" for "easy". I recognize both the (different) Dutch words Google Translate provides me when I translate to Dutch as similar to the Afrikaans words, but Google Translate translates both to "einfach" when I translate to German. May be German for some reason conflates the meanings. That said, homonyms and homophones that conflate meanings are found in most human languages, and often for meanings that are far easier (or is that simpler ;-)) to distinguish than "simple" and "easy".

> No flame sit. It is either safe or not. Safer doesn't qualify as safe.

I agree and I often have to try to make this clear to proponents of "modern" C++/Go.

> Your query searches for type unsafeties.

His query searches for all unsoundness in Rust (including both type- and memory unsoundness). It does not search for unsafeties. Unsoundness can enable unsafety in code written in save Rust. However, unsoundness is fixable w/o redesigning the language (though may be very hard in practice) and usually doesn't cause significant breakage when fixed (in Rust at least). Unsafety in code enabled by fixing unsoundness often disappears when the unoundness is fixed but will result in a compiler error or -lint when the unsoundness is fixed if it doesn't disappear. Unsafety in the language is not fixable w/o major redesign and ecosystem wide breakage. It should be noted that most remaining unsoundness in rustc is suspected to have very low impact in practice and are very hard to fix but they are being steadily fixed.

> A third query would be for concurrency unsafety: deadlock. All three unsafeties are builtin by design. There's no way to deny it. But they still do repeat the same lies again and again.

Deadlocks are theoretically impossible to eliminate in any Turing complete language. In Rust there are often ways to prove your program doesn't contain any deadlocks but indeed some academic research languages (mostly dealing with effect types) makes this easier in more cases. At least in Rust a deadlock results in the lack of stuff happening that you would've preferred happen (which is bad enough), not in UB like in C++ (which is considerably worse).

Memory leaks in Rust are a similar situation to deadlocks although admittedly authors of unsafe Rust need to take some care to ensure it remains similar and not a way that worse memory safety issue could occur. The Rust designers wanted to make it very clear that they consider memory leaks bad but not part of Rust's memory safety guarantees and even went so far as to add a safe function to std that leaks memory (i.e. not as a side-effect, leaking memory is what it is for).

On this note. No language can ever be save in all respects. But save doesn't mean no bugs. It means you have explicit guarantees and enforced contracts. Save rust explicitly guarantees concurrency safety except that deadlocks can occur and the compiler enforces the guarantee unless an unsoundness bug causes the compiler to fail in its explicit contract to enforce it. Similar with memory safety, which is guaranteed (and enforced except sometimes in the precence of unsoundness bugs) but the guarantees explicitly exclude memory leaks. That still leaves a lot less to worry about than in "modern" C++ where absolutely no concurrency- or memory safety is in any way guaranteed nor enforced. Rust is all about eliminating all compromises it can and where the cost/benefit ratio makes sense but to still be pragmatic when and where appropriate.

> Stack overflows being memory safe you can tell your grandma or upper management. Problem was rust was once memory safe, but they ripped out the GC. Now it's just better than C++, but not better than Java or really safe languages. Overhype rarely reflects well on a community.

Stack overflows are memory safe in Rust. Rust's safety guarantees don't say stack overflows will not occur only that they would not cause specific issues if they do occur (like double free or UAF or ...). Again. Sometimes it is possible to prove they cannot occur but in general this is an impossible problem to solve in any Turing complete language.

EDIT: Also: GC's don't prevent stack overflows either. Therefore I don't get your point.

The terms did not change in a malicous way, because they were already malicious. There never was an opt-out of sharing data with Facebook:

> Specifically, users had 30 days after first seeing the 2016 privacy policy notice to opt out of “shar[ing] my WhatsApp account information with Facebook to improve my Facebook ads and product experiences.” The emphasis is ours; it meant that WhatsApp users were able to opt out of seeing visible changes to Facebook ads or Facebook friend recommendations, but could not opt out of the data collection and sharing itself.

Source: https://www.eff.org/deeplinks/2021/01/its-business-usual-wha...

> "Would you give me your home address and keys so I can drop off a newspaper on your coffee table each morning?"

... Oh. And BTW. I'll be making some copies of your keys to give to a bunch of others interested in placing adds on your coffee table (or so they claim). I'll also go through all your drawers to see if I can't find any other keys/access cards/... to gain access to your office or your colleages' offices, friends' or family's homes, etc. just so I can provide them with the same adds "service" as I intend to provide you. Of course I don't remind you of any of this. Nor do I tell your colleagues, friends, family, etc. After all. What you don't know will aid me and what they don't know will aid me. ;-)