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

Rust vs C Pitfalls

garin.io

Post reply on HN
Print view View original

131–140 of 379 posts

Re: Rust vs C Pitfalls

#131

Post by Manishearth »

mmstick wrote: post #55
gravypod wrote: post #28

Earlier quoted context omitted.

Like you I need something like NumPy and SciPy for my work. I'd also like an IDE. An IDE goes a long way to helping me feel comfortable to use a language.

Rust's had great IDE support for more than a year now. - There's Atom with Tokamak, which you must also install racer and clippy via cargo to get rapid in-line linting. - Then there's Visual Studio Code with RustyCode which you can also integrate with racer and clippy, that provides faster code completion and hovering over items will show a tooltip that documents that items. - Some people like IntelliJ Rust, but I've…

I don't really consider this to be "great IDE support", I consider this to be a start at IDE support. I love Rust, and I'm productive even without racer or YCM -- but I think there's a large gap between what Rust has and what many IDEs get you.

Most Java/C# IDEs will get you:

- Type-based autocomplete (racer/YCM/etc have this for Rust)

- Jump-to-definition / documentation (YCM/etc has this)

- Autoimport

- Non-grep-based refactoring

- Auto-boilerplating: for example, type `impl Trait for MyType` and have it tab-complete to a skeleton trait impl

- Some error integration (not just fileline jump-to), with tooltips and stuff asking you how you want the IDE to auto-fix the error

- A bunch of other smaller useful things which I can't remember at the moment

Now, autocomplete is a major chunk of this, but nowhere near being all of it.

The way I see it there are two camps on this issue. There's the "text editor" camp who use vim/emacs/sublime and when they are asking for IDE support they just mean autocomplete and jump-to that works from their editor. Then there's the camp coming from Eclipse or VS who want the whole deal.

The Rust Language Server project (https://github.com/jonathandturner/rls) is working on exposing this info from the compiler in a structured form so that IDEs and "text editor"s alike can get IDE features.

Re: Rust vs C Pitfalls

#132

Post by lobster_johnson »

voidlogic wrote: post #3
gravypod wrote: post #2

If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Ev…

On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS). Basically, Go is good for 90% of what I used to use Java for and 80% of wha…

As someone who writes Go full time, once I'm done with my current big Go project I will be taking a break to investigate alternatives. Both Rust and Swift are at the top of my list.

Go is good, even great, at many things. But it's a language largely defined by its limitations, usually intentionally. It's an engineering language, not made for big abstractions. For me, the largest frustration is that the language gets in the way, and the pain increases with the scale of the problem. Which is to say: I think Go scales to large projects just fine, but there are problems where you'd like to build big building blocks on top of smaller blocks on top of smaller blocks, and Go doesn't lend itself to certain kinds of big, composable, data-oriented abstractions. It's small building blocks all the way.

I've bumped into several very real problems recently where Go's coarse, not-very-data-oriented imperative approach has revealed itself as a liability, and where I found myself fantasizing how I could have done it in just a few elegant lines in Haskell. Sometimes they're about expressing things simply in a composable manner, and sometimes these problems simply manifest themselves in immense blobs of boilerplate/repetition (for example, because you have to implement the same method a few dozen times on different data structures, which in a different language could be solved with a generic implementation), where Go's solution is to either eschew type safety, use slow reflection APIs, or programmatically generate the Go code as part of the build process.

Go's is also frustrating in its selective pragmatism. Where Go has chosen to automate and sugarcoat some complicated things (memory management, goroutines), it's stubbornly unpragmatic about other things (error handling, working with polymorphic data, memory safety). Go has been ridiculed for its simplistic error system, but I'm not an extremist here; I'm all for errors being values, and not a fan of exceptions. But if you look at actual Go code, a huge amount of code has to interact with errors. When nearly every function is riddled with "if err != nil", you should know that your language is crying out for just a little syntactic sugar. Or a solid type-system solution for that matter. Enums (Rust-style) and pattern matching wouldn't go against Go's grain at all, but since Go is "done", we're stuck with how it is.

I think Go's focus on simplicity is very important (I'm a big fan of the Wirth school of languages), and my worry about Rust and Swift is that they never learned this lesson. To me, both Rust and Swift looked more promising early in the design process than in their current state; Swift looks increasingly like Scala every time I visit it, whereas Rust often feels lost in a sea of punctuation. That said, my annoyance with Go is acute enough that I'm willing to deal with a few downsides if I can get a language that better matches the kinds of projects that I build.

Re: Rust vs C Pitfalls

#133

Post by TheDong »

shanemhansen wrote: post #103
pornel wrote: post #88

Earlier quoted context omitted.

I write libraries. In Go I can only write libraries for Go programs. In Rust I can write libraries for any program. i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.

> In Go I can only write libraries for Go programs. That's not true. It's quite simple to create a loadable shared object in go and call it using anything with a c ffi.

It's not quite simple because of the GC go brings.

