alchemio

You can use std containers in a no-exceptions environment. Just know that if an error occurs the program will terminate.

checksec is part of the pwntools suite. Along with other tools for finding ROP gadgets and shellcode generation.

The most shocking part is the absence of stack canaries. I know there are issues with them on microcontrollers, but still I would assume they’re enabled by default by the compiler.

Python, rust and Go aren’t beacons of software stability though.

Zig’s general purpose allocator might detect use after free in debug builds, however zig appears to be ok with dangling (invalidated) pointers/slices and use after free for stack variables, which is more concerning, especially from a security standpoint.

```zig

const std = @import("std");

fn get_ptr() i32 { var a: i32 = 6; return &a; }

pub fn main() void {

    var x: ?*i32 = undefined;
    {
        var a: i32 = 5;
        x.? = &a;
    }
    std.debug.print("{} {}", .{ x.?.*, get_ptr().* });

}

``` These are trivial examples that Zig doesn’t even warn about, even though similar code in C or C++ gets a warning in gcc and clang.

This discussion:

https://ziggit.dev/t/what-makes-ban-returning-pointer-to-sta...

indicates that core zig devs aren’t interested in diagnosing such usage.

But it does. He has to notify R4L of what his changes were and how it broke the Rust driver. Even if he didn’t, he will still be contacted for information regarding these things.

So they stirred a whole lot of drama for not much, potentially harming R4L.

Flash apps and Java applets (via Cheerp) can run again in browsers thanks to wasm.

Embrace, Extend, Extinguish, Endow

> It is undoubtedly hard work to fix these remaining problems, as they typically require both rust and C knowledge in addition to deep HTTP familiarity. There does not seem to be that many persons interested or available for this challenge. Meanwhile, there is little if any demand for hyper from existing (lib)curl users.

You might as well replace HTTP with OS, hyper with rust and curl with linux, and you get the current situation with Rust adoption on Linux.

RustyBuzz is quite limited when compared with HarfBuzz. The Rust fonts scene also seems to lack the necessary momentum to drive things through. I’m not sure whether it’s because the Rust community is mostly interested in webtech or whether Rust itself makes it hard to solve such complex problems. But I don’t see the sands shifting in less than 10 years to come.

Memory allocation is slow and undeterministic in perf. Some allocations also require a global lock on the system level. It’s also a point of failure if the allocation doesn’t succeed, so there’s an extra check somewhere. Furthermore if every object is a pointer you get indirection overhead (even though small but existent). Deallocation as well incurs an overhead. Without a compacting gc you run into memory fragmentation which further aggravate the issue. All of this overhead can be felt in tight loops.

Which make? I’m guessing you mean gnu make, well there’s several incompatible variants as bsd make and nmake. Also bash is not universally used, not windows, not current macos.

It’s looking like the same fate awaits Rust in the linux kernel!

Exactly

It really doesn’t matter and that’s my point.

It’s something Zig touts when compared to other languages(1). The idea is that in the end it’s a convention that an allocator needs to be passed to indicate that the function allocates, which not even the stdlib adheres religiously to. I’m fine with it since I do believe a library writer should know best what works with their library.

1. https://ziglang.org/learn/why_zig_rust_d_cpp/#no-hidden-allo...

Just a correction: most std C functions don’t allocate. strdup does but it was only recently adopted into the standard, it was previously an extension.

Similarly zig’s stdlib shouldn’t allocate behind your back, except for thread spawn where it does: https://github.com/ziglang/zig/blob/5cd7fef17faa2a40c8da23f0...

Generally speaking, it’s as mentioned just a convention. A zig library might not allow its users to pass allocators for example.

In C++, stl containers can take an allocator as a template parameter. Recent C++ versions also provide several polymorphic allocators in the stdlib. You can also override the global allocator or a specific class’ allocator (override placement new).

So rewrite the browser in Rust!

Rust is 10 years old this year, yet there are no production level browsers or operating systems written in it!

I’m talking about Google. They come up with article after article about the failings of C++, yet would prefer starting their own programming language Carbon, continue using C/C++ for chrome, zircon and android.

I for one appreciate this article. It sheds light on the history of V and its undelivered promises; and save me wasted time trying it or reading their site.

I’m excited to try mojo. I just don’t wanna create an account just to try it.

Are there companies contributing to the Rust compiler?

Unlikely. At least less likely compared to discord and reddit!

This project is amazing. It also speaks to the strength of Ojective-C vs Swift which barely runs anywhere that’s not an apple os.

C++ is the most important source inspiring Rust throughout its development. Rust devs just like to downplay that role.

- Rust has interface inheritance with pretty much the same syntax

- Rust’s generics are monomorphized, exactly like C++ templates. They also have the same syntax. The only difference is that Rust generics are trait bound.

- Rust RAII is used exactly as it’s used in C++. Moves in Rust are destructive, while in C++ they are not. At the time where move semantics were proposed for C++ in the C++03 era, both types were proposed and the committee decided to go with non-destructive moves.

- Scope resolution syntax is also a carryover from C++.

When the words superset and subset are used in regards to C, C++ and Objective-C, it is quite a misunderstanding to describe C as a subset of Rust.

Zig is plenty fast for a compiled language with optimizations. The Go compiler has no debug/release profiles and the generated machine code isn’t as optimized as say a language using llvm. If you compare it to C++ or Rust, Zig actually has better compile times, and it keeps improving.