Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in 2018: easier to use

jvns.ca

Post reply on HN
Print view View original

151–160 of 305 posts

Re: Rust in 2018: easier to use

#151

Post by coldtea »

vhakulinen wrote: post #51
pjmlp wrote: post #41

Earlier quoted context omitted.

Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.

Writing GUI with rust is totally possible: http://gtk-rs.org/

Yeah, but the parent point is that "possible" is a very low bar.

Re: Rust in 2018: easier to use

#152

Post by coldtea »

amelius wrote: post #110
pjmlp wrote: post #91

Earlier quoted context omitted.

It is possible, but far from productive, which I learned exactly by trying to use Gtk-rs to port an old basic Gtkmm demo, that I used for a C/C++ Users Journal article.

Wasn't Rust invented to write a GUI? A webbrowser can be regarded as a kind of GUI.

No, it was invented to write a generic (web) rendering engine.

So, even if we consider a web app as a GUI, Rust wasn't invented for writing that (you still use CSS, HTML, JS etc for that part). It was invented for writing the backend for that UI.

In other words, Rust is not GTK (a UI library), it's C (the language the UI library itself is written in).

Re: Rust in 2018: easier to use

#153

Post by coldtea »

littlestymaar wrote: post #108
rapsey wrote: post #84

Earlier quoted context omitted.

Anyone pinning hope on limn should take a look at the activity on the project since start of December.

I wouldn't be too pessimistic about a project just because the main author stopped pushing changes for one month in the holliday season. It also happened in August for the same project and work resumed later at a fast path.

If the project has only one main author, I would be. Even more so if they are on and off and not paid for it. Heck, TextMate and somewhat Sublime Text had such issues with 1 single dev, and those are projects that actually make them money...

Re: Rust in 2018: easier to use

#154

Post by z0ltan »

xfer wrote: post #143
z0ltan wrote: post #31

Earlier quoted context omitted.

I have always been interested in OCaml, but I have a genuine question though - last when I looked at seriously at it, the standard library seemed to be a bit of a mess lacking a lot of features. A lot of modern resources seemed to focus on using Jane Street's Core(?) which I would not like to use - I'd rather depend on the standard language for standard features. Is this still a thing, or am I mistaken, or both? Plea…

You don't need Core, the shipped stdlib is good enough for toy projects. There are other stdlibs like containers and janestreet has split their stdlib into smaller pieces. What's your issue with having to use alternate stdlibs? Regarding books, Real World Ocaml is very well written, although some examples might need tweaking.

Thanks for the reply!

Mostly wondering how people ship stuff if there are different variants of std libs? Say you write your code entirely using one std lib and then try to share it (the code that is) with somebody who uses a different std lib, then the onus of learning the new std lib is entirely on him, right? How does that work for teams then? I know that Jane Street is a big user and so they have considerable influence. That being said, does the std lib (the one bundled with the distro) have enough features (like all the necessary data structures, for instance) to make using it viable in a non-trivial project (off the top of my head, say writing a very simple web server)? If so then, I suppose that's good enough.

Any recommendations for learning material? I have a copy of "Practical OCaml", don't really like it. INRIA's materials seem quite substantial, but more like reference.

Re: Rust in 2018: easier to use

#155

Post by jeremyjh »

grayrest wrote: post #9

I expect a "it's easier to use" evangelism push around the upcoming epoch release. There are a bunch of mostly completed but still feature flagged changes that should remove a lot of the borrow checker toe stubbing. Getting rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part of the push. Aside from the almost completed features in the pipeline, I only see procedural macros (macros 2.0) and wh…

You can already get “Monad comprehensions” through the mdo and mdo-futures crates.

Re: Rust in 2018: easier to use

#156

Post by bjz_ »

grayrest wrote: post #9

I expect a "it's easier to use" evangelism push around the upcoming epoch release. There are a bunch of mostly completed but still feature flagged changes that should remove a lot of the borrow checker toe stubbing. Getting rustfmt (formatter) and clippy (linter) on stable Rust would ideally be part of the push. Aside from the almost completed features in the pipeline, I only see procedural macros (macros 2.0) and wh…

