Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust 1.24

blog.rust-lang.org

Post reply on HN
Print view View original

51–60 of 215 posts

Re: Rust 1.24

#51

Post by sidlls »

Rotareti wrote: post #40
kzrdude wrote: post #34

Earlier quoted context omitted.

When I use Python I miss Rust's enums, the pattern matching of those enums, and the static types that help refactoring (the compiler spots where one change has knock-on effects in the rest of the project..). Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me. I don't think Rust is better than Python for every task. Python is a lot simpler if you can ge…

> Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me. In recent versions Python got some nice improvements in this area, with the new way of creating NamedTuples , Data Classes and the typing module. I wrote a stackoverflow answer recently that sums it up, if anyone is interested: https://stackoverflow.com/a/45426493/1612318

Those artifacts in Python don't really compare with what the parent laments. Rust's sum types are one of my top reasons for preferring the language.

Re: Rust 1.24

#52

Post by burntsushi »

steveklabnik wrote: post #33
MrBuddyCasino wrote: post #30

Earlier quoted context omitted.

> Compiles to a relatively standalone binary (not as good as Go though) Whats the difference?

We use glibc by default, so while Rust statically links all Rust code by default, that's still dynamically linked. You can use MUSL to remove that, where appropriate, but it's not the deafult.

To add an additional clarification here for others (I know Steve knows this :P), by default, at least on Linux, whether Go produces a dynamic executable or not depends on which things you import. For example, a simple hello world program will produce a static executable:

    $ cat main.go
    package main
    
    import "fmt"
    
    func main() {
            fmt.Println("Hello, world!")
    }
    $ go build
    $ ldd scratch
            not a dynamic executable
But anything using the network, like a simple HTTP server, will cause the Go tool to build a dynamic executable:

    $ cat main.go
    package main
    
    import (
            "log"
            "net/http"
    )
    
    func main() {
            // Simple static webserver:
            log.Fatal(http.ListenAndServe(":8080", http.FileServer(http.Dir("/usr/share/doc"))))
    }
    $ go build
    $ ldd scratch
            linux-vdso.so.1 (0x00007fff161f0000)
            libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f796b0e8000)
            libc.so.6 => /usr/lib/libc.so.6 (0x00007f796ad31000)
            /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f796b306000)
Now of course, you can set flags to force Go to always produce a static executable, but the difference here isn't too much different with Rust. With Rust, you do need to install MUSL, add the target and then rebuild with an extra flag, but it's all very simple.

(To be clear, I am not criticizing Go here! There are good reasons why they link to libc by default when network stuff comes into the picture.)

Re: Rust 1.24

#53

Post by comex »

Manishearth wrote: post #10
Felk wrote: post #7

Earlier quoted context omitted.

If I'm not wrong, UTF-8 continuation bytes always start with binary 10, where ASCII always starts with 0 and multi-byte starts start with either 11 (2 bytes), 111 (3 bytes) or 1111 (4 bytes)

That doesn't solve the problem of searching for multibyte character AB and finding multibyte character CB instead :) Or, searching for multibyte character ABB (like U+A041 YI SYLLABLE PA) and finding the first "B" instead of the second "B". Sadly there's no memchr for consecutive sequences of characters. memchr2/memchr3 let you search for multiple needles in the haystack, not a bigger needle.

There’s memmem...

Re: Rust 1.24

#54

Post by azdle »

AceJohnny2 wrote: post #47
yazaddaruvala wrote: post #14

Earlier quoted context omitted.

Have there been any thoughts around making the compiler something akin to a stateful server with an embedded datastore for the caching rather than using the filesystem?

What would be the benefit of this approach over using the filesystem?

I'd imagine it would be a benefit where, let's say, every project has `byteorder` in its dependency tree somewhere. If you had a local, stateful, build server that processes every build on your machine, you could re-use the object file from the last time you compiled that library regardless of if it was for this project or not. That's probably not a big gain for just `byteorder`, but if you multiply that by many libs or take into account some of the much bigger ones it could make quite a difference in build time. Even "first" build time for new projects you're building.

