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

151–160 of 203 posts

Re: Four Years of Rust

#151

Post by rubber_duck »

msvan wrote: post #11

I wonder how many Rust users really want linear types and borrow checking, instead of the other stuff Rust brings to the table: modern language design, large and friendly community, nice type system, native compilation, good package ecosystem. Personally I would prefer a well-designed GC'd language with a strong type system and native compilation over Rust, unless I was doing something with specific demands on parall…

You can AOT C#/F#/.NET

It has value types, Span, PInvoke etc. that make low level interop simple, GC and higher level semantics and better ecosystem/tooling than most alternatives.

Runtime size and GC limit some use cases

Re: Four Years of Rust

#152

Post by pornel »

ddffre wrote: post #146

Were the major security vulnerabilities fixed? I remember all the talking while back about the major bugs regarding the language.

Short answer: yes

Long answer: it depends whether you mean actual vulnerabilities, or soundness bugs

Known bugs that could affect security of programs written in Rust get fixed ASAP. There was one serious bug in std's VecDeque that caused memory corruption. There was a more recent issue where if you override type_id method that wasn't supposed to be overridden, and then use another method that relies on type_id being correct, you get crashy garbage. In C or C++ that'd be called garbage-in, garbage-out, and a bad programmer shooting themselves in the foot. In Rust that was considered a vulnerability.

Apart from that, there are known soundness bugs in the language/compiler/LLVM that could lead to undefined behavior, miscompilation, or otherwise weasel out of things that the language is meant to guarantee:

https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...

At this point these are mostly edge cases that you're unlikely to hit in real code, but if you really really want to make your program crash, Rust can't stop you.

Re: Four Years of Rust

#153

Post by wyatwerp »

dpc_pw wrote: post #150
wyatwerp wrote: post #143

Earlier quoted context omitted.

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 et…

I truly was curious about your C/C++ code - good for you that it was less C++ and more C! I don't know any masochists, so I don't know anybody who likes to work in C++ (even with just composition and generics), or even any reluctant "expert". I get away from segfaults because I am on server & can get away by more static copying of data (it pales in comparision to what alternatives offer).

I can see why you think Rust is tractable; you have worked on fairly complex stuff like automobile base software (AutoSAR, was it?). I am probably not as good at it as you are, so the cognitive load of designing at that scale with borrow-checking seems prohibitive. I hope there is a way to slice the problem which makes for less cognitive load.

Re: Four Years of Rust

#154

Post by wbl »

apo wrote: post #18

> Rust+WASM went from an experiment to a usable product, making rustc the first compiler with focus on supporting WASM This may be the most interesting use case of them all. WebAssembly is fast, but it's also not fun to write. There are languages like AssemblyScript and Lys that will let you write WebAssembly in what appears to be a higher-level language, but you're still schlepping bytes around and must build the en…

I'm curious what you think those wounds were.

Re: Four Years of Rust

#155

Post by Matthias247 »

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…

For C++ try the cquery extension. It's pretty good. It mostly helped me to provide IDE support (full code completion and navigation) for a project that wasn't supported by Visual Studio or any other IDE (embedded project based on gcc and a hacky makefile).

Re: Four Years of Rust

#156

Post by leonardmh »

deking wrote: post #101
fnordsensei wrote: post #92

Earlier quoted context omitted.

Try :q! On a more serious note: I have a long-term goal to learn either Vim or Emacs for various reasons, the above mentioned being one of them. It's hard to feel so spectacularly unproductive as I do when I try them out though, so it's easy to give up. What's there best way to go about learning Vim or Emacs?

I don't have any reference material/tutorials, but my major breakthrough with Vim was when I understood that normal mode is the norm. Anytime you're not entering text, be in normal mode. Remap jk or jj to escape. Get in the habit of typing it whenever you're done adding text. Use hjkl for movement instead of the arrow keys. Learn the f,t, and o commands. http://cloudhead.io/2010/04/24/staying-the-hell-out-of-inser...

“Normal mode” it’s right there in the name :)

Re: Four Years of Rust

#157

Post by akra »

yawn wrote: post #30
lmm wrote: post #20

Earlier quoted context omitted.

What is it you don't like about OCaml, or similar ML-family languages (e.g. F#)? Most of "modern language design" seems to amount to the ML featureset.

Not the grandparent, but... OCaml: multicore, standard library situation (which one?) is a mess, adoption. F#: Have to deal with null and lack of ADTs when you interact with .NET (or JS for Fable) standard lib. The tooling situation in F# has been a mess since .NET Core, especially in Linux. Treated as a 2nd class citizen by MS.

I'm using F# tooling in Linux and both VS Code and Jetbrains Rider's IDE's outclass most functional language IDE's at present IMO. It's greatly improved within the last year or so. If you use code most of your app in F# the null factor doesn't really bite you all too often and its not too hard to handle when it does.

Re: Four Years of Rust

#159

Post by dpc_pw »

wyatwerp wrote: post #153
dpc_pw wrote: post #150

Earlier quoted context omitted.

> 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 et…

I truly was curious about your C/C++ code - good for you that it was less C++ and more C! I don't know any masochists, so I don't know anybody who likes to work in C++ (even with just composition and generics), or even any reluctant "expert". I get away from segfaults because I am on server & can get away by more static copying of data (it pales in comparision to what alternatives offer). I can see why you think Rust…

> AutoSAR, was it?

Just a real-time hypervisor for Tegra underlying Nvidia Automotive platform. MISRA C, ISO 26262. Bleh. :D

> so the cognitive load of designing at that scale with borrow-checking seems prohibitive

I have multiple 1k - 10k line Rust projects on github, and I hardly ever deal or think about lifetimes. I just randomly opened a project of mine on github, opening some major files and there's literally 0 explicit lifetime annotations anywhere.

People hang up on lifetimes because they are unfamiliar, but for someone that gets some understanding and accepts "ways of Rust" (mostly avoiding cyclical graphs, using IDs instead of pointers, etc.), there are not an issue. Only when designing some weird zero-cost abstractions in performance-critical APIs, trying to avoid any copying, one has to annotate some lifetimes in non-trivial ways. Usually you can just ask someone on IRC and they will give you an answer. :D

The mental overhead is actually way lower than in C (or most languages for that matter). After a while you get used to relying on compiler to check the mundane stuff and focus only on the higher level problems. It's quite relieving actually.

Re: Four Years of Rust

#160

Post by manwe150 »

dpc_pw wrote: post #132
pjmlp wrote: post #112

Earlier quoted context omitted.

Because having a GC doesn't mean throwing away deterministic destruction. Many GC enabled system languages do offer both mechanisms. It is a matter of enjoying productivity it offers, while having the tools to fine tune performance when it actually matters.

> Many GC enabled system languages do offer both mechanisms. ? Can you give me an example? Java's `finalize` is not deterministic destruction. D's scope guards (or Go's `defer`) are also not like destructors, because a calling code has to take care of them. > It is a matter of enjoying productivity it offers, There's hardly any productivity gain, and it is being offset by productivity gained by a reliable and hassle-…

Not exactly a systems language, but Python has deterministic destruction (due to the use of reference counting) of non-cyclic data structures.

Edit: Oh, and if you don’t think that’s enough, note that Rust doesn’t guarantee destruction to ever occur in that case (“considered safe”): https://doc.rust-lang.org/book/ch15-06-reference-cycles.html

Post reply on HN