Live data from Hacker News

I Hope Rust Does Not Oxidize Everything

gavinhoward.com

181–190 of 195 posts

Re: I Hope Rust Does Not Oxidize Everything

#181

Earlier quoted context omitted.

function max with type parameter T with arguments a of type T and b of type T and returns a value of type T where T implements trait PartialEq Vs fn max (a: T, b: T) -> T where T: PartialEq

Limiting examples to a subset of Rust syntax will produce more readable answers, sure. You have no lifetimes and no borrows, and very limited generics.

The information density of the "human syntax" Rust syntax both remain linear in size, but with a significant different N.

    function max
    with
        a lifetime a,
        a lifetime b,
        and type parameter T
    with
        argument a of a reference to type T that lives as long as lifetime a
        argument b of a reference to type T that lives as long as lifetime b
    and returns a value of type parameter T
    where T implements trait PartialEq
Vs

    fn max(a: &'a T, b: &'b T) -> T

If you want a real life example:

    #[stable(feature = "rust1", since = "1.0.0")]
    impl IntoIterator for &'a Vec {
        type Item = &'a T;
        type IntoIter = slice::Iter;

        fn into_iter(self) -> Self::IntoIter {
            self.iter()
        }
    }


    An implementation of trait IntoIterator
    (that has been stable since Rust 1.0.0)
    with a lifetime a
        a type parameter T
        a type parameter A which implements the trait Allocator
    for a borrow for the duration of lifetime a of type Vec with type parameters T and A
    
        it has an associated type Item, which is a borrow for the duration of lifetime a of type T
        it has an associated type IntoIter, which is type Iter from module slice with parameters lifetime a and type T

        it has a method into_iter
            that consumes the receiver
            and returns associated type IntoIter
            
            the methods body
            calls method iter on the receiver
            and returns its resulting value

Re: I Hope Rust Does Not Oxidize Everything

#182

Earlier quoted context omitted.

Limiting examples to a subset of Rust syntax will produce more readable answers, sure. You have no lifetimes and no borrows, and very limited generics.

