Live data from Hacker News

Exploring Rust (from C#)

nblumhardt.com

41–50 of 132 posts

Re: Exploring Rust (from C#)

#41
post #20

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…

Case-insensitivity I get, but deleting underscores? Yikes. I don't like Nim for other reasons, but that's a huge one.

Re: Exploring Rust (from C#)

#42
post #38

Earlier quoted context omitted.

> The facts that Rust is quite young, has no shipping hero project as a case study Dropbox using it sounds like a pretty good hero project...

Hard to say. I've seen posts by jamwt (I assume someone that's working on the said Rust project) which are more confusing than enlightening. In one they say that Dropbox is investing multiple millions in a key piece of infrastructure written in Rust. One month later they say that the project is written in go with some Rust and it will "stay that way". There was also a HN thread, maybe that contains more clues.

The fact that it was Go+Rust has never changed. Dropbox had a huge piece of infra being written in Go, they rewrote a core part of it in Rust and got massive savings from that. I presume a lot of that infra isn't bottlenecked by perf, so it doesn't make sense to rewrite it.

Re: Exploring Rust (from C#)

#43
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…

> 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. This is a vast oversimplification. It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an e…

Exactly. Just as I've written in my post:

> Rust is still a huge improvement

> Except that it's not guaranteed

Re: Exploring Rust (from C#)

#44
post #20

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…

When I was switching from Pascal (Delphi) to C#, I was wondering why would someone make something and Something two different things. But that what Nim does is definitely weird.

Re: Exploring Rust (from C#)

#45
post #22
post #3

Could someone explain why Rust is so damn popular/controversial?

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.

Re: Exploring Rust (from C#)

#46
post #38

Earlier quoted context omitted.

> The facts that Rust is quite young, has no shipping hero project as a case study Dropbox using it sounds like a pretty good hero project...

Hard to say. I've seen posts by jamwt (I assume someone that's working on the said Rust project) which are more confusing than enlightening. In one they say that Dropbox is investing multiple millions in a key piece of infrastructure written in Rust. One month later they say that the project is written in go with some Rust and it will "stay that way". There was also a HN thread, maybe that contains more clues.

> In one they say that Dropbox is investing multiple millions in a key piece of infrastructure written in Rust. One month later they say that the project is written in go with some Rust and it will "stay that way".

Their overall infrastructure is in Go and they're fine with that, they've (re)written specific components in Rust for memory savings (and CPU though less so), they have ~60kLOC of rust in production according to jamwt comments on reddit.

Re: Exploring Rust (from C#)

#47

Earlier quoted context omitted.

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

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 first class support from the platform owners.

Using Go, Swift, Rust would increase that pain level quite higher given the actual lack of comparable tooling.

Meaning build scripts, IDE, debugging tools, packaging and APIs.

C# doesn't suffer as much from it thanks to Xamarin, but I would only use it in commercial projects.

I really would wish that one of those languages would eventually be adopted across mobile OS SDKs as C and C++ currently are.

Already had a look at Rust for Windows Phone, but COM support is not yet there to the level expected by WinRT as C++/CX allows. Assuming I was looking at the right place.

Re: Exploring Rust (from C#)

#48
post #3

Could someone explain why Rust is so damn popular/controversial?

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.

I always thought Go is less suitable as C++ replacement due to its GC. Another candidate which could be a dark horse is Swift.

Re: Exploring Rust (from C#)

#49
post #43

Earlier quoted context omitted.

> 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. This is a vast oversimplification. It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an e…

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 front page is true. It does guarantee memory safety in safe Rust code, as much as possible. It gives you the tools to extend your abstractions with unsafe Rust code, which you need to supply your own guarantees with.

Re: Exploring Rust (from C#)

#50
post #25

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…

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/wiki/Singularity_(operating_system)

Post reply on HN