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

81–90 of 203 posts

Re: Four Years of Rust

#81

Post by wtetzner »

lmm wrote: post #20
weberc2 wrote: post #17

Earlier quoted context omitted.

I'm definitely in this category. I think I want "Go with generics and enums and Cargo" (and no, OCaml folks, I am not describing OCaml). I want to write more Rust, but I rarely can afford to trade off on Go's productivity for Rust's performance and safety.

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.

I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project.

The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at least didn't) without a lot of extra work, and it seemed like most packages were designed only for unixish OS's.

There are projects where I've used Rust instead of OCaml, even though I'd have preferred to use OCaml, simply because the infrastructure is so much better and easier to use for Rust.

Re: Four Years of Rust

#82

Post by eikenberry »

weberc2 wrote: post #17
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…

I'm definitely in this category. I think I want "Go with generics and enums and Cargo" (and no, OCaml folks, I am not describing OCaml). I want to write more Rust, but I rarely can afford to trade off on Go's productivity for Rust's performance and safety.

From the looks of things you'll probably get the Go you want first. The only thing missing from the roadmap are enums and there are a few Go2 proposals for them.

Re: Four Years of Rust

#83

Post by ynnn »

msvan wrote: post #31
yawn wrote: post #30

Earlier quoted context omitted.

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.

Multicore OCaml is actually making promising progress, but I agree that the standard library situation is a little bit unfortunate.

Sadly, that's what I've been hearing for at least 5 years.

Re: Four Years of Rust

#84

Post by AlexanderDhoore »

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.

Re: Four Years of Rust

#85

Post by wyatwerp »

pornel wrote: post #76
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…

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 + runtime doesn't preclude performance, for a long-running program. Of course, for short-running programs, just malloc, don't free, is the fastest.

Re: Four Years of Rust

#86

Post by msvan »

wtetzner wrote: post #81
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.

I love OCaml, but my biggest pain point is not having something like Cargo. I haven't spent a lot of time with opam since 2.0 came out, so maybe it's better now, but when I used it it felt very much designed around installing packages globally, instead of defining dependencies per-project. The other issue with the package ecosystem is cross-platform support. While OCaml itself works on windows, opam doesn't (or at le…

Esy (https://esy.sh/) has completely solved the first problem, fwiw.

Re: Four Years of Rust

#87

Post by tomcatfish »

yingw787 wrote: post #4

@steveklabnik what would you say are the core tenets of Rust's success? From Python's side (as a Python prosumer), I'd say Python's core tenets may be: - Building an explicitly and observably welcoming open source community - Separating corporate money from technical direction, even at the cost of faster execution - Upholding pragmatism over all else (e.g. keeping around a C/C++ API) I'm not sure whether these princi…

As a CS major in school who is mostly self taught using the internet, I'd say Rust's big win is how it takes basic concepts from low to high level without bothering me or killing performance entirely.

Just the presence of well integrated Algebraic Data Types (ADTs) makes an incredible amount of difference. They are used to represent errors in a meaningful and easy to understand way (```Result```), are used to show that a function may or may not return a meaningful value without needing a garbage value (```Option```), and the optional case can even be used to wrap a null pointer scenario in a safe way (```Option>``` being the closest to a literal translation I think).

That's just one small feature that permeates the language. Whatever the opposite of a death-of-a-thousand-cuts is, Rust has it.

Re: Four Years of Rust

#88

Post by UnpossibleJim »

amelius wrote: post #74
UnpossibleJim wrote: post #47

Earlier quoted context omitted.

Not to be the nay sayer here, but garbage collection kind of goes against the premise of Rust, as stated by the mission statement. I'm a fan of Rust, but I also like Python, but they are different tools for different problems. Go seems like the tool for your specific problems. I'm not trying to be offensive towards you, or anything, but Rusts mission statement was written pretty clearly and the reasons against a garb…

If this is true then Rust is the wrong tool for many projects in which it is currently used. Most of those projects are not an OS or driver and are far from the metal. Even the compiler itself would not fit your description.

It doesn't HAVE to be used for bare metal, but that's what it's best at, but it is bad for quick prototyping, that's for sure. So if you had a project that needed a project that needed quick turn around and rapid prototyping and someone wanted to use Rust because it's the "new hotness" or whatever, then absolutely not. It's the wrong tool for the job. The same as C, or C++ would be the wrong tool. Python is great for something like that.

Just like if you wanted heavy number crunching and data manipulation, I'd push someone towards R and Scala as they have the libraries to handle it (and, I'd also say Python, but I'm starting to show my biases here). Go is great for back end systems, as that's what it was designed for, and it's now getting libraries built out for it for other things to fill in gaps for other things, just as Rust is filling in other spaces, but there's only so far it can go from its original design doc. The GC makes it, inherently, not a systems language. That doesn't mean it isn't great at other things. Rust is great as a systems language, that doesn't mean it isn't great at other things, but it's terrible as a rapid prototyping language. It lacks that capability. It wasn't designed for that =/

Re: Four Years of Rust

#89

Post by est31 »

steveklabnik wrote: post #48
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…

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 year where that change is executed doesn't give you a stable language.

Also consider the pace of compiler updates. With C++, I can be very productive with my distro provided compiler. With Rust, the ecosystem is jumping onto new compiler versions so fast that you basically have to use rustup or a rolling release distro when you have a project with a medium amount of crates you depend on (hundreds). Cargo further has no way of recognizing the MSRV of crates and it's updating the index without asking so you can't even safely add new dependencies or update dependencies without increasing the MSRV of your Cargo.lock.

All of this can change, and maybe the rate of modifications will slow down. But right now it rather points towards the opposite direction, with the recent introduction of editions.

Re: Four Years of Rust

#90

Post by pimeys »

wyatwerp wrote: post #85
pornel wrote: 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 +…

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.
Post reply on HN