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

Exploring Rust (from C#)

nblumhardt.com

Post reply on HN
Print view View original

51–60 of 132 posts

Re: Exploring Rust (from C#)

#51

Post by Cshelton »

pjmlp wrote: post #47
Manishearth wrote: post #37

Earlier quoted context omitted.

Note that it isn't 100% memory safe, it doesn't protect against iterator invalidation (which is a pretty common way in which memory unsafety springs up). But it can be close enough.

Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with firs…

Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but;

Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of tooling for cross platform, both mobile and desktop OS's. I believe Go also has some fairly popular mobile cross platform libraries as well that are probably much further along than Rusts'.

I can't say for Windows phone as I have never done anything for it and I think it's dead...

Re: Exploring Rust (from C#)

#52

Post by ToppestDawg »

blub wrote: post #39
Certhas wrote: post #29

Earlier quoted context omitted.

> The facts that Rust is quite young, has no shipping hero project as a case study and there are basically no jobs available are adding fuel to the fire. That's a bit of a misrepresentation though. Rust code is shipping in Firefox, and more importantly, Servo will have an alpha release in June. The close integration between Rust and Servo development, as well as the rigorous pre 1.0 process also set it apart from oth…

I want to see a large-scale system written in Rust or a security-critical piece of infrastructure where it's demonstrable that defects were reduced. Of course, no one is obliged to fulfill my wish, it's just a criteria that I use to evaluate the maturity of a tool and that I think is very reasonable.

DropBox has a 60k line project http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amaz...

Re: Exploring Rust (from C#)

#53

Post by ToppestDawg »

naasking wrote: post #45
blub wrote: post #22

Earlier quoted context omitted.

Technical reasons alone don't clarify what's happening. Everyone's explaining basically why "Rust is awesome", which is not what was asked. It's popular because Rust fans are heavily promoting it on HN as the solution to certain classes of programming errors. 2016 is probably going to be the year of Rust on HN, generally there's a new language every year such as Ruby, Javascript, etc. This year Go is a strong competi…

> The facts that Rust is quite young, has no shipping hero project as a case study Their Cargo package manager is written in Rust, and everyone seems to like it.

and compiler.

Re: Exploring Rust (from C#)

#54

Post by pjmlp »

Cshelton wrote: post #51
pjmlp wrote: post #47

Earlier quoted context omitted.

Still I have come to like it quite much. Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. At least when using it alone or in small teams that value safety. I have been using it in anger on my side projects for mobile s. Why use it in spite of my rants about safety? Tooling. Using C++ across Android and Windows Phone is already an extra layer of pain (thanks NDK) with firs…

Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of to…

> But I don't think it's any harder than c++

For the time being it surely is.

With C++ I just download XCode or NDK/Android Studio/Visual Studio.

I don't need to bother with FFI on iOS and Windows.

On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language.

The IDEs show visual representation of data structures when debugging and two way editing between C++ and the respective platform language.

With Rust or Go AFAIK I need to use Mac OS X or GNU/Linux for cross-compilation. Need to compile that toolchain myself and write my own wrappers to OS APIs.

Also not enjoying the same IDE experience isn't that much fun.

> I can't say for Windows phone as I have never done anything for it and I think it's dead...

Except the APIs are the same as Windows and XBox are moving to, even if WP10 is at the end of the road now with the last update misfortune.

So if Rust or Go want a place in Windows Store for desktop and XBox apps, they need to get along with WinRT APIs.

Yes, those languages will surely improve but if I have 1 hour to work on a side project, I rather spend that hour coding and not fixing toolchain issues.

If I had more time, I would surely like to help to improve the situation, but sadly time is limited.

Re: Exploring Rust (from C#)

#55

Post by Manishearth »

tomp wrote: post #40
Manishearth wrote: post #33

Earlier quoted context omitted.

> the use of "unsafe" features for the most basic tasks, such as implementing various collections. That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe. (Also, one can argue that implementing a collection is not a basic task. It's taught ver…

> This is not a con; this is the _point_ of unsafe. It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". > Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? I'm talking about the fact that the programmer has to write the code/algorithms in such a way that…

> It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety".

I explained in the other comment why this isn't really an issue. Note that most "basic datastructures" exist in the stdlib already, so you don't have to use unsafe code to do this in practice. 100% guaranteed memory safety by your definition is an unattainable goal. In safe rust code you do indeed have guaranteed memory safety, and you're able to extend this by writing unsafe rust code with which you supply your own guarantees of safety.

Safe Rust and unsafe Rust are best viewed as separate languages with smooth FFI between them, see http://doc.rust-lang.org/stable/nomicon/meet-safe-and-unsafe....

> splitting a vector and updating each element by a separate thread - IIRC that used to be a problem, maybe it has been fixed already?

This is scoped threads and is possible. Crossbeam and scoped_threadpool both have solutions for this.

> This also means implementing concurrent algorithms using the (limited) API

That's what you should be doing for thread safety. Like you mentioned, that's what you do in C too. Rust does indeed have CAS atomics.

> I have multiple threads, and I only care about the last result (i.e. they can all write to the same memory location)

This sounds like a use case for monotonic (relaxed) atomic ordering? Not sure.

Note that "the last result" itself doesn't mean anything, due to the way the cache works. There's no global clock (hooray for distributed systems!). The fact that Rust makes you think about this is a good thing. You can stick a Lamport clock in there, but that involves using more atomics and won't be as fast as relaxed ordering.

Re: Exploring Rust (from C#)

#56

Post by pjmlp »

johncolanduoni wrote: post #50
pjmlp wrote: post #25

Earlier quoted context omitted.

I have done my share of critics regarding Go team decisions, but one thing they got right is that Go is indeed a systems programming language. My understanding being that a systems programming language is one that can be used to bootstrap itself and build a full OS stack with the exception of some Assembly for interfacing with the underlying hardware. As of Go 1.6, the language certainly fulfils this description. If…

From the Clive design paper[1]: At this moment, the kernel used is a BSD kernel, but we are working now on making Go run on the bare hardware and on hypervisors. When that is done, the BSD kernels will be replaced with our own one. So if that is enough to be a systems programming language, then C# is also one on account of the Singularity OS[2]. [1]: http://lsub.org/export/clivesys.pdf [2]: https://en.wikipedia.org/w…

I can be made to be one, one still needs to remember Singularity and Midori aren't using pure C#, they have extended the language. Namely Sing# and System C# respectively.

Both projects influenced the design of native .NET on Windows Phone 8, followed by .NET Native, IILC and CoreRT.

Also many of the C# extensions on Midori are being explored for C# 7 and future versions.

C# when compiled to native code is not much different than using Modula-3, in terms of available features. It just needs a little more fine tuning in terms of features.

Re: Exploring Rust (from C#)

#57

Post by steveklabnik »

tomp wrote: post #40
Manishearth wrote: post #33

Earlier quoted context omitted.

> the use of "unsafe" features for the most basic tasks, such as implementing various collections. That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe. (Also, one can argue that implementing a collection is not a basic task. It's taught ver…

> This is not a con; this is the _point_ of unsafe. It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety". > Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? I'm talking about the fact that the programmer has to write the code/algorithms in such a way that…

  > an example would be
This has not been a problem for quite a while. You call split_at_mut to get two &mut T's back, and then pass them to each thread.

Re: Exploring Rust (from C#)

#58

Post by Tyr42 »

pjmlp wrote: post #54
Cshelton wrote: post #51

Earlier quoted context omitted.

Actually, I haven't done much with it, just messing around, so don't take this as absolute or anything but; Using Rust cross platform, across IOS and andriod, wasn't really that difficult to do...sure, the tooling isn't fully there yet. But I don't think it's any harder than c++, if anything, easier. Cargo is amazing and what makes Rust really nice to use. The community will create better IDE's and an ecosystem of to…

> But I don't think it's any harder than c++ For the time being it surely is. With C++ I just download XCode or NDK/Android Studio/Visual Studio. I don't need to bother with FFI on iOS and Windows. On Android I just need to bother with JNI FFI, not additionally how to call JNI from the respective language. The IDEs show visual representation of data structures when debugging and two way editing between C++ and the re…

I just got Rust compiling for a linux kernel module.

It wasn't too bad, though an inability to read C header files is kinda a pain. And for any target you are going to want to wrap things up in a "Rusty" api, as dealing with cstrings is kinda a pain.

Still, it'd be a pain to go from C strings to C++ strings, and hook new/delete up to kmalloc/kfree.

Re: Exploring Rust (from C#)

#59

Post by nyan4 »

gjm11 wrote: post #20
skoczymroczny wrote: post #8

Earlier quoted context omitted.

I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the backgro…

> Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the background. Nim is frustrating, because to my taste it gets so many things just right while getting one particular thing so spectacularly wrong that I can't bring myself even to try it. The one thing is its rule for when two identifiers are the same. They are compared case-insensitively, ignoring…

This criticism usually comes from people that do not use Nim. I was very surprised as well at first - now after 1 year of using Nim I realize I never run into any trouble because of case/underscore insensitivity.

#1: those variables have to be in the same scope or be procs working on the same types to be an issue.

#2: I don't use nimgrep, I just keep a consistent style across my files. When reading somebody else's code, case-insensitive search is usually enough.

Re: Exploring Rust (from C#)

#60

Post by vvanders »

pjmlp wrote: post #25
skoczymroczny wrote: post #8

Earlier quoted context omitted.

I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the backgro…

I have done my share of critics regarding Go team decisions, but one thing they got right is that Go is indeed a systems programming language. My understanding being that a systems programming language is one that can be used to bootstrap itself and build a full OS stack with the exception of some Assembly for interfacing with the underlying hardware. As of Go 1.6, the language certainly fulfils this description. If…

Last I checked Go doesn't have any memory placement semantics. That's a non-starter IMO for a systems programming language.

I like performance in my systems programming languages and you won't get that if you can't control where your memory lives.

Post reply on HN