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

81–90 of 132 posts

Re: Exploring Rust (from C#)

#81

Post by pcwalton »

pmelendez wrote: post #27
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…

> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes some people (like me) would argue that C++ (11&14) is actually that language. A subset of C++ is actually very perfomant and safe for most of the uses.

> And sometimes some people (like me) would argue that C++ (11&14) is actually that language.

The memory safety track records of large-scale software written in modern C++ disagree with you. I don't think this is a tenable argument.

C++11 and C++14 don't really add any memory safety features over C++03 plus user-defined reference counted smart pointers. In fact, I think there's a reasonable argument to be made that C++11 is less safe in practice than this use of C++03. If you use rvalue references and move semantics a lot (since "use-after-move" is now a very real problem), or if you use lambdas a lot (since it's so easy to make dangling upvar references).

Re: Exploring Rust (from C#)

#82

Post by kazagistar »

maxxxxx wrote: post #78

Does anybody know how good the Rust integration with Windows is? The language looks very good but can you interop with Win32, COM and .NET? Is there a debugger? Without those its usability is a little limited.

Haven't used any yet, but there are number of libraries.

Generated winapi bindings: https://retep998.github.io/doc/winapi/

A COM library, including a macro for generating a COM interface: http://eljay.github.io/com-rs/com_rs/index.html

Not exactly sure about .Net, but here is a tutorial for how to use a rust library from C#: http://www.loekvandenouweland.com/content/using-rust-code-fr...

Re: Exploring Rust (from C#)

#83

Post by pjmlp »

pcwalton wrote: post #80
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…

> Yes we cannot get rid of the C underpinnings, but there are enough features to write safe C++. No, there aren't. Empirically, modern C++ projects are not memory safe. Maybe when you qualify it with this: > At least when using it alone or in small teams that value safety. But I suspect the reason it looks that way is actually this: Projects that are developed alone or with small teams tend to be less important proje…

I fully agree with you, but my point is that until Rust achieves a certain parity with mobile OS C++ tooling the "good enough approach of C++14 and C++17" improvements will prevail, even among those that would rather use something else.

Given myself as example, in spite of all my rants about security that you well know, I still use C++ as my portable business code between mobile platforms.

However I always compile with all warnings as errors, fully embrace C++ STL types for safe programming and do regular static analysis, exactly to minimize as much as possible the errors that might still miss my attention.

If I would be focusing just in a single platform, then I would surely choose between Swift, Java and C# respectively.

Re: Exploring Rust (from C#)

#84

Post by kazagistar »

Manishearth wrote: post #49
tomp wrote: post #43

Earlier quoted context omitted.

Exactly. Just as I've written in my post: > Rust is still a huge improvement > Except that it's not guaranteed

You will never be able to get both 100% guaranteed memory safety and low level control/performance. Opposing it based on principle means that you'll never move on to anything better because a perfect solution doesn't exist. For what it's worth, you can write quite a lot in 100% safe code, such that you have to trust only the standard library. Which is the case for any programming language. So, the argument on the fro…

> You will never be able to get both 100% guaranteed memory safety and low level control/performance.

Sure you can. You just need a full fledged proof engine instead of "merely" a type system.

Re: Exploring Rust (from C#)

#85

Post by pjmlp »

lgunsch wrote: post #74
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…

You cannot use Go in kernel programming at all without a monumental amount of work. You'd need your own implementation of the language. Go originally did have a runtime that did not require systemcalls and could run on bare hardware, however, this was removed very early on as not being worth the effort.

Yes I do remember that runtime when I was still reading gonuts.

As always, a language and its implementations are not the same thing.

It is nothing special to have a bare runtime that would enable a Go application to be statically compiled and deployed into a Raspberry PI, for example.

It just needs someone to create such Go compiler.

Of course, such work would probably be a nice thesis project for OS design classes.

Re: Exploring Rust (from C#)

#86

Post by barsonme »

vvanders wrote: post #60
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…

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.

Theoretically they (or whomever writes an OS in Go) could extend the runtime to add something like `makestack(Type, size IntegerType) Type` to mimic alloca or add in a guarantee that `var b [100]byte` will be allocated on the stack.

(Right now I think it is, but I know there's a Go issue dealing with a function like this, and one of the comments was about potentially creating `a` on the heap and returning an invisible pointer instead of the actual 1e9 bytes.)

    func foo() (a [1e9]byte) { return a }

Re: Exploring Rust (from C#)

#87

Post by agentgt »

Hopefully this is relevant but one of the things I had difficulty with in Rust is closures (or more specifically the lifetime and pointers of closures) and wiring up a system or library that needs lots of callback things.

See I'm used to Java where anonymous classes are closures (I really like that about Java/Scala/Groovy. One of the very few things I don't like about C# is that does not have anonymous classes).

So the problem is when I want a callbacky thing that has state it gets fairly complicated in Rust because you have lots of options that have limitations. For example there is bare functions or raw functions which basically stateless, there is traits but you'll need to use boxes and or cells, and then there is Rust closures which I had some various issues with because of bugs (they are probably fixed now).

I only bring this up because instead of so many tutorials on simple static programming stuff I would like to see how one might wire up a system with many callback components (ie manual dependency injection). I suppose I should look at how its done in Iron.

ie if your going to show something analogous to a Java/C# developer show them some wiring up of a complicated system that has interfaces and the components can be interchanged (perhaps that is just something you don't do in Rust but I'm curious how it would be done).

Re: Exploring Rust (from C#)

#88

Post by Manishearth »

kazagistar wrote: post #84
Manishearth wrote: post #49

Earlier quoted context omitted.

You will never be able to get both 100% guaranteed memory safety and low level control/performance. Opposing it based on principle means that you'll never move on to anything better because a perfect solution doesn't exist. For what it's worth, you can write quite a lot in 100% safe code, such that you have to trust only the standard library. Which is the case for any programming language. So, the argument on the fro…

> You will never be able to get both 100% guaranteed memory safety and low level control/performance. Sure you can. You just need a full fledged proof engine instead of "merely" a type system.

Well, ok. I guess that's too heavyweight, though.

However, http://plv.mpi-sws.org/rustbelt/

Re: Exploring Rust (from C#)

#89

Post by pbz »

agentgt wrote: post #87

Hopefully this is relevant but one of the things I had difficulty with in Rust is closures (or more specifically the lifetime and pointers of closures) and wiring up a system or library that needs lots of callback things. See I'm used to Java where anonymous classes are closures (I really like that about Java/Scala/Groovy. One of the very few things I don't like about C# is that does not have anonymous classes). So t…

> One of the very few things I don't like about C# is that does not have anonymous classes

Anonymous classes are lambdas in C#.

http://programmers.stackexchange.com/questions/195081/is-a-l...

Re: Exploring Rust (from C#)

#90

Post by mreiland »

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…

I tried to get into nim, but then I started reading the source for some of their stdlib and finding bugs.

I pointed it out on the boards and the response wasn't all that great, so I decided to spend my time elsewhere.

I started picking up Rust a few weeks ago, so far I'm having fun :)

Post reply on HN