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

181–190 of 203 posts

Re: Four Years of Rust

#181

Post by lenkite »

rubber_duck wrote: post #151
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

AFAIK, F# has still got some wrinkles for AOT support. https://github.com/dotnet/corert/issues/6055

Re: Four Years of Rust

#182

Post by jamil7 »

vram22 wrote: post #123
jamil7 wrote: post #94

Earlier quoted context omitted.

Not sure about emacs but vim basically requires a period of fighting through how horribly unproductive you will initially be, give it a week or two and you'll be ok.

Doesn't have to be so. See my other comment in this thread: https://news.ycombinator.com/item?id=19923720

Nice tips, thanks!

Re: Four Years of Rust

#183

Post by lzutao »

est31 wrote: post #114
wtetzner wrote: post #102

Earlier quoted context omitted.

> Major theme of the year, but not major theme of the language. One year of stability followed by one year of working on the next breaking idiom change followed by one year where that change is executed doesn't give you a stable language. Doesn't C++ have exactly this problem? It keeps adding new features, which change the language idioms. It actually seems much worse than Rust in this area, as Rust is mostly re-enfo…

The C++ approach of adding new idioms by making the language fatter is of course not as nice as the Rust approach of having breaking changes and disallowing the old idioms. But then again, the people behind Rust have made usage of the try! macro harder for a questionably useful keyword that could have been named differently as well. And now it's part of the 2018 edition and you need two more characters to use the try…

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

Re: Four Years of Rust

#185

Post by hopscotch »

pimeys wrote: post #106
wyatwerp wrote: post #97

Earlier quoted context omitted.

Is the speed bump for other-language libraries or for other-language applications? For speeding up other-language libraries, D has a -betterC mode, which prevents you from using the subset of the language and the libraries (standard & user-defined) that relies on GC. The remaining language is a very clean C that simply works on the other language's GC'd memory (using the other language's C interface), and can use sta…

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?

Re: Four Years of Rust

#186

Post by batisteo »

pzmarzly wrote: post #9
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 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 :-/

Re: Four Years of Rust

#187

Post by Lorkki »

pzmarzly wrote: post #9
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 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…

It's a lot smoother than stable RLS, but type resolution is practically nonexistent for futures-based code due to trait support still lacking. Definitely excited to check back once that's resolved though.

Re: Four Years of Rust

#188

Post by manwe150 »

dpc_pw wrote: post #167
manwe150 wrote: post #160

Earlier quoted context omitted.

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`.

That's probably a tricky question, since CPython is also essentially the spec. PyPy talks a bit about this: http://doc.pypy.org/en/latest/cpython_differences.html#diffe...

That's true, since Python has reflection it can't easily optimize that case, whereas that's a powerful benefit of having a linear type system for tracking ownership like Swift or Rust. But early freeing (which Rust has and Python does not) is slightly different from deterministic freeing (which both have) is slightly different from guaranteed freeing (which CPython has and Rust does not).

Re: Four Years of Rust

#189

Post by Hermitian909 »

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?

For shops that really care about highly performant parallel tasks, the difference matters. For people who just want more performance for free it's too much work versus what other languages provide.

If OCAML were already popular I don't think the lack of parallelism would be huge issue, but it's niche, which is a huge downside to any language in a business context. The upsides the language provides in terms of performance, ergonomics, and maintainability need to overcome that downside. All the issues I listed mean that OCAML can't generally pass that bar.

Re: Four Years of Rust

#190

Post by est31 »

lzutao wrote: post #183
est31 wrote: post #114

Earlier quoted context omitted.

The C++ approach of adding new idioms by making the language fatter is of course not as nice as the Rust approach of having breaking changes and disallowing the old idioms. But then again, the people behind Rust have made usage of the try! macro harder for a questionably useful keyword that could have been named differently as well. And now it's part of the 2018 edition and you need two more characters to use the try…

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 if you just had a compiler flag that invokes an user settable handler function every time Err() gets constructed or something like that.

To give concrete examples, I was developing a library to generate certificates [1]. Often you generate a wrong one though and the parser library you use for testing gives you a Err(BadDer). If that's everything you are getting it can be a bit tough to find out the origins. As it was using ? I had to grep for all the places returning a BadDer error and replace them with a panic. Shadowing try! would have been much easier.

[1]: https://github.com/est31/rcgen

Post reply on HN