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

161–170 of 203 posts

Re: Four Years of Rust

#161

Post by sanxiyn »

pornel wrote: post #130
pjmlp wrote: post #113

Earlier quoted context omitted.

Only to the GC hating crowd. Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.

If GC & runtime is on the table, then there are many nicer languages you can use (Go, D, Swift, Kotlin). I assume that the C and C++ users who haven't switched yet are largely the "GC-hating" crowd that can't. COM and other refcounted ones get a pass. But I'm surprised that Unreal gets away with a mark-and-sweep GC. Perhaps because it's only required for UObjects, and the rest of the codebase can still easily avoid u…

Isn't Swift also refcounted?

Re: Four Years of Rust

#162

Post by nullwasamistake »

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…

Vscode has great Typescript and JS support. Arguably the best of any editor. I still use jetbrains for other languages, it's really hit or miss.

Re: Four Years of Rust

#163

Post by zbentley »

pcwalton wrote: post #72
jnordwick wrote: post #41

I really want to like Rust, and I've made a few attempts in the past to get involved - I wrote a database driver for a time series database (KDB) in pure Rust among a few other things. I've even done a couple deep dives into rustc to figure out the cause of some iterator slowness (it wasn't giving proper hinting in the LLVM IM). However, I keep having to step back. And in this short time Rust has progressed a lot (an…

Well, async I/O is important to get early. Otherwise we're going to have an entire ecosystem of synchronous networking code, and there's no going back from that. You can look at languages like Ruby for what happens if you don't get an async I/O story before the package ecosystem develops.

Java seems to have done pretty well, and it didn't have broad stdlib support for asynchronous I/O until a few years ago.

Re: Four Years of Rust

#164

Post by pjmlp »

renox wrote: post #139
pjmlp wrote: post #113

Earlier quoted context omitted.

Only to the GC hating crowd. Unreal and UWP/COM developers are perfectly fine with writing C++ code with a GC around.

Try to broaden your horizons.. I work in telecoms only one step away from a FPGA, a 1ms pause would be a critical bug report..

My horizons are already broaden.

https://atlas.cern/discover/detector/trigger-daq

You can also try to broaden yours.

https://www.ptc.com/en/products/developer-tools/perc

Will this work for you? I guess most likely not, and you really cannot afford any kind of delay, where even a C++ virtual call would be considered a bug, given the 1ms delay.

The point being that only a very tiny population has such requirements, just like barely anyone writes applications 100% fully in Assembly.

Re: Four Years of Rust

#165

Post by pjmlp »

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

D structs have destructors, for example.

Dealing with borrow checker on cases that are still being worked on (NLL 2, GUI callbacks), using unsafe for graphs or dealing with use-after-free array indexes for the alternative workaround, unsafe Drop implementations, doesn't look hassle free to me.

Re: Four Years of Rust

#166

Post by pjmlp »

sanxiyn wrote: post #161
pornel wrote: post #130

Earlier quoted context omitted.

If GC & runtime is on the table, then there are many nicer languages you can use (Go, D, Swift, Kotlin). I assume that the C and C++ users who haven't switched yet are largely the "GC-hating" crowd that can't. COM and other refcounted ones get a pass. But I'm surprised that Unreal gets away with a mark-and-sweep GC. Perhaps because it's only required for UObjects, and the rest of the codebase can still easily avoid u…

Isn't Swift also refcounted?

Reference counting is a GC algorithm, as per CS curriculum.

Re: Four Years of Rust

#167

Post by dpc_pw »

manwe150 wrote: post #160
dpc_pw wrote: post #132

Earlier quoted context omitted.

> 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

Oh, interesting. But from what I read it's only an implementation detail of CPython?

With `with`I can't eg. pass an open file to another function to eg. be closed there etc.

Example:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

closing `File` will happen at the end of `foo` or `foo2`.

Re: Four Years of Rust

#168

Post by pjmlp »

AlexanderDhoore wrote: post #84
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…

Before Vim I had to look for an editor every time I learned a new language. Now I just use Vim. For everything.

If the only thing you do with programming is typing text sure, my IDEs do a little more than that.

Re: Four Years of Rust

#169

Post by pjmlp »

wyatwerp wrote: post #99
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?

This is going further & further OT, but hey - I didn't start it! What you need is a motivating factor. Vim is almost guaranteed to be there on any Linux/BSD/Mac shell environment, which motivates people in those environments to learn it even if they learn no other editor. Beyond such environments, like on any desktop GUI, what'd motivate you to try GUI Vim? For Emacs, I can say the integration between any set of tool…

I would like to see a UI designer or UML layout written in elisp, including support for third party components.

Re: Four Years of Rust

#170

Post by pjmlp »

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…

Java wasn't the original idea, Pascal P-Code from UCSD was it, among several other ones.
Post reply on HN