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

91–100 of 132 posts

Re: Exploring Rust (from C#)

#91

Post by vorg »

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…

> anonymous classes are closures (I really like that about Java/Scala/Groovy

Apache Groovy has diverged from Java since Java 8 came out, and there's also other JVM languages such as Kotlin. You only gave JVM languages as examples of the good, and all your examples of the bad were those on other platforms.

Re: Exploring Rust (from C#)

#92

Post by j1f4 »

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…

"Systems programming language" seems to be one a frequent definition miscommunication, right alongside "a Lisp" and "self taugt programmer".

People use the phrases without acknowledging or without realizing that there is a great breadth (and sometimes controversy) in what people take them to mean. I think you're doing it right defining it where you use it.

Re: Exploring Rust (from C#)

#93

Post by scott_s »

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.

Since tomp objects to trusting code, then I agree with Manishearth: if you're never willing to trust code, then you can never have guarantees. Even the proof engine is trusted code.

Re: Exploring Rust (from C#)

#94

Post by pcwalton »

barsonme wrote: post #86
vvanders wrote: post #60

Earlier quoted context omitted.

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

There's a lot more than that that you have to do. You can't even implement defer without allocation, just to name one example.

Re: Exploring Rust (from C#)

#95

Post by elcritch »

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.

This. There's no reason the smaller bits of `unsafe` code couldn't be verified with a proof system (ala COQ). Very few systems can be completely `true` in a mathematical sense, including math itself. IMHO, this is a self-defeating argument. E.g. a form of: "math isn't provable so math sucks!".

In the long run, this viewpoint would prevent moving to a system with 5% unsafe/95% safe which could be much more readily proofed using COQ since only a handful of unsafe code needs to be analyzed – I'm assuming proofing code has exponential complexity growth. So basically give Rust 10 years and I bet someone could build a verified stdlib & compiler for Rust!

Re: Exploring Rust (from C#)

#96

Post by agentgt »

vorg wrote: post #91
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…

> anonymous classes are closures (I really like that about Java/Scala/Groovy Apache Groovy has diverged from Java since Java 8 came out, and there's also other JVM languages such as Kotlin. You only gave JVM languages as examples of the good, and all your examples of the bad were those on other platforms.

Groovy still has anonymous classes. And yes there are other languages that have anonymous classes I just didn't feel like enumerating them especially the OP article was about C#.

Let me just say this so there isn't any assumption that I was bashing C#... C# is a far far better language than Java with the only exception for me being it doesn't have anonymous classes.

Re: Exploring Rust (from C#)

#97

Post by agentgt »

pbz wrote: post #89
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...

Not all anonymous classes are lambdas.

There are many situations like async streams or even synchronous iterators that require multiple methods.

Erik Meijer even mentions somewhere in this video that he is remiss that C# doesn't have anonymous classes: https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Ke...

Around 47:50 he says "feature request for C# anonymous inner classes".

Re: Exploring Rust (from C#)

#98

Post by vfclists »

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…

Really, the view of a number of bloggers who have used Nim consider it the best among the new crop of languages around for whatever reason, variable naming not withstanding.

Your comment is the only one I have seen making such a big issue about the variable naming.

Re: Exploring Rust (from C#)

#99

Post by tomp »

scott_s wrote: post #93
kazagistar wrote: post #84

Earlier quoted context omitted.

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

Since tomp objects to trusting code, then I agree with Manishearth: if you're never willing to trust code, then you can never have guarantees. Even the proof engine is trusted code.

Well, you have to trust something... Silicone manufacturer, CPU designer, the OS, the compiler...

But the big difference is, if I can do proofs and the compiler breaks my trust, that's a bug in the compiler. On the orher hand, Rust disallows complex proofs entirely, so I have to use unsafe code and trust random humans!

Re: Exploring Rust (from C#)

#100

Post by tomp »

Rusky wrote: post #66
tomp wrote: post #35

Earlier quoted context omitted.

> The argument has always been that it reduces the amount of code you have to check for safety manually. No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety". Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. I a…

Even if the language pulled some magic trick where it could verify collection implementations without unsafe, all you'd have done is move the unsafety into the type checker and compiler backend. The only difference is that Rust 1) moved some of that into the stdlib and 2) lets third parties extend it to provide more guarantees. Given this, I think you're drawing a rather arbitrary line- Rust (the compiler + stdlib, o…

It does guarantee memory safety... until you need to write your own collection. Then it explicitly endorses unsafe code (as opposed to offering a more powerful proof engine). I'm find with trusting something (compiler, proof engine, stdlib), but the issue is that safe Rust is barely a complete language!
Post reply on HN