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

81–90 of 305 posts

Re: Rust in 2018: easier to use

#81

Post by llogiq »

curiousGambler wrote: post #36
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…

Why anyone would name anything "clippy" again is beyond me.

One of clippy's authors and maintainers here (though I didn't choose the name); why would you name such a program "lint"?

For me clippy evokes the image of a well-meaning, if at times clumsy helper that tries to nudge you in the right direction. I find that very fitting for a tool that...well...tries to nudge you in the right direction of writing good, fast, idiomatic code.

Re: Rust in 2018: easier to use

#82

Post by kbwt »

raverbashing wrote: post #74
banachtarski wrote: post #29

Earlier quoted context omitted.

> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.

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

I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known.

Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a simpler language.

Re: Rust in 2018: easier to use

#83

Post by d33 »

curiousGambler wrote: post #36
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…

Why anyone would name anything "clippy" again is beyond me.

What's wrong with this name?

Re: Rust in 2018: easier to use

#84

Post by rapsey »

IshKebab wrote: post #78
rapsey wrote: post #73

Earlier quoted context omitted.

Servo guys have the potential to make something amazing (i.e. a sane electron type library). But I'm not sure how much they care about that. Other then that there is nothing serious going on.

There's a project called Limn trying to do this. I doubt it has solved the ergonomics issue though.

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

Re: Rust in 2018: easier to use

#85

Post by sebcat »

banachtarski wrote: post #29
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

> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.

I also do this. I make use of Capsicum/seccomp-bpf and jail/chroot to a ro mountpoint, use SSP, ASLR where possible, ... But I still use C as my primary programming language. I've also written code in golang professionally for a year or two.

It's quite common in the embedded space to use C or C++. It's easy to run everything as root and skip fundamental bound checking, so those languages get a bad rep in that space. Totally understandable. But it is possible to engineer solutions that are a lot safer too. It's just a question of priorities. Companies not prioritizing writing safe code or not working on having a safe architectural design will not bother with Rust or other memory safe languages. There's little to no market incentive in most areas. Sad but true.

Re: Rust in 2018: easier to use

#86

Post by civility »

raverbashing wrote: post #74
banachtarski wrote: post #29

Earlier quoted context omitted.

> Nobody with a sane mind would write C or CPP micro-services why? I do this all the time. Maybe I should check into a nearby asylum.

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.

Re: Rust in 2018: easier to use

#87

Post by currymj »

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.

rust at one point had garbage-collected references. And there's still Rc/Arc types for reference counting.

I get what you're saying though. Another poster mentioned Swift and indeed Graydon Hoare, Rust's creator, is now working on Swift at Apple. And I believe some kind of notion of borrow checking/lifetimes is supposed to be coming to Swift in the future?

Re: Rust in 2018: easier to use

#88

Post by sambe »

kbwt wrote: post #82
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

I wouldn't be so sure lower level code necessarily has more vulnerabilities. It's certainly easier to find the vulnerabilities because the attack vectors are well-known. Software written in higher level languages is often less widely deployed, so less people are trying to find vulnerabilities. All the complexity adds up, and can result in new vulnerabilities that wouldn't have been there if the code was written in a…

What complexity adds up?

Re: Rust in 2018: easier to use

#89

Post by currymj »

nafizh wrote: post #3

Anyone has suggestions on learning rust for a python programmer who is also not strong on systems concepts?

a big part of the early Rust community comes from Ruby, so Rust as an entry to systems programming is really common.

Mozilla's IRC server has a #rust-beginners channel that is like, overwhelmingly helpful. Go and ask stupid questions.

"The Rust Programming Language" is good:

https://doc.rust-lang.org/book/second-edition/

Knowing the difference between the stack and the heap, and having a picture of it in your head and understanding which variables go where, and what happens to the stack when calling and returning from functions, is pretty important. (Python wouldn't give you this intuition, although programming in something like Java might.)

I half-assed learned to code in C++ for scientific purposes. Later I got deeper into Rust, and it's made me a better, safer C++ programmer when I run into C++ code.

Re: Rust in 2018: easier to use

#90

Post by pjmlp »

continuational wrote: post #52
pjmlp wrote: post #44

Earlier quoted context omitted.

> value and reference types types (from c or c++) Applies to other languages as well.

Many languages handle this internally; essentially all functional languages and all dynamically typed languages.

And many others handle this externally, including some functional languages, in case you want a list, I can provide it.
Post reply on HN