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

31–40 of 203 posts

Re: Four Years of Rust

#31

Post by msvan »

yawn wrote: post #30
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.

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.

Re: Four Years of Rust

#33

Post by thrower123 »

wyatwerp wrote: post #24
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…

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.

Re: Four Years of Rust

#34

Post by Hermitian909 »

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.

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 you want to hear when you're just trying to set up your first server.

Documentation is, in general, bad. Most packages just give a list of function signatures.

The community is small, academic, and often French.

Re: Four Years of Rust

#35

Post by vijaybritto »

My journey with rust has been a single application serving a couple of endpoints from an sqlite database. Its never going over 50Mbs of memory. It has been a solid rock for the past year no matter the hiccups in traffic!

Re: Four Years of Rust

#36

Post by robohamburger »

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

We're embarking on a major project to re-architect the compiler and write a next-generation RLS. It's on this year's roadmap. See here for more: https://ferrous-systems.com/blog/rust-analyzer-2019/

> It has high latency: because build is costly, it is invoked at most once per x seconds, which means you either have to wait to get the results, or get stale results.

I find this is the worst part right now. Latency is everything if it is tied to actual typing in of code.

Excited to see this get fixed, or at least improved!

Re: Four Years of Rust

#37

Post by adamnemecek »

thrower123 wrote: post #33
wyatwerp wrote: post #24

Earlier quoted context omitted.

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.

I think that part of the reason it didn't pick up is because it was made during an era when talking about the problems of C++ was brushed aside with "learn to program kiddo".

Re: Four Years of Rust

#38

Post by wyatwerp »

thrower123 wrote: post #33
wyatwerp wrote: post #24

Earlier quoted context omitted.

Are you describing the D language? https://dlang.org C-like syntax and execution speed with high-level scripting-language-like conveniences, close to Lisp-level ability to generate code at compile time, an active user-base ( https://forum.dlang.org ) that continuously strives to get the language improved. Its (thread-local) memory heap is GC'd by default. They also have an LLVM back-end if that is pertinent. Recently…

D is a weird one, because it has been lurking around for at least a decade and a half without really picking up the kind of steam and hype that later entrants have. I remember dabbling with D for game development way back in high school, as a friendlier alternative to C++.

Well, Standard ML is a weird one too in that sense (lurking around for a couple of decades without picking up steam (outside academia?)). Languages having type inference and modules designed into them seems to have a good chance to live long.

Re: Four Years of Rust

#39

Post by thelastbender12 »

yawn wrote: post #22
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…

This is exactly how I feel. I'd be all about Rust if it was GC'd. Go is close enough that it's what I reach for for personal projects, but not having ADTs and pattern matching is super frustrating for modeling data.

curious, does Swift potentially fill this gap for you?

Re: Four Years of Rust

#40

Post by estebank »

steveklabnik wrote: post #28
estebank wrote: post #26

Earlier quoted context omitted.

What would stop you from using Rc/Arc/RefCell to have reference counting and internal mutability where you need it?

It's really, really awkward to use them everywhere.

They are, and it is one of the places where I'd see us working towards improving their ergonomics in the next couple of years. In the meantime I'm convinced that most code falls either on "small enough that they can be Copy" or big balls of state that also need internal mutability. For people just arriving to the language I always recommend "don't be afraid of .clone(), .clone() until you understand the rest of the language, then jump deeper into borrowing/lifetimes". I would love to have some affordances to avoid having to give that advice.
Post reply on HN