One of the first things I tried in Rust a couple of years ago coming from Haskell. Unfortunately it's still not stabilized :(

> Memory safety is not that sacred. In fact, for many applications malfunctioning is better than crashing

Yeah, just another data leak, no biggie.

What's a bit of arbitrary code execution between friends?

Not at the same level. TRAMP is way behind feature-wise.

You mean like the way VSCode does by installing a whole mini version of itself on the remote computer?

Well, I guess? Using TRAMP with large projects is not a pleasant experience. It works great for one-off files and remote bookmarks etc, but for working with large projects you're better off mosh/ssh-ing into the server and using Emacs there. With things like term-keys [1] you can use all the keys there as well. Basically only missing out on images and variable fonts, both of which are none issues for me at least when programming.

1: https://github.com/CyberShadow/term-keys

> Zig must also be good for eliminating the same ones.

But Zig does not eliminate them, but rather it might catch them at runtime. The difference here is that Rust promises that it will detect them at compile time, long before I ship my code.

> The property of memory safety is itself not binary in both languages

In this case it is: either you catch the issue at compile time, or you don't. This is the same as type safety: just because Python can detect type errors at runtime it does not mean that it's as "type safe" as, for ex. Haskell. This might be due to imprecise usage of terms but that's just the way it's discussed in the craft.

> But Zig does not eliminate them, but rather it might catch them at runtime

So does Rust. That's what we mean by eliminating them. Zig/Rust will panic, but you won't get a vulnerability.

> The difference here is that Rust promises that it will detect them at compile time, long before I ship my code.

No, Rust doesn't guarantee catching spatial-memory-safety violations at compile-time. Neither do Java, Python, or JS/TS, by the way.

Yes, but instances require the user to provide shrinking while Hypothesis does not: shrinking is derived automatically.

> async/await is also available in a bunch of other languages, including F#, C#8, Haskell[...]

Haskell (GHC) does not provide async/await but uses a green thread model.

Aren't green threads and async-await orthogonal concepts?

As I understand it async-await is syntax sugar to write a state machine for cooperative multitasking. Green "threads" are threads implemented in user code that might or might not use OS threads. E.g.:

- You can use Rust tokio::task (green threads) with a manually coded Future with no async-await sugar, which might or might not be parallelized depending on the Tokio runtime it's running on.

- ...or with a Future returned by an async block, which allows async-await syntax.

- You can have a Future created by an async function call and poll it manually from an OS thread.

- Node has async-await syntax to express concurrency but it has no parallelism at all since it is single-threaded. I think no green threads either (neither parallel or not) since Promises are stackless?

Is this a new usage of the term I don't know about? What does it mean? Or did I misinterpret the "but"?

As a non-Haskeller I guess it doesn't need explicit async-await syntax because there might be some way to express the same concept with monads?

You don't need "monads" (in plural) since GHC provides a runtime where threads are not 1:1 OS threads but rather are managed at the user level, similar to what you have in Go. You can implement async/await as a library though [1]

[1] https://www.cambridge.org/core/services/aop-cambridge-core/c...

What do you mean with "in plural"?

In the sense that you only need to work with the standard IO monad to get the benefits of the runtime.

(author here)

Well, I haven't used Haskell in a few years, so I could absolutely be wrong. That being said, I'm almost sure that I saw a presentation by Simon Marlowe 15-20 years ago demonstrating GHC with a multicore scheduler (alongside `seq` and `par`). Also, from the very same Simon Marlowe, there's a package called `async` https://hackage.haskell.org/package/async which basically provides async (no await, though).

A runtime with it's own scheduling. Something rust doesn't want to require.

> Knowing if a function will yield the thread is actually extremely relevant knowledge you want available.

When is this relevant beyond pleasing the compiler/runtime? I work in C# and JS and I could not care less. Give me proper green threads and don't bother with async.

Knowing when execution will yield is useful when you want to hold onto a thread. If you run your GUI related async tasks on the GUI thread you don't have to worry about locks or multi threaded data structures. Only a single GUI operation will happen at a time.

If yields are implicit, you don't have enough control to really pull that off.

Maybe it's possible but I haven't seen a popular green threaded UI framework that let's you run tasks in background threads implicitly. If I need to call a bunch of code to explicitly parcel background work, that just ends up being async/await with less sugar.

> I mean, Haskell has like what, 2, 3, 4? Major build systems and package repositories? It's a quagmire.

Don't know when was the last time you've used Haskell, but the ecosystem is mainly focused on Cabal as the build tool and Hackage as the official package repository. If you've used Rust:

- rustup -> ghcup - cargo -> cabal - crates.io -> hackage - rustc -> ghc

It's admittedly been years.

ghcup didn't exist, AFAIK. Cabal was around but I think there was a different ecosystem that was more popular at the time (Started with an S, scaffold? Scratch? I can't find it).

    } catch (exception: Exception) {
      // log exception
      throw exception
    }

Probably the most harmful snippet ever written. Every blog post about errors has something similar written, regardless of the programming language. Please, don't write, suggest or even pretend that this should exist.

Whats the problem ? Is throwing directly better here ? Given the annotations I presume this is spring so it will probably be logged anyway. So maybe its unnecessary here.

> that data flowing between them consists of simple, agreed-upon formats

> HTTP servers and clients, email systems, DNS resolvers—they all interoperate based on simple protocols

Yeah, massive disagree with this. There is absolutely nothing "simple" about these protocols. Try to compose 3/4 UNIX programs together and you necessarily need to run it to see if it even makes sense. Don't get me started on HTTP.

It boils my blood to read "simple" in the context of software engineering