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

Four Years of Rust

blog.rust-lang.org

Post reply on HN
Print view View original

141–150 of 203 posts

Re: Four Years of Rust

#141

Post by pimeys »

steveklabnik wrote: post #129
pimeys wrote: post #111

Earlier quoted context omitted.

We have the whole team waiting for this to land. We're probably going with nightly already due to the problems fitting Futures 0.1 model to our codebase. Very nice to hear.

The proposed syntax has already landed in nightly, so you could use it right now if you wanted, by the way.

I've been trying a couple of approaches already, but first we're aiming correctness and after that async/await.

Many libraries use tokio::spawn behind the scenes, so it seems we need compat from 0.1 to 0.3 and back to 0.1 to get old futures to work with async/await and the resulting futures to work in 0.1 tokio.

Last time I checked the async/await feature in tokio had some weird crashes and tokio::spawn crashes when used inside romio...

Re: Four Years of Rust

#142

Post by pornel »

buckminster wrote: post #128
wyatwerp wrote: post #85

Earlier quoted context omitted.

Taking nothing away from the Rust community that has managed such a complex language so well so long, I have to say that there never was anything viable in the no-GC no-runtime niche (that is why it is a niche - otherwise why would anybody be using GC'd languages). We were/are just gritting and bearing C++. If it is a typical program, i.e. not a device driver or OS kernel running on low-memory hardware, having a GC +…

> Of course, for short-running programs, just malloc, don't free, is the fastest. A custom malloc that knew free would never be called would be faster still. I wonder if any short-running utilities do this?

AFAIK the D compiler is basically this.

Re: Four Years of Rust

#143

Post by wyatwerp »

dpc_pw wrote: post #137
wyatwerp wrote: post #124

Earlier quoted context omitted.

As pjmlp said below, GC doesn't preclude deterministic destruction, so it isn't about resources in general; it is largely about memory. Also typical programs in any language have quite a bit of stack-allocatable data and C/C++/D/Go/Rust do support stack-allocatation, so the memory heap isn't involved everywhere. Wherever the memory heap is involved, if the system isn't memory-starved, it can be argued that determinis…

> indeed no mechanism to lazily schedule files/sockets for closure. It's not only about file sockets. It's about your core abstractions. Thread-pools, channels, flushing streams, events and other stuff, unlocking Mutexes, auto-validating guards etc... I have production or semi-production experience with code written in C, D, C++, Python, Go, Java, Node, Scala, Rust and others (please excuse argument from authority, b…

I wasn't talking about necessarily temporal operations like mutex ops; of course, they should be deterministically done - it is a beautiful implementation detail that it falls out of the principles of Rust, without explicit compiler support and/or "checked-delete" as is required in most other languages.

I meant lazy operations for avoiding unnecessarily making things like memory deallocation temporal. Unless you have a strict memory budget (and you might additionally need to have mitigation for memory fragmentation), freeing whenever GC deems it fit, or streams flushing whenever the OS/library deems it fit, can't be worse - but could potentially be better - for performance than being done only at points decided arbitrarily by the language and the program structure. It is simply easier to disable GC on critical paths.

But as you say, you are not (only) talking about performance. You are talking about determinism for predictability. I hope you are not implying predictability across various threads/processes that make up the system, only within 1 thread/process where that predictability leads to reliability.

Reliability across threads/processes needs strategy because failures are inevitable (yes, I have drunk the Erlang kool-aid too, among other ones). While I have no doubt that Rust's design principles would support developing such strategies, I do wonder as to what scale this would work up to ...

... as you say, I don't know the size of projects Rust has scaled to, I just know enough about Rust itself to balk at its complexity (and I am a C++ person!). Maybe we are just talking from different viewpoints. You, having done a variety of non-trivial production code in a plethora of languages, plump for Rust. But I honestly wonder about the size & longevity of your C/C++ semi-production code - semi, because it is C/C++ ;-) - I have worked on large C++ codebases for long-lived products, and I somehow can't see another complex language solving more problems net-net.

Re: Four Years of Rust

#144

Post by wyatwerp »

pornel wrote: post #142
buckminster wrote: post #128

Earlier quoted context omitted.

> Of course, for short-running programs, just malloc, don't free, is the fastest. A custom malloc that knew free would never be called would be faster still. I wonder if any short-running utilities do this?

AFAIK the D compiler is basically this.

And it is a short-running utility :-)

Re: Four Years of Rust

#145

Post by Waterluvian »

oselhn wrote: post #133
Waterluvian wrote: post #5

I love watching Rust progress. But the #1 thing I'm watching is the RLS and vscode plugin. Maybe I'm weird but I work with so many languages that having to manage multiple editors is a non-start. So any time I have a little personal project that could be done in Rust (for learning) I end up using Go or Python instead because the vscode support is still quite buggy. Naturally others will say you don't need IDE-like su…

I do not understand what people like about vscode. If I ignore insane resource consumption this is at most average IDE (the only real benefit over sublime "text editor" is integrated debugger). This is most preferred editor at work so I am forced to work with it and there are some of the most serious issues I have: 1. Only one side panel, so I can't see outline, test results and project files at the same time as I am…

It works well enough for the 6 languages I use weekly. I'm honestly too busy doing all the other engineering tasks that don't happen inside Vscode to really care that it's not perfect. I don't live in vscode that much each week to really care.

Re: Four Years of Rust

#147

Post by njepa »

wyatwerp wrote: post #138
njepa wrote: post #131

Earlier quoted context omitted.

In my experience C++ programmers aren't necessarily great programmers as such. Because low levels things usually requires domain knowledge and experience more so than programming brilliance.

The topic was the no-GC no-runtime niche, which necessarily requires brilliant programmers, and they are stuck with C++. They would welcome tools to represent their resource control well, borrow checking or deny capabilities. As a current C++ programmer who remembers what GCC 2.95's error messages looked like for even simple templates, I second you - it is less about the intellect, and more about experience and enoug…

I definitely think it is needed. I just don't think Rust has solved the paradox that the more you need something specialized the less you can afford the overhead.

Finding hundreds of web developers with some spare time who don't mind learning Rust, can port some of their tooling and use it in some part of their stack isn't going to be much of a problem. The same isn't true if you, say, need an embedded programmer who has worked with zigbee and needs to be in your lab for testing and verification.

Pretty much all major programming languages are where they are as a result of being some kind of "lowest common denominator" for their application. Something like Bash is pretty horrible as a programming language, but extremely accessible for sysadmins. Only now is it changing slightly were things like Python and Go is becoming more popular, but mostly because they are easier than the alternatives.

Re: Four Years of Rust

#148

Post by wyatwerp »

renox wrote: post #140
Hermitian909 wrote: post #34

Earlier quoted context omitted.

As someone who really enjoys OCAML, it has a variety of issues that prevent it from becoming popular (though I'm hopeful for reasonML). No multicore Standard library has... issues No community consensus on a common base setup, questions about which library to use for a task often get answers like "well, do you want to use functors or monads? because that will change the library we recommend" which is really not what…

Honest question: what is so bad about having to create one process per core? If you have lots of data you can use shared memory, so the performance should be similar no?

I don't know. Maybe because it is GC-only? It doesn't have custom allocators, so there may be no easy way to map an object to some location in shared memory.

Re: Four Years of Rust

#149

Post by wyatwerp »

p0nce wrote: post #118
xvilka wrote: post #63

Earlier quoted context omitted.

Modern OCaml (4.06+) is not that bad, but yeah, lack of proper parallelism and bad Windows support (without hacks like MinGW or Cygwin) is what still hurts. Standard library these days is only one - Base, one buildsystem - Dune, Camlp4 is dead, and compiler improved a lot recently (including speed if you enable flambda).

You guys are welcome to D, you may enjoy unboxed floats, guaranteed monomorphization and native threads. Also, 3 backends.

The reference compiler is as free-standing as OCaml's because it too has its own back-end. Its front-end is shared with the other 2 back-ends: feeds the ubiquitous LLVM in LDC, and is included as a supported front-end in GCC since version 9.1.

Anyway, there is no way you'd give up ML-tradition pattern-matching; D doesn't have it.

Re: Four Years of Rust

#150

Post by dpc_pw »

wyatwerp wrote: post #143
dpc_pw wrote: post #137

Earlier quoted context omitted.

> indeed no mechanism to lazily schedule files/sockets for closure. It's not only about file sockets. It's about your core abstractions. Thread-pools, channels, flushing streams, events and other stuff, unlocking Mutexes, auto-validating guards etc... I have production or semi-production experience with code written in C, D, C++, Python, Go, Java, Node, Scala, Rust and others (please excuse argument from authority, b…

I wasn't talking about necessarily temporal operations like mutex ops; of course, they should be deterministically done - it is a beautiful implementation detail that it falls out of the principles of Rust, without explicit compiler support and/or "checked-delete" as is required in most other languages. I meant lazy operations for avoiding unnecessarily making things like memory deallocation temporal. Unless you have…

> I meant lazy operations for avoiding unnecessarily making things like memory deallocation temporal.

Yes, I wasn't talking about real-time/performance consideration. The root post was along the lines of "Rust is nice, but I like productivity of a GC". I'm saying deterministic destruction is more productive for the developer and Rust makes a great high-level language.

Regarding stuff like non-blocking deallocation etc. You can still do it in Rust if so you desire. In the a destructor, enforced by the type, you can use nice abstractions, etc. and eg. defer deallocations, or draw memory from an arean. I think eventually Rust will just have more or less standardized type for GCs and graphs with explicit roots etc.

But sure, it is all still very new here, so if one is writing a real-time trading or OS, maybe they should stick to C/C++.

> But I honestly wonder about the size & longevity of your C/C++ semi-production code - semi, because it is C/C++

In C I worked on code powering embedded chips (mostly radio communication, kernel modeules) and eg. real-time hypervisor powering some high-end cars. In C++ eg. some high-perf data management stuff (data dedupilcation, encryption, etc.) in a SV unicorn. I actually would describe myself as C (as opposed to C++ person), but I know my around modern C++ quite well - i just really don't like working with it.

> I somehow can't see another complex language solving more problems net-net.

I don't think Rust is actually that complex. It is definitely bigger than C, but I think it's much smaller than C++. And it is sane. Thinks play well together in it, I think I could get a new dev productive with Rust in a week or up to a monthy, and as long as you avoid `unsafe` in Rust they will produce a decent code with ease. In C++ you're either an "expert" or you're debugging segfaults. ;)

Post reply on HN