IIRC, some group in mozilla has already has something working that works like ccache that works (or rewrote ccache to work) with compiling rust. (Which I think is what steveklabnik is alluding to in his neighboring comment.) Although I guess that might only work within a single code base, not sure about that.

Re: Rust 1.24

#55

Post by jhasse »

steveklabnik wrote: post #33
MrBuddyCasino wrote: post #30

Earlier quoted context omitted.

> Compiles to a relatively standalone binary (not as good as Go though) Whats the difference?

We use glibc by default, so while Rust statically links all Rust code by default, that's still dynamically linked. You can use MUSL to remove that, where appropriate, but it's not the deafult.

What's the problem with that? Do you use any of glibc's private API?

Re: Rust 1.24

#56

Post by whyever »

Rotareti wrote: post #40
kzrdude wrote: post #34

Earlier quoted context omitted.

When I use Python I miss Rust's enums, the pattern matching of those enums, and the static types that help refactoring (the compiler spots where one change has knock-on effects in the rest of the project..). Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me. I don't think Rust is better than Python for every task. Python is a lot simpler if you can ge…

> Especially how Rust enums and structs make it easy to define new types to guide your programs are a highlight for me. In recent versions Python got some nice improvements in this area, with the new way of creating NamedTuples , Data Classes and the typing module. I wrote a stackoverflow answer recently that sums it up, if anyone is interested: https://stackoverflow.com/a/45426493/1612318

There are not sum types though.

Re: Rust 1.24

#57

Post by steveklabnik »

azdle wrote: post #54
AceJohnny2 wrote: post #47

Earlier quoted context omitted.

What would be the benefit of this approach over using the filesystem?

I'd imagine it would be a benefit where, let's say, every project has `byteorder` in its dependency tree somewhere. If you had a local, stateful, build server that processes every build on your machine, you could re-use the object file from the last time you compiled that library regardless of if it was for this project or not. That's probably not a big gain for just `byteorder`, but if you multiply that by many libs…

You're thinking of https://github.com/mozilla/sccache which is not quite the same thing.

Re: Rust 1.24

#58

Post by steveklabnik »

jhasse wrote: post #55
steveklabnik wrote: post #33

Earlier quoted context omitted.

We use glibc by default, so while Rust statically links all Rust code by default, that's still dynamically linked. You can use MUSL to remove that, where appropriate, but it's not the deafult.

What's the problem with that? Do you use any of glibc's private API?

The problem is that you have to think about it at all. If you compile on a machine with a new libc, and then try to run it on a machine with an old libc, it won't work. So you end up doing what most people do, even outside of Rust, which is take the oldest CentOS box you can stand and do builds on that.

Re: Rust 1.24

#59

Post by foota »

azdle wrote: post #54
AceJohnny2 wrote: post #47

Earlier quoted context omitted.

What would be the benefit of this approach over using the filesystem?

I'd imagine it would be a benefit where, let's say, every project has `byteorder` in its dependency tree somewhere. If you had a local, stateful, build server that processes every build on your machine, you could re-use the object file from the last time you compiled that library regardless of if it was for this project or not. That's probably not a big gain for just `byteorder`, but if you multiply that by many libs…

Man, I bet that would be blazing fast!

Re: Rust 1.24

#60

Post by currymj »

Etzos wrote: post #27
michaelchisari wrote: post #18

Earlier quoted context omitted.

Performance is quite a bit higher for rust. And it's a much safer language by design (and forces the programmer to be as such). That said, development time in Python is much faster. Honestly, it depends on what you're building.

I'm curious what parts of Rust you think are safer than Python. Edit: The only big thing I can think of is the safety of compile-time type checking to ensure you won't end up with some kind of runtime error from mismatched types. Is there something I'm missing?

the type-checking catches lots of memory errors (irrelevant in a GC language like Python, but wouldn't be caught by the compiler in C or C++), but it also catches data races when writing concurrent code, which is definitely something that could happen in Python.
Post reply on HN