As proof, notice that it barely happens, and only as an oddity in Go, yet in rust there are actual uses (e.g. ruby and python library optimization)

Re: Rust vs C Pitfalls

#134

Post by lobster_johnson »

shanemhansen wrote: post #103
pornel wrote: post #88

Earlier quoted context omitted.

I write libraries. In Go I can only write libraries for Go programs. In Rust I can write libraries for any program. i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.

> In Go I can only write libraries for Go programs. That's not true. It's quite simple to create a loadable shared object in go and call it using anything with a c ffi.

Calling C from Go has significant overhead [1], doesn't that mean calling Go from C is equally slow?

[1] https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...

Re: Rust vs C Pitfalls

#135

Post by Manishearth »

lobster_johnson wrote: post #132
voidlogic wrote: post #3

Earlier quoted context omitted.

On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS). Basically, Go is good for 90% of what I used to use Java for and 80% of wha…

As someone who writes Go full time, once I'm done with my current big Go project I will be taking a break to investigate alternatives. Both Rust and Swift are at the top of my list. Go is good, even great, at many things. But it's a language largely defined by its limitations, usually intentionally. It's an engineering language, not made for big abstractions. For me, the largest frustration is that the language gets…

> my worry about Rust and Swift is that they never learned this lesson

FWIW the Rust team does consider simplicity to be important. However, it's not the only goal, which means that sometimes it has to be sacrificed to be able to make something possible. But most new language features do get discussed in the context of a "complexity budget".

So Rust tries pretty hard to ensure it doesn't get more complex than it has to; but it doesn't put simplicity as the overriding goal and hang all else to get it.

> Enums and pattern matching wouldn't go against Go's grain at all

I've said this many times before -- I don't miss generics from Go; I understand why they're not in the language. I miss ADTs and pattern matching.

Re: Rust vs C Pitfalls

#136

Post by kasey_junk »

tptacek wrote: post #99
empath75 wrote: post #36

Earlier quoted context omitted.

It's very rare that any programmer switches computer languages. You're probably going to retire as a c programmer. What are they going to teach in school? What are new systems programmers going to start with? I suspect it'll be rust and go, not c.

Not even a little bit true.

I don't know scheme & I have this thing...

It crosses boundaries.

Re: Rust vs C Pitfalls

#137

Post by euyyn »

atombender wrote: post #116
plandis wrote: post #43

Earlier quoted context omitted.

For me this is pretty easy. It's about leadership. The leaders of Go foster an attitude of exclusiveness (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups). The leaders of Rust are very receptive and helpful to new people. They are on IRC / Reddit and many other channels. I'd much rather invest my time into a truly open language and to me, that…

> just like a month ago they wanted to get rid of the Go subreddit To be fair, this was a proposal by a single person on the Go mailing list, and it was in reaction to Reddit's CEO publicly admitting to editing other users' comments. The person who proposed closing the Go subreddit was also under the mistaken impression that the subreddit was hosted by the Go team, which wasn't the case. In the end, there was a lot o…

What's a good example of it?

Re: Rust vs C Pitfalls

#138

Post by andreimuntean »

burntsushi wrote: post #109
lossolo wrote: post #87

Earlier quoted context omitted.

> If you show me a naive line by line approah, I'll show you an approach that is much faster but more complex. Of course, I did it myself many times. But this is NOT the point, I've already wrote it. The point is that I wrote naive approach in both languages and it's a lot faster in Go. Which is a reply to what OP wrote (don't forget where this discussion started). In this case this is the fact and I don't see any re…

> The point is that I wrote naive approach in both languages and it's a lot faster in Go. I tried your challenge, and the first data point I uncovered contradicts this. Here is the source code of both programs: https://gist.github.com/anonymous/f01fc324ba8cccd690551caa43... --- The Rust program doesn't use unsafe, doesn't explicitly use C code, is shorter than the Go program, faster in terms of CPU time and uses less…

Amazing! Thank you for your comment.

Re: Rust vs C Pitfalls

#139

Post by gens »

Since this is a "vs" can i assume that rust is better in all regards to C ? As in that rust is flawless ? Or should it be "Rust vs C's Pitfalls" ?

Re: Rust vs C Pitfalls

#140

Post by lobster_johnson »

mmstick wrote: post #55
gravypod wrote: post #28

Earlier quoted context omitted.

Like you I need something like NumPy and SciPy for my work. I'd also like an IDE. An IDE goes a long way to helping me feel comfortable to use a language.

Rust's had great IDE support for more than a year now. - There's Atom with Tokamak, which you must also install racer and clippy via cargo to get rapid in-line linting. - Then there's Visual Studio Code with RustyCode which you can also integrate with racer and clippy, that provides faster code completion and hovering over items will show a tooltip that documents that items. - Some people like IntelliJ Rust, but I've…

Does Rust have anything like "gorename" and "goimports"?
Post reply on HN