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

101–110 of 305 posts

Re: Rust in 2018: easier to use

#101

Post by red75prime »

jefftime wrote: post #42
karlding wrote: post #14

Out of curiosity, how is the embedded story (for both bare-metal and RTOS) in Rust nowadays? I took a look early last year, and I remember feeling that the ecosystem still wasn't as mature as I liked. There's svd2rust [0] and dslite2svd [1], which is basically "bindgen for hardware". Please do correct me if I'm wrong, but from what I understood [2], most SVD files leave out a lot of information so a lot of what svd2r…

I tried exploring no_std Rust recently, and found it to be quite frustrating. After just using a Result type I was getting errors of things like `eh_unwind_resume` being undefined. Toggling LTO rectified my problems but didn't give me much confidence in reliably using no_std

`-C panic=abort` compiler option should have fixed the problem. If you want to be able to intercept panics, you need to provide implementations for `eh_unwind_resume` and `eh_personality`.

Re: Rust in 2018: easier to use

#102

Post by ilammy »

tomsmeding wrote: post #96
bjz_ wrote: post #92

Earlier quoted context omitted.

> Kakoune uses a clippy ASCII art for its immediate help, it's nice. Had to look this up - very cute! https://github.com/mawww/kakoune#screenshots https://raw.githubusercontent.com/mawww/kakoune/master/doc/s...

Their choice of executable name is slightly unfortunate in Dutch, where 'kak' basically means 'shit'.

Eastern Slavic languages like Russian also give a similar vibe to this word ('shitter').

Re: Rust in 2018: easier to use

#103

Post by pjmlp »

sebcat wrote: post #85
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.

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

Even using C++ in embedded is an issue, mostly cultural.

A common theme in the C++ community is to advocate C++ to devs that only see Assembly and C89, and don't see any reason to move beyond that.

Most recent example "Embedded & C++ - Meeting 2017 Keynote"

https://www.youtube.com/watch?v=mNPfsUZb3vs

Re: Rust in 2018: easier to use

#104

Post by pjmlp »

K0nserv wrote: post #72
eecc wrote: post #50

Earlier quoted context omitted.

Where I live and work, golang is only used at one major client (because they’re US based, the decision must have happened elsewhere.) Everything else is Spring Boot (java), Akka (Scala) or Nodejs. Apparently nobody wants to embrace a language designed for offshoring, so no Meetups, noisy user groups and so on... even Clojure is more popular

Golang is a language designed for offshoring? It was invented at one of the largest engineering orgs to be used in house

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 adopt. – Rob Pike 1"

"It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. – Rob Pike 2"

So a language that makes it quite easy for enterprises to deal with developers as cogs.

Source:

http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...

https://talks.golang.org/2012/splash.article

Re: Rust in 2018: easier to use

#105

Post by elygre »

tomsmeding wrote: post #96
bjz_ wrote: post #92

Earlier quoted context omitted.

> Kakoune uses a clippy ASCII art for its immediate help, it's nice. Had to look this up - very cute! https://github.com/mawww/kakoune#screenshots https://raw.githubusercontent.com/mawww/kakoune/master/doc/s...

Their choice of executable name is slightly unfortunate in Dutch, where 'kak' basically means 'shit'.

I think “kak” would be better translated as “poo”. Parents will routinely talk to their kids about “kak”, similar to the way US parents will use the word “poo”. The word “shit” generally has a much stronger meaning (and is therefore often obscured, as “s..t” or something similar.

Re: Rust in 2018: easier to use

#106

Post by pjmlp »

currymj wrote: post #87
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?

Yes, the initial support is already there in Swift 4, it is called enforced exclusive access to memory in Apple documentation.

Re: Rust in 2018: easier to use

#107

Post by k__ »

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.

Isn't Rust perfect for severless?

Since cloud providers do all the plumbing, Rust would only have to deliver a tiny Linux binary for the function.

Re: Rust in 2018: easier to use

#108

Post by littlestymaar »

rapsey wrote: post #84
IshKebab wrote: post #78

Earlier quoted context omitted.

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.

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.

Re: Rust in 2018: easier to use

#109

Post by jefftime »

red75prime wrote: post #101
jefftime wrote: post #42

Earlier quoted context omitted.

I tried exploring no_std Rust recently, and found it to be quite frustrating. After just using a Result type I was getting errors of things like `eh_unwind_resume` being undefined. Toggling LTO rectified my problems but didn't give me much confidence in reliably using no_std

`-C panic=abort` compiler option should have fixed the problem. If you want to be able to intercept panics, you need to provide implementations for `eh_unwind_resume` and `eh_personality`.

Perhaps it's just an issue of me not being educated enough with this kind of low-level Rust. Setting panic to abort in the cargo config did indeed fix `eh_personality` being undefined, but `eh_unwind_resume` still seems finnicky. Building in release will work, but building in debug will still complain

Re: Rust in 2018: easier to use

#110

Post by amelius »

pjmlp wrote: post #91
vhakulinen wrote: post #51

Earlier quoted context omitted.

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

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.
Post reply on HN