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

191–200 of 203 posts

Re: Four Years of Rust

#191

Post by sriram_malhar »

davemp wrote: post #75
sriram_malhar wrote: post #59

Earlier quoted context omitted.

You speak of low latency code and doubly linked lists in the same breath. Personally, I have moved from linked data structures to more cache friendly data structures, which means contiguous spaces. No jumping around. It's very liberating.

Doubly linked lists are used all over for low level programming. For low access, large dynamic data they're a pretty good solution AFAIK.

I wasn't speaking of low-level programming. I was referring to very low-latency code.

Highly performant code tends to get complex. One way to ensure high performance and reduce complexity is to deal with values, not pointers; it is good for concurrency (no aliasing), excellent for cache locality, and the value is right there. Multi-versioned stable values work excellently, like RCU-locks in the Linux kernel.

Re: Four Years of Rust

#192

Post by Rusky »

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…

> 4. Official C++ extension despite being completely useless consumes several gigabytes of space for "indexed" files (I wonder if it is so bad to not hurt sales of Visual Studio).

I chuckled at this, because the implementation is actually shared between the official C++ extension and Visual Studio. That extra space usage is likely the recent addition of automatic PCH generation (to VS Code, VS has done that for a long time).

Re: Four Years of Rust

#193

Post by pimeys »

hopscotch wrote: post #185
pimeys wrote: post #106

Earlier quoted context omitted.

We've been rewriting a big Scala code base to Rust now since January and the team is advancing in a nice pace. Our plan was: - Take one part of the system to rewrite over JNA - Run a massive amount of Scala tests against the new code - When green, take another part - Meanwhile the other part of the team writes the user-facing code base, connecting it to the new Rust crates - The test suit works also over an integrati…

Why are you migrating from Scala?

The company wants much lower resource usage per node and easy integration with other languages.

Re: Four Years of Rust

#194

Post by lzutao »

est31 wrote: post #190
lzutao wrote: post #183

Earlier quoted context omitted.

What are the cases when `try!` macro bettern than `?` operator? I'm a beginner to Rust so I don't know about that.

Often when you are getting error messages you would like to find the place they originate. Failure provides backtraces but not everyone uses failure and tbh it's quite a heavy dependency, using serde and so on. With try!, you can easily shadow the macro to e.g. emit a panic. This can be done to basically any codebase using try!, even if it's not yours. Migrating it to use failure is much harder :). It would be cool i…

Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.

Re: Four Years of Rust

#195

Post by fnord123 »

fnordsensei wrote: post #92
AlexanderDhoore wrote: post #84

Earlier quoted context omitted.

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

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?

Emacs is physically destructive. The chording will destroy your hands. This is why emacs enthusiasts need special keyboards or foot pedals.

https://www.emacswiki.org/emacs/FootSwitches http://ergoemacs.org/emacs/emacs_best_keyboard.html http://ergoemacs.org/emacs/emacs_pinky.html

Vim is great, but after 20 years of using it, I'm moving mostly to Jetbrains stack since flying around the code is faster and syntastic (a vim plugin) is slow as shit on large projects. Thankfully the vim bindings in Intellij are pretty darn faithful.

Re: Four Years of Rust

#196

Post by est31 »

lzutao wrote: post #194
est31 wrote: post #190

Earlier quoted context omitted.

Often when you are getting error messages you would like to find the place they originate. Failure provides backtraces but not everyone uses failure and tbh it's quite a heavy dependency, using serde and so on. With try!, you can easily shadow the macro to e.g. emit a panic. This can be done to basically any codebase using try!, even if it's not yours. Migrating it to use failure is much harder :). It would be cool i…

Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.

That only gives you backtraces for panics, but not for errors based on the Result type.

Re: Four Years of Rust

#197

Post by maltsev »

batisteo wrote: post #186
pzmarzly wrote: post #9

Earlier quoted context omitted.

I can recommend https://tabnine.com/ with https://github.com/rust-analyzer/rust-analyzer . While rust-analyzer doesn't always resolve type (unlike Jetbrains Rust plugin, which always does but sometimes incorrectly), it still makes writing code faster and doesn't have RLS quirks (which come from the fact that RLS has to compile the code before offering suggestions, so code has to be correct at some point, which is not…

Too bad TabNine is a Freemium :-/

When working with Rust code you get all paid features for free: https://tabnine.com/faq#language

Re: Four Years of Rust

#198

Post by lzutao »

est31 wrote: post #196
lzutao wrote: post #194

Earlier quoted context omitted.

Thanks through I still don't get it. I only know that you can get backtraces of errors by setting `RUST_BACKTRACE=1`.

That only gives you backtraces for panics, but not for errors based on the Result type.

I am not serious. Often in these cases I would use printf debugging to know where the errors came.

(I am still a Rust beginner).

Re: Four Years of Rust

#199

Post by dpc_pw »

pjmlp wrote: post #176
dpc_pw wrote: post #172

Earlier quoted context omitted.

D's destructors are not deterministic, IIRC. > 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. Valid points, but these are rare problems in idiomatic Rust. Specifically avoiding graphs by structuring code into a tree of ownership, has greatly improved architecture of my programs, to the point that I just…

> D's destructors are not deterministic, IIRC. Yes they are, they get called at the end of scope. > Valid points, but these are rare problems in idiomatic Rust. Being rare doesn't mean they aren't there, and anyone trying to write UI related code will deal with them on regular basis.

https://forum.dlang.org/thread/tsfgbmakzcrxwqreheiq@forum.dl...

Can you clarify, what am I misunderstanding here? In couple of places online I've found that you can't depend on dtor being called.

Re: Four Years of Rust

#200

Post by renox »

pjmlp wrote: post #164
renox wrote: post #139

Earlier quoted context omitted.

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

I'll look at your links but to answer to your question: yes virtual functions are not accepted in the code.
Post reply on HN