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

201–210 of 305 posts

Re: Rust in 2018: easier to use

#201

Post by coldtea »

laumars wrote: post #190
coldtea wrote: post #153

Earlier quoted context omitted.

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.

>That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute

It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute.

Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the project's blog. And that's for a hugely used and know project. I doubt a Rust UI lib would get more than that.

Re: Rust in 2018: easier to use

#202

Post by wwweston »

foldr wrote: post #120
pjmlp wrote: post #104

Earlier quoted context omitted.

In the words of Rob Pike: "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to…

I don't see what that has to do with offshoring. Developers of the kind Rob Pike is referring to exist everywhere in the world.

Exactly. :)

Re: Rust in 2018: easier to use

#204

Post by gbersac »

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 am surprised no one already mentionned Scala. It perfectly fit the bill ans is even more mature !

Re: Rust in 2018: easier to use

#205

Post by vvillena »

gbersac wrote: post #204
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 am surprised no one already mentionned Scala. It perfectly fit the bill ans is even more mature !

The main problem of Scala is that it brings in the whole JVM. That's awesome for certain kinds of apps, but not so great for other things like small tools. I have high hopes on scala-native, though!

Re: Rust in 2018: easier to use

#206

Post by alkonaut »

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.

There are plenty of language choices fitting nearly every feature set.

What I’d like to see is for one language to be possible to use “vertically” through a stack. That is - for example a C# systems version with manual memory that you can use instead of C interop for the small core of your app. Or, the opposite, a dumbed down version of Rust that works well for classic reference heavy UIs and similar.

Re: Rust in 2018: easier to use

#207

Post by wongarsu »

gravypod wrote: post #139
d33 wrote: post #83

Earlier quoted context omitted.

What's wrong with this name?

Probably trademarks and copyrights.

Copyright doesn't apply to names, and the only US trademark for "clippy" is for medical equipment (and thus doesn't apply here) [1]. There doesn't seem to be any EU trademark for "clippy"

1: http://tmsearch.uspto.gov/bin/showfield?f=toc&state=4805%3At...

Re: Rust in 2018: easier to use

#208

Post by paulddraper »

gbersac wrote: post #204
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 am surprised no one already mentionned Scala. It perfectly fit the bill ans is even more mature !

The biggest difference is that Scala requires JVM (or JS).

But if you are willing to accept runtime GC, a JIT runtime like JVM/Node might also not be out of the question.

So Scala Native would be spot on, if it were ready for production use.

Re: Rust in 2018: easier to use

#209

Post by Conan_Kudo »

coldtea wrote: post #201
laumars wrote: post #190

Earlier quoted context omitted.

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.

> That's not a fair comparison as they weren't open source so it was impossible for the community to help contribute It is fair, as whether it's possible for the community to contribute is a moot point if the community wont contribute. Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the proje…

> Heck, GTK+, which is used by millions, had just one person working on it full time a few years ago (not sure if changed since), and lamenting how there's no community help in the project's blog. And that's for a hugely used and know project. I doubt a Rust UI lib would get more than that.

This is not true for GTK+ 3. GTK+ 2, however, has been in maintenance mode since the introduction of GTK+ 3 and has been in that state since.

Re: Rust in 2018: easier to use

#210

Post by penetrarthur »

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

It is not about languages. It is mostly about frameworks. I want to write my next web project in a mature framework.
Post reply on HN