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

2017 Rust Roadmap

github.com

Post reply on HN
Print view View original

101–110 of 201 posts

Re: 2017 Rust Roadmap

#101

Post by Cyph0n »

cm3 wrote: post #71
Cyph0n wrote: post #21

Earlier quoted context omitted.

Could you provide references for the claim that hardware support for GCs had been in CPUs for decades?

Burroughs line of machines and Intel iAPX 432 and it's derivative i960 (which is actually in use). The project for which the Intel CPU was designed together with Siemens would have given us a safer foundation due to using this processor in an Ada based operating system in the 1980s. But then UNIX won and gave us the hegemony of C and all the avoidable security bugs associated with it. Lisp machines had similar design…

Thanks. I will definitely look into these when I have the time. I'm actually a grad student in EE but this topic interests me. Maybe I can get something published on hardware accelerated GCs... one day!

Re: 2017 Rust Roadmap

#102

Post by cm3 »

Cyph0n wrote: post #101
cm3 wrote: post #71

Earlier quoted context omitted.

Burroughs line of machines and Intel iAPX 432 and it's derivative i960 (which is actually in use). The project for which the Intel CPU was designed together with Siemens would have given us a safer foundation due to using this processor in an Ada based operating system in the 1980s. But then UNIX won and gave us the hegemony of C and all the avoidable security bugs associated with it. Lisp machines had similar design…

Thanks. I will definitely look into these when I have the time. I'm actually a grad student in EE but this topic interests me. Maybe I can get something published on hardware accelerated GCs... one day!

Genuinely curious, do they not teach historic designs in EE course plans? To learn from and improve, but not reinvent something half-way or worse. Also, older designs are much easier to study completely compared to the super complex logic inside your current day x86.

Personally, I would call it hardware-assisted gc if we consider hardware acceleration to be things like GPUs, crypto accelerators, etc.

Re: 2017 Rust Roadmap

#103

Post by Cyph0n »

cm3 wrote: post #102
Cyph0n wrote: post #101

Earlier quoted context omitted.

Thanks. I will definitely look into these when I have the time. I'm actually a grad student in EE but this topic interests me. Maybe I can get something published on hardware accelerated GCs... one day!

Genuinely curious, do they not teach historic designs in EE course plans? To learn from and improve, but not reinvent something half-way or worse. Also, older designs are much easier to study completely compared to the super complex logic inside your current day x86. Personally, I would call it hardware-assisted gc if we consider hardware acceleration to be things like GPUs, crypto accelerators, etc.

An undergrad computer architecture course would typically gloss over the history of CPUs and focus either on MIPS or x86 (or both). For example, I did two courses on x86, starting from 8086 (and 8088), through Pentium, and some bits of Itanium.

You're right that starting with a simple architecture makes things much easier. 8086 for example operated in 16-bit real mode (segmented memory), and so the memory layout was trivial compared to 32-bit protected mode in x86.

I haven't taken any graduate architecture courses yet, but my assumption that they would go into more detail on the development of CPUs through history.

Re: 2017 Rust Roadmap

#104

Post by Manishearth »

jdf wrote: post #95
pcwalton wrote: post #62

Earlier quoted context omitted.

> It's also important to note that Go was designed for programmer productivity and Rust wasn't. Rust was absolutely designed for programmer productivity. Source: I was one of the designers. > GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. That's true, it is a productivity boost. But it also has a cost. Rust didn't want to pay that cost, especially when…

> The only thing I can think of that Rust has that Go doesn't is, like, SIMD, and I'm sure your comment wasn't just referring to SIMD. Just to clarify, are you referring to Rust using SIMD by way of LLVM, or by way of being able to use SIMD primitives / intrinsics directly in Rust code? The former works much better than I had anticipated. I've been surprised by the extent that my iterator code ends up vectorized with…

> The latter does not give me warm Rust feelings today. There's a SIMD crate, but it doesn't look maintained and only works with the nightly compiler releases. I didn't think there was any stable way to do inline assembly, so I think linking C is my best bet here?

Yeah, the person formerly working on simd is no longer able to contribute to random open source projects. It's still something the Rust team wants to make stable, just not right now. SIMD is a bit complicated because you need to address target support in a straightforward way.

Re: 2017 Rust Roadmap

#105

Post by tatterdemalion »

berntb wrote: post #100
tatterdemalion wrote: post #88

Earlier quoted context omitted.

> Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compil…

Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)

> (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)

Not my experience at all.

Re: 2017 Rust Roadmap

#106

Post by hellofunk »

joshmarlow wrote: post #13

I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust,…

I assume you mean OCaml's "utop" ?

Re: 2017 Rust Roadmap

#107

Post by fulafel »

yazaddaruvala wrote: post #26
pcwalton wrote: post #10

Earlier quoted context omitted.

It's important to note that Go and C have very different design goals from Rust. Go was never designed to have zero-cost abstractions (garbage collection being the most obvious outcome of this, but there are many others), and it has a runtime. C was never designed for safety and security, memory safety or otherwise. In short, Go sacrifices performance and C sacrifices safety, while Rust's goal is to sacrifice neither…

What are your thought on making `rustc` poly-lingual? Ideally, all libraries (i.e. should be written by experts) are written in Rust, but applications are allowed to be written in RustScript. RustScript would be optimized for lower learning curve. example[0]: - No `unsafe` allowed. - Everything is implicitly an `Arc `. - All numerics are BigNum. - etc. This is inspired by the popularity of using Rust within other lan…

There are a few Rust hosted dynamic languages already, see: https://github.com/ruse-lang/langs-in-rust

Dyon in particular sounds interesting for realtime apps as it uses a lifetime checker instead of GC.

Re: 2017 Rust Roadmap

#108

Post by shadowmint »

cmrx64 wrote: post #41
wyldfire wrote: post #19

Earlier quoted context omitted.

> any nontrivial project will make use of unsafe blocks. Sure! But that's okay. Just don't use 'quantity of unsafe blocks' as a metric of quality and you'll be all set. Think of it like so: don't use it until you have to and try not to have to. For me, that means consulting experts on IRC (etc), "How can I express this goal in idiomatic rust?" No different from learning C/C++ for the first time, IMO. And if no good w…

> > any nontrivial project will make use of unsafe blocks. I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.

Most projects use c bindings; it's not unfair to say that the quality of many of the c bindings on crates.io doesn't match the quality of stuff in the standard library.

(ie sure, maybe you're not writing unsafe yourself, but you'll quite possibly hit an issue where you have to dig into a crate that does)

Re: 2017 Rust Roadmap

#109

Post by pjmlp »

bluejekyll wrote: post #63
threeseed wrote: post #29

Earlier quoted context omitted.

Personally I think Rust should take this one step further. Actually build templates into the platform itself. For example one for creating a microservice complete with routes, test cases, JSON support etc. Another for a command line application. In languages with a steeper learning curve like Rust there needs to be more of an opinionated approach to teaching users.

I'm not sure how valuable this type of thing really is. Templates tend to fall out of date, since they're not actively used, they're not actively updated to new practices. I've seen this with lots of templates in other languages. The libraries having excellent documentation and pointing to apps that are similarly implemented tends to be better maintained, IMO.

Maybe this could be some kind of cargo command:

    cargo template-gen name something

Re: 2017 Rust Roadmap

#110

Post by pjmlp »

berntb wrote: post #75
leshow wrote: post #52

Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles.…

Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! Or are you saying that it is a pleasure to use, so you'll use it for smaller backends where development speed isn't that critical? (Asking, not flaming. :-) )

It is possible to have both capabilities in a programming la language.
Post reply on HN