rust VS go

That's because the linked issue is a different, but related tracking issue. The FP-in-const tracking issue was this one: https://github.com/rust-lang/rust/issues/57241

A long-standing issue with that was just recently fixed: https://github.com/rust-lang/rust/pull/133250

By the way, genawaiter is also an interesting library that uses the async-await mechanism to implement the generator in the stable version of Rust. As we know, async-await is essentially a generator, and also relies on the compiler’s CPS transformation to implement the state machine. However, async-await was stabilized a long time ago due to the strong need for asynchronous programming, whereas the generator feature lagged behind. The similar principles behind them allows their mutual implementation. In addition, the Rust community is actively promoting async generators, with native async gen and for await syntax entering the nightly version. However, since it is not integrated with the futures ecosystem, it remains in an unusable state overall. RisingWave‘s stream processing engine relies heavily on async generator ****mechanism to implement its streaming operators, simplifying streaming state management under asynchronous IO. That's another extensive topic, and we'll discuss the relevant applications if there is an opportunity later.

Might not.

Rust has a state of the art sort implementation. There’s nothing faster, in any language - https://github.com/rust-lang/rust/pull/124032.

And sure, it’s possible that someone could write a C program that compares in speed to all the Rust programs I’ve mentioned. C is a Turing complete language after all. I’m only pointing out that it hasn’t happened in practice.

Also check the Android Binder code before (C https://github.com/torvalds/linux/blob/master/drivers/androi...) and after (Rust - https://android.googlesource.com/platform/frameworks/native/...). Same speed but the quality difference, it’s incomparable.

To be honest I don't think it is possible in Raku. It can be done in Rust using it's ownership transfers and borrow checker, but that is subject for another blog post :)

> But Rust has a better workaround to create stack traces: the backtrace module, which allows capturing stack traces that you can then add to the errors you return. The main problem with this approach is that you still have to add the stack trace to each error and also trust library authors to do so.

That's technically true, but the situation is not as dire. Many errors do not need stack traces. That so few carry a backtrace in Rust is mostly a result of the functionality still not being stable [1].

The I think bigger issue is that people largely have given up on stack traces I think, in parts because of async programming. There are more and more programming patterns and libraries where back traces are completely useless. For instance in JavaScript I keep working with dependencies that just come minified or transpiled straight out of npm. In theory node has async stack traces now, but I have yet to see this work through `setTimeout` and friends. It's very common to lose parts of the stack.

Because there are now so many situations where stack traces are unreliable, more and more programmers seemingly do lose trust in them and don't see the value they once provided.

I also see it in parts at Sentry where a shocking number of customers are completely willing to work with just minified stack traces and not set up source maps to make them readable.

[1]: https://github.com/rust-lang/rust/issues/99301

As to internal technology, it is written in Rust language and depends on them with big thanks:

Fast Node Manager lets us switch between them quickly. It's written in Rust which is a very cool language I know nothing about other than it runs really fast and is used for mission-critical systems.

Box::leak was added two years later in November 2017 https://github.com/rust-lang/rust/commit/360ce780fdae0dcb31c...

>Crashes, stability, and performance issues are still not safety issues since there’s so many ways to cause those beyond memory leaks.

They aren't safety issues according to Rust's definition, but Rust's definition of "unsafe" is basically just "whatever Rust prevents". But that is just begging the question: they don't stop being serious safety issues just because Rust can't prevent them.

If Rust said it dealt with most safety issues, or the most serious safety issues, or similar, that would be fine. Instead the situation is that they define data races as unsafe (because Rust prevents data races) but race conditions as safe (because Rust does not prevent them in general) even though obviously race conditions are a serious safety issue.

For example you cannot get memory leaks in a language without mutation, and therefore without cyclic data structures. And in fact Rust has no cyclic data structures naturally, as far as I am aware: all cyclic data structures require some "unsafe" somewhere, even if it is inside RefCell/Rc in most cases. So truly safe Rust (Rust without any unsafe at all) is leakfree, I think?

Let's continue our journey into Go. Last time, we got Go set up in WSL and covered some fundamentals like values, variables, and constants. This time, we'll dive into for loops and conditional blocks, the building blocks of decision-making and iteration in Go. We're working our way through Go by Example if you want to follow along.

Related Go Issue

and http3 is being implemented https://github.com/golang/go/issues/70914

Since Go has strong backwards compatibility guarantees, they're unlikely to commit to APIs that may need to change in the standard library.

Go, created by Google, has become a favorite in the backend world thanks to its simplicity, speed, and built-in concurrency through goroutines and channels. Its compiled nature allows for highly performant applications that often outperform interpreted languages, making it an excellent choice for robust backend systems.

[2]: https://github.com/golang/go/issues/71497

Learning things is fun so I've decided it's time to learn go and because I enjoy making these little series I thought I'd write about it too.

It's not just system calls. E.g. reflection package uses unsafe too: https://github.com/golang/go/blob/master/src/reflect/value.g... .

Unfortunately, OS vendors like microsoft are quite incompetent at running root stores https://github.com/golang/go/issues/65085#issuecomment-25699...

I don't think any reasonable member of the Go community would claim that any aspect of the language and its standard library is perfect. The many open issues on https://github.com/golang/go attest to that.

One example, if I may: the errors.As function is far from ergonomic. It would have been much better if generics had come to the language before that function was added to the standard library. Modern alternatives exist: https://pkg.go.dev/github.com/jub0bs/errutil

A similar issue in Go, that I've encountered in real code: https://github.com/golang/go/issues/27505#issuecomment-71370...

In a nutshell, if you want to use the death signal, which is very handy and useful, you also need to lock an OS thread so that it can't be destroyed. Fortunately I'm only spawning one process so I don't need to jump through hoops, I can just dedicate a thread to it, but it would be inconvenient to want to spawn lots of processes that way.

Speaking more generally, a lot of things that I learned in the 200xs apply to "processes", and things I just osmosed over the years as applying to "processes", were changed to apply to "threads" over the decades and a lot of people have not noticed that, even now. Even though I know this, my mental model of what is associated to a thread and what is associated to a process is quite weak, since I've not yet needed to acquire a deep understanding. In general I would suggest to people that if you are dealing with this sort of system programming that you at least keep this general idea in your head so that the thought pops up that if you're having trouble, it may be related to your internal beliefs that things related to "processes" are actually related to "threads" and in fact just because you did something like set a UID or something somewhere in your code doesn't necessarily mean that that UID will be in effect somewhere else.