> [1] I'd really like to see F# Computation Expressions instead of async/await. I know the language experts have said Haskell-like do notation doesn't work in Rust but I'm not sure if the F# tweaks would make it work or not.

I'd prefer a systems-y, zero-cost take on algebraic effects, similar to what OCaml is going to get. Could be much more extensible, and open things up to annotating whether functions panic or not, access global state, etc. Alas it's still a tricky research problem, even after all these years. There were some nice discussions from ICFP here - the comments strayed into talking about how effects might be implemented without a GC: https://www.youtube.com/watch?v=DNp3ifNpgPM

Re: Rust in 2018: easier to use

#157

Post by z0ltan »

erk__ wrote: post #62
z0ltan wrote: post #31

Earlier quoted context omitted.

I have always been interested in OCaml, but I have a genuine question though - last when I looked at seriously at it, the standard library seemed to be a bit of a mess lacking a lot of features. A lot of modern resources seemed to focus on using Jane Street's Core(?) which I would not like to use - I'd rather depend on the standard language for standard features. Is this still a thing, or am I mistaken, or both? Plea…

You could also take a look at F# wich is also a ML derived language so the syntax is very similar to OCaml.

I did consider it seriously (especially after watching Scott Wlaschin's Parser Combinators video), but it seems a bit too MS-centric for my liking. Who knows, maybe if learning OCaml doesn't pan out that well, it might be F# for me! :D ... the community seems to be focused, so that's one big advantage.

Re: Rust in 2018: easier to use

#158

Post by chmln »

pjmlp wrote: post #41
eecc wrote: post #24

Julia writes she wouldn’t yet use Rust to write webservices. Right there, this could be the mission for 2018. http://www.arewewebyet.org Nobody with a sane mind would write C or CPP micro-services, but post-Spectre and Meltdown any reclaim in performance is tangibility valuable. Rust could be the one to swoop in and claim the position

Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity, unless we are speaking about tiny IoT devices with a few KBs. Also, it is not yet fit for writing GUI code. It is quite far from what is possible to achieve today in Qt/WPF/Cocoa/Android/... tooling and even the latest NLL improvements don't fix all issues regarding writing callbacks.

> Neither I think Rust is fit for that purpose, any GC language is a better fit in terms of productivity

There is nothing in Rust that makes it inherently unfit for APIs or the web. To dismiss the entire language is simply lazy. Having GC also doesn't necessarily make one language superior to another.

While http ecosystem is still in active development, if there was really a choice between Rust and JS for e.g. writing an API I would go with Rust in a heartbeat.

Re: Rust in 2018: easier to use

#159

Post by seanmcdirmid »

littlestymaar wrote: post #114
pjmlp wrote: post #99

Earlier quoted context omitted.

Just because a language has a GC, doesn't mean it doesn't have language features to have more fine grained control over how memory allocation takes place, or even when the GC has to run if at all.

In that case it's no different from Rust, Rust has a GC option (ref counting). It's limited and opt-in then you still carry the cognitive burden of memory management, you have to think when to use it. But if you need that level of control, you'll need to think about memory anyway. And in my experience, it's way easier to reason about allocations in Rust that it is in Java (automatic type erasure if you want to use ge…

UWP has ref counting, garbage collection (via C#), and stack allocation. It does native compilation to boot, unfortunately it isn’t quite universal.

Re: Rust in 2018: easier to use

#160

Post by raverbashing »

civility wrote: post #86
raverbashing wrote: post #74

Earlier quoted context omitted.

Because your code has bugs and/or security vulnerabilities. It's pretty safe to assume this without looking at your code

Heh, so does yours. I can say this without even knowing what language you use to write your software, much less looking at it... All software has bugs, and most of those are security vulnerabilities waiting to happen.

Of course. Code is hard.

Using a safer language makes it easier and less prone to out-of-bounds memory accesses.

By using C/C++ you're choosing to make a hard problem harder.

Post reply on HN