The information density of the "human syntax" Rust syntax both remain linear in size, but with a significant different N. function max with a lifetime a, a lifetime b, and type parameter T with argument a of a reference to type T that lives as long as lifetime a argument b of a reference to type T that lives as long as lifetime b and returns a value of type parameter T where T implements trait PartialEq Vs fn max (a:…

I'm not arguing that complex things will somehow become non-complex.

However, none of the human syntax of Rust includes things like :: or '. To a first approximation[1], those are the parts that people can experience as "ugly", and they are not present in the human syntax. This is what people mean when they say "sigil heavy" or "punctuation based" syntax -- things that are generally are not read out as such. This is the space where you can make arguments about beauty.

[1]: Only roughly so because your chosen human syntax still encodes some Rust syntax decisions like predeclaring generic lifetimes and types, and using "where" instead of an inline clause. Those parts of syntax can also be shuffled around for subjective values of "not ugly".

Re: I Hope Rust Does Not Oxidize Everything

#183
post #51

Earlier quoted context omitted.

There’s no reason you couldn’t have a rust jit for development then compile the code for production (or stick with a jit for prod too).

There's no reason? Are you sure about this? I think you mean there could theoretically be an interpreted Rust, but I don't think anyone has ever made a prototype of a Rust interpreter. The closest is probably rust-analyzer (the official language server), that maintains internal state and reacts to changes you make, but it doesn't create an executable artifact. The other is probably the Cranelift Backend ( https://git…

The cranelift backend itself has a JIT mode.

Re: I Hope Rust Does Not Oxidize Everything

#184

Earlier quoted context omitted.

IMO there was only a brief period of monoculture, and only if you consider C & C++ to be part of the same culture, which is a stretch. It started in the mid-80s when people stopped writing programs in Pascal and/or assembly, and stopped in the mid-90s when Java & Perl started to get used extensively.

I was talking about a monoculture specifically in the systems programming area. Java, Perl, PhP, Python, Ruby, JavaScript, C#, Go, these got popular but they use garbage collection and have limitations for systems programming. C and C++ were the only options for a long while.

Systems programming is just a niche. A large niche, but just a niche. But between when Pascal & Assembly stopped being used widely and before Java started being used widely C & C++ were used for pretty much everything.

Re: I Hope Rust Does Not Oxidize Everything

#185
"I like small programs with few dependencies. I will write my own I/O to avoid dependencies. And tokio is to dependencies what god objects are to object-oriented programming."

This is what is preventing me from using Rust. It is so tightly integrated with a package manager for libraries that trying to avoid crates.io and dependencies is like paddling against the current.

Re: I Hope Rust Does Not Oxidize Everything

#186

The author seems very anxious because Rust is getting traction and they don't like Rust. They're afraid that one day Rust will become a "monoculture" and everything will be written in it. I like Rust, but I consider this very, very unlikely. Rust has actually brought more choice to the programming language scenario. If we're talking about monoculture, let's talk about C/C++. For decades this was the only viable optio…

IMO there was only a brief period of monoculture, and only if you consider C & C++ to be part of the same culture, which is a stretch. It started in the mid-80s when people stopped writing programs in Pascal and/or assembly, and stopped in the mid-90s when Java & Perl started to get used extensively.

> if you consider C & C++ to be part of the same culture, which is a stretch

That’s my main gripe with most pro-Rust comments of this kind, to be honest. There are a few ways to write C and a lot of ways to write C++, and most of the C is quite unlike most of the C++. (I’m not counting marginal cases like raw GObject or raw COM as C here, I think those count as basically separate languages.)

The problem is, the Rust I’ve read (and read about) is methodologically and stylistically a replacement for most of the C++, but not a lot of the C. I don’t dislike the theory behind Rust—I’ve written Haskell, I’ve written SML, I read the Tofte&Talpin regions paper and some of the subsequent research more than a decade ago. I do dislike when people ask me to switch or even try to, of all things, shame me into switching from C to what presents itself as a better C++, in largely the same way that I dislike attempts to switch to C++ that claim it’s the same thing as C. No it isn’t. And I largely tune out when I read “C/C++”, because it implies the author does not get it.

(I’m aware there are other people that do get it, some of whom work on other programming languages. They just don’t write posts proposing Rust replace C.)

Re: I Hope Rust Does Not Oxidize Everything

#187

Earlier quoted context omitted.

People reject OCaml for these use cases due to the GC, but I wonder if this actually matters in practice. The optimizations that can be applied to ML languages (see MLTon for example) are very advanced and the ability to do multi core with ease (I know this is more recent to OCaml) can be a big performance unlock that is very hard to get right in C.

The GC does matter. Most applications are completely fine with having a garbage collector, but they are not fine with having multiple garbage collectors! Mixing multiple garbage collected languages is a recipe for complex bugs. At a minimum, reference cycles across the languages will result in memory leaks. Thus every garbage collected language tends to grow its own ecosystem of libraries, with the whole world having…

I see this same situation playing out with async executors. tokio is taking over, but it doesn't play well with other async executors. I just wrote a program that mixed tokio & glib and it wasn't fun.

This does feel like a soluble problem, so I hope they do figure it out. I think the first step might be something like without.boats' proposal to add something like https://github.com/zesterer/pollster to the standard library to establish a minimum common denominator.

Re: I Hope Rust Does Not Oxidize Everything

#188
post #166

I just cloned the Starship repo and cargo --release built it and it took six minutes and 30 seconds (which did feel interminable). The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else". My CPU is from 2012 . What on earth is he doing this on, a TI-83? Or am I missing some intricacy of whatever Gentoo is doing that would inherentl…

> The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else". That's weird, cargo displays the current crates under compilation, not files as that's not the compilation unit in Rust, the author seems to be fibbing.

    $ emerge -v starship
    
    Running `rustc --crate-name starship --edition=2021 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib 
    Running `rustc --crate-name starship --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin 
This person is using gentoo, gentoo does print it like that.

Re: I Hope Rust Does Not Oxidize Everything

#189

Earlier quoted context omitted.

People love to think that C++ is only used in systems programming, the thing is C++ is used everywhere . FORTRAN is being developed and improved, and new code, most notably in scientific domain, is still being written. What Rust did to C++ is what clang did to GCC. Wake the giant up. Rust will go nowhere, but it's the same for C++. Thinking that C++ will just fade to black is wishful thinking.

What new scientific applications are being written in Fortran?

Fluid dynamics codes are still being written in Fortran.

Notably, there are still improvements happening in the Fortran space, and there's been a bit of revival of sorts. There are still features in Fortran that make it nicer to write in than C++ (and while I'd hoped rust might be a good Fortran replacement, I feel rust has taken a different path, and remains no better than C++).

Re: I Hope Rust Does Not Oxidize Everything

#190

Projects adopting rust makes contributing less fun and more painful I tried to work on bug fix for Zed, waiting 30 seconds everytime you change a value was _very_ painful

The fact that i got downvoted says it all, people are in delusional mode

Zig devs are tackling the issue early, Rust devs are living with it, it's just sad

Post reply on HN