Live data from Hacker News

Four Years of Rust

blog.rust-lang.org

101–110 of 203 posts

Re: Four Years of Rust

#101

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?

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

Re: Four Years of Rust

#102
post #89

Earlier quoted context omitted.

There's a lot here, and I don't have a ton of time, and the important thing is that this is about your experience, so I won't say you're wrong. But to add some context on a few things: > I'm about to take another shot at Rust, and I decided this time I should just ignore all the dislike of `unsafe` and just use it as much as I need to. What it sounds like to me is that you struggled to learn Rust , and instead tried…

> > However, I think Rust has moved too fast in the language department. ... I'd like the language to stabilize a bit and work on what is currently there > This is actually the major theme of this year! https://blog.rust-lang.org/2019/04/23/roadmap.html 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…

> 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-enforcing the existing idioms, while C++ is almost like two different languages now (well, probably even more than two).

Re: Four Years of Rust

#103

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?

`vimtutor` It's installed everywhere vim is.

Re: Four Years of Rust

#104
post #76
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…

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-li…

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient](https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no...). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any imperative PL.

I have (re-)implemented couple of real-life projects, and each time Rust was much better higher-level language than eg. Java, Python or JS. Borrow checker fights are non-issue in practice: just avoid references, pass messages as copies and when you have to share data use `Arc` and copy on write (or just add `Mutex`).

There's a reason why Rust is most loved PL for 4 years in a row. Once you try it, and get past initial adjustments (mosty: what owns what relationship) everything clicks, and I guarantee that you won't miss GC at all.

Re: Four Years of Rust

#105
post #89

Earlier quoted context omitted.

> > However, I think Rust has moved too fast in the language department. ... I'd like the language to stabilize a bit and work on what is currently there > This is actually the major theme of this year! https://blog.rust-lang.org/2019/04/23/roadmap.html 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…

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

> C++ is almost like two different languages now (well, probably even more than two).

C++ is a different language in every company I worked for. Ha. Even a different language per team/project sometimes.

Tab vs spaces, different capitalization, different indentation style, exceptions vs no-exceptions, 0 is failure vs 1 is failure and then we like featureA, we don't like featureB, and so on.

Re: Four Years of Rust

#106
post #90

Earlier quoted context omitted.

Having a GC also kind of makes it nasty to write libraries to other GC'd languages. In Rust all of this is very easy, and you can get the speed bump to your Ruby/Python/JavaScript libraries using a modern and safe language.

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 integration layer, so the other team can test their code and the backend with the same test suite

We're quite far already. Originally I was the only person with Rust experience. Now there's five of us.

Re: Four Years of Rust

#107
post #76

Earlier quoted context omitted.

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-li…

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

The use case for non-GC languages go significantly beyond low-level OS kernel type code. Most of our backend infrastructure software and servers (e.g. database engines) are also poor fits for a GC languages, and this is what Rust is targeting. For this type of software, a GC has a large negative performance impact, so it isn't really an option. Operational cost efficiency is often a key factor in platform selection -- being able to reduce hardware requirements by an integer factor is compelling.

To me, Rust is a cleaner and stricter but also more narrow systems programming language than C++, and can be used as a sensible replacement for many C++ code bases, particularly as Rust adds features. Rust still has some challenges. For example, the DMA-driven, schedule-based memory safety models that have become fashionable in high-performance database kernels are not compatible with Rust's memory model. You'd have to make most of the code "unsafe" (in a Rust sense, it is actually an alternative memory safety model designed around a different set of assumptions).

Re: Four Years of Rust

#108
post #104
post #76

Earlier quoted context omitted.

There are already several decent GC languages. If Rust was just another GC language, I don't think it would have attracted such a strong community required to develop all of these things and break out of obscurity. It'd be another Go with generics, or Elixir-native, or Swift with uglier syntax. In the no-GC no-runtime niche for a very long time there was nothing viable besides C and C++. For programmers who want C-li…

I don't really understand why people would want a GC over deterministic destruction like in Rust. GC is [neither necessary nor sufficient]( https://ruudvanasseldonk.com/2015/10/06/neither-necessary-no... ). Ownership model in practice is much more convenient precisely because objects can act like resources and implement their cleanup logic, and the business logic can rely on it. It's a great improvement in any impera…

I think mainly because mastering new concepts increases the barrier to entry, overhead and scope. Which in turn affects creativity. There are many brilliant programming languages, used by brilliant programmers, yet, most really useful software tends to be produced by whatever. It would be awesome if Rust could overcome that, but I don't really see how currently.

Re: Four Years of Rust

#109
post #13

Kudos! When Rust 1.0 was announced I had a look. I was very surprised because that language was very different from my previous look, when Rust still had GC and green threads (and a syntax with mystic sigils). Rust 1.0 looked like it could be a good language, but coming from mainstream languages with a richer ecosystem -- such as Java/Scala or C# --, Rust lacked many common libs. For instance, a high-level approach t…

rust is getting HOTT? :p

Re: Four Years of Rust

#110

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?

Clojure for the Brave and True has a really nice Emacs primer
Post reply on HN