Stupid alloc – What if memory allocation was annoying (github.com)

This isn't really a Rust problem. Even Java forces you to reckon with heap vs. stack allocation with its boxed types, and you'll get annoying warnings when you use Integer when int would do.

This is just programming culture; given two ways of doing something, with one being harder but more performant, we gravitate to the harder one at all costs.

I agree, but I don't know about a million :)

https://programming-language-benchmarks.vercel.app/rust-vs-j...

For giggles, also checkout the amount of generated machine code in godbolt with a simple Hello world that uses &str vs String. Its like 10x the instructions :P

If you don't understand how lifetimes and associated aspects of the language work, you might very realistically run into situations where your code will be a million times slower than the python, java, etc. equivalent, not faster. For instance, copying a massive dynamically allocated container in every iteration of a hot loop instead of passing a reference (much less likely to do on accident than in C++, but still possible), if you don't understand value vs reference semantics, copying, moving, etc, since garbage collected languages don't force you to learn these things, and passing around references to large collections is cheap in those languages.

Well you're not going to be much of a Rust user if you don't learn the basics of lifetimes anyway. I don't mean to get all gatekeepy, but if someone's not comfortable with &str and &[T], they're missing half the point of the language and won't be able to use much library code anyway.

If you don't care about allocations why are you using Rust in the first place?

Also if you are super sloppy with allocations I would expect something like Java or Go would be faster since GC is more efficient.

I like to pre-allocate a &str buffer at launch, then create &str variables pointing into that buffer. I separate them with 0x00 bytes so I don’t have to store an extra size counter or invent a new data type.

That works for some types of code and fails for other types. If you have very long lived but memory heavy apps, allocations really matter...

>now they have to learn all about lifetimes

If you do not want to learn about lifetimes do not use Rust. The advice is also terrible since inevitably you are going to use someone elses code, which does use slices.

> It's all still going to be a million time faster than whatever you were doing in Python, or Java, or Go, or Javascript, or whatever.

Not at all. Systems languages don't magically make all code faster, they just help you write fast code. It's not that hard to tank performance if you're careless with allocations. I've seen some really slow C++, written by people who liked to use new everywhere like it's Java.

If you want not to care about this stuff, I think that Java would fit your programming style better (or Kotlin, if you dislike Java's verbosity). The JVM is quite tolerant of doing lots of unnecessary allocations.

It already exists! https://github.com/cuviper/alloc_geiger

Not Rust, but it's very easy to wrap malloc under gcc for this kind of thing (or something more useful). Compile with --wrap=malloc and:

    void *__real_malloc(size_t);
    void *__wrap_malloc(size_t size) {
        ...
        return __real_malloc(size);
    }

I feel like Rust was designed to fully replace old languages, and is now facing the same issue as every language before it - C and C++ interop (both ways).

Zig nailed it, Rust fucked it up. Time will tell if thats big enough of an issue to warrant some bigger changes to fix it.

Rust can be called from C the same way as C++ can. You need to export unmangled extern "C" symbols. Not quite frictionless but there are helper utilities for this.

If the Rust code uses the "StupidAlloc" allocator, it should work as expected. There may be some constructor/destructor code involved with its usual complications.

But it would not replace malloc/free in C code nor will it be compatible with C++ allocators for std containers.

It has been practical for ages. You define a wrapper function as no_mangle and extern "C", then compile the lib as a staticlib. When compiled, it produces a .a file you can link into your C application

fairly straightforward:

        #[global_allocator]
        static GLOBAL: StupidAlloc = StupidAlloc;
        
        #[no_mangle]
        pub unsafe extern "C" fn stupid_malloc(size: usize) -> *mut u8 {
            let layout = Layout::from_size_align(size, 1).unwrap();
            GLOBAL.alloc(layout)
        }
        
        #[no_mangle]
        pub unsafe extern "C" fn stupid_free(ptr: *mut u8) {
            let layout = Layout::from_size_align(1, 1).unwrap();
            GLOBAL.dealloc(ptr, layout)
        }

then build with --crate-type cdylib, giving you a .so you can link

> C/C++ project/programmer

There is no such thing.