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

181–190 of 305 posts

Re: Rust in 2018: easier to use

#181

Post by amelius »

coldtea wrote: post #152
amelius wrote: post #110

Earlier quoted context omitted.

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

Ok what is the GUI of Firefox written in/using?

Re: Rust in 2018: easier to use

#182

Post by Thaxll »

chmln wrote: post #158
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.

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

Except it takes 10x time to write anything backend related. Why would you choose Rust over Java / C# / Go ect ...?

Re: Rust in 2018: easier to use

#183

Post by coldtea »

amelius wrote: post #181
coldtea wrote: post #152

Earlier quoted context omitted.

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

Ok what is the GUI of Firefox written in/using?

Until recently-ish something called XUL, a markup language for UI (similar to HTML, or even better XAML). Not sure if they've moved on since.

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL

Re: Rust in 2018: easier to use

#184

Post by vvanders »

sho_hn wrote: post #53
rapsey wrote: post #49

Earlier quoted context omitted.

You're comparing a language to an OS and three GUI frameworks.

I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolki…

Qt uses way more than vanilla C++ though, it practically has its own dsl for a whole host of things.

Re: Rust in 2018: easier to use

#185

Post by kod »

setzer22 wrote: post #167
StreamBright wrote: post #10

Well it is super easy to develop hello world in Rust. Yay! Last time I checked there was no decent HTTP client and the documentation is just non existent for that subpar library. There were lost of promises about the newer version of async io library yet it is still WIP as of today. The performance was 30 times less than the same code in Java and after consulting many Rust developers nobody could tell me why. It is n…

So if a language can't do HTTP and async I/O (with state-of-the-art performance) then we shouldn't consider any other possible application for it? Rust is not Java, you have better languages to build webservers with.

Yes, if a language can't easily do async IO and HTTP in 2018, it is in deep shit with regard to long term adoption. The Rust devs realize this, otherwise they would be putting less effort into tokio.

Re: Rust in 2018: easier to use

#186

Post by computerphage »

Thaxll wrote: post #182
chmln wrote: post #158

Earlier quoted context omitted.

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

Except it takes 10x time to write anything backend related. Why would you choose Rust over Java / C# / Go ect ...?

Except that number is completely made up. Why do believe it takes ten times as long?

Re: Rust in 2018: easier to use

#187

Post by robohamburger »

yen223 wrote: post #12

This is going to sound weird, but I would like to see a garbage-collected Rust. Take away the borrow checker, and you still have a modern language with UTF-8 support out-of-the-box, algebraic data types, pattern matching, a focus on performance, and great tooling (cargo + rustup = OCaml almost fits the bill (Rust is inspired by OCaml after all), but the tooling around it is lacking to put it mildly.

I agree. Part of whats kept me going is the language is very nice, even though I don't always need borrow checking.

I wonder how threading would work without the borrow checker though. It would be cool if you could still have the "fearless concurrency part".

Re: Rust in 2018: easier to use

#188

Post by sho_hn »

vvanders wrote: post #184
sho_hn wrote: post #53

Earlier quoted context omitted.

I think there's some merit to the statement nonetheless - e.g. Qt is native to C++ and its API designed around C++ language features and semantics in many ways. There has been success in writing bindings for languages that can emulate those semantics without too much pain (e.g. PyQt), but Rust is not one of them. Inside the Rust community, there's been a lot of debate about what an idiomatic Rust API for a GUI toolki…

Qt uses way more than vanilla C++ though, it practically has its own dsl for a whole host of things.

This often gets over-reported; old memes die hard.

There's a small number of macros that a custom preprocessor expands to (very pedestrian) generated code, but they are optional to use (though it's certainly uncommon not to use them) and these days there's template-based versions of some of them that are preferred and steadily finding adoption over the macro ones because they're superior. Beyond that there's a few more normal preprocessor-based macros that are entirely optional.

In that sense Qt also tracks vanilla C++ very closely and has adopted features from newer language versions at a fairly steady pace and swiftly for such a large production library set.

None of this matters much to my point though - that was about much more basic language semantics like classes-based OOP and the absence of ownership rules.

Re: Rust in 2018: easier to use

#189

Post by Thaxll »

computerphage wrote: post #186
Thaxll wrote: post #182

Earlier quoted context omitted.

Except it takes 10x time to write anything backend related. Why would you choose Rust over Java / C# / Go ect ...?

Except that number is completely made up. Why do believe it takes ten times as long?

What Rust framework replace Java spring or equivalent, none of them so you have to write everything yourself. Rust doesn't have any ecosystem to write service side services so you're going to spend time by just re implementing a framework.

Re: Rust in 2018: easier to use

#190

Post by laumars »

coldtea wrote: post #153
littlestymaar wrote: post #108

Earlier quoted context omitted.

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

That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute (and the community did want to contribute when it looked like development had stalled). Where as limn is open source so if it does prove worthwhile but development stalls it would be trivially easy for any number of other developers fork the git repo and carry on the work.
Post reply on HN