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

Rust and Go

medium.com

Post reply on HN
Print view View original

41–50 of 311 posts

Re: Rust and Go

#41

Post by agwa »

freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

> Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas:

I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers.

Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.

Re: Rust and Go

#42

Post by TheHydroImpulse »

burntsushi wrote: post #13

> A good (trivial) example was a great command parsing library just doesn’t exist yet. There is a Docopt implementation in Rust[1], which is used by Cargo. It tracks master and is regularly updated. Interestingly, I've found people either love or hate Docopt, so maybe you knew about it but don't like it. :P /shameless plug [1] - https://github.com/docopt/docopt.rs

I've had a really good experience using that library in Rust. It just works without much code or hassle.

Re: Rust and Go

#43

Post by shin_lao »

freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

To met it's pretty clear that the language C++ programmers were waiting for is called C++ 14.

Re: Rust and Go

#44

Post by alkonaut »

jaekwon wrote: post #32
alkonaut wrote: post #25

Earlier quoted context omitted.

I'm thinking of the crowd that insists "map" is never more useful or readable than s straight for-loop. So not only don't they want it in go (which could be understandable in some situations), they genuinely seem to think it has no place in an imperative language. That blows my mind.

I've written in both paradigms and I mostly agree with the Go team. That it blows your mind blows mine, and I suppose it's good that we have these choices so we don't have to agree. Could you show me a code snippet of maps and filters used that you believe is more readable than for loops? Maybe I'll get a laugh out of that. :)

A for loop is a general tool. It can be used for anything. Because of that, it conveys little or no information. As a reader I have to read the loop in detail to see that what it does is perform a mapping, and not something slightly different (the last item could be skipped, etc etc).

The expressiveness of higher order functions comes not from terseness (only) but by expressing intent more clearly.

E.g this expresses (in pseudo) A conversion followed by a filter.

> odd_ints = strings.map(parseInt).select(odd)

This was expressed in the forum, but there was no agreement that this was readable, so I fully expect you to also think the for loop to be more readable. I suspect there is a divide between those who prefer reading how something is done rather than what is intended, in order to understand it.

Re: Rust and Go

#45

Post by humanrebar »

freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

  who is still using C/C++ in 2014, and why?
Systems programmers. Embedded programmers. Kernel developers. Compiler developers. Language runtime developers. Safety critical software developers. I guess you can group them under "performance benefits" but it's as much about the ability to drop down, write arbitrary bits to arbitrary addresses, and (re)implement low-level constructs as it is about performance.

The most obvious example of the need for a powerful language is manual memory management. For C and C++ developers, manual memory management isn't a drawback of their language but a feature.

If you want that sort of freedom to rebuild from the ground up, the only mainstream choices are C and C++. We'll see if Rust gets it right too.

All that being said, I think there's more room in the systems programming space. Both C and C++ tend to pick fast (or reverse-compatible) over correct when deciding which way to go on a feature. There are many, many applications that could really benefit from a "safety first" attitude towards systems programming. Browsers are the driving example but encryption libraries, medical systems, safety-critical software, and many other domains would benefit from a new perspective on things.

Re: Rust and Go

#46

Post by eridius »

Animats wrote: post #23

The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff th…

As a separate comment I want to address your final paragraph. Rust definitely provides a solution to buffer overflows. Specifically, all data structures that represent buffers of any sort always do bounds checking. This includes using the indexing operator (`foo[idx]`) on a fixed-length compile-time array. It's possible to skip the bounds check but you have to do so very intentionally, using an `unsafe {}` block (which defines a scope wherein certain features can be used that bypass some of Rust's safety). This should only ever be done in response to performance profiling when it turns out that bounds checking is a problem and when you can prove to yourself that it's safe to skip, and often there's another way to do the same thing that doesn't use `unsafe {}` (e.g. if you're iterating an array, use an iterator instead of indexing into the array each time; the iterator approach generally optimizes all the bounds checks away).

The basic rule is if you see a segfault or a data race, search your code for any `unsafe {}` blocks, and the cause will always be found inside one of those. And as a corollary, never use `unsafe {}` if you can possibly avoid it.

Re: Rust and Go

#47

Post by pjc50 »

freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

Never underestimate the legacy. I've resolved not to start another C++ project, but I'm learning MFC at the moment for working on a codebase that's 35 years old and was rewritten into C++ at some point in the 90s.

Re: Rust and Go

#48

Post by zem »

programminggeek wrote: post #9

Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great. I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big o…

the thing that has got me excited about learning go some day is that it's supposed to be really good at cross-compiling code into small, standalone binaries for the three major platforms (linux, windows, osx). haxe is another language on my radar for much the same write-once-deploy-all-over-the-place reason.

Re: Rust and Go

#49

Post by humanrebar »

shin_lao wrote: post #43
freyr wrote: post #31

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is…

To met it's pretty clear that the language C++ programmers were waiting for is called C++ 14.

As a C++ programmer, I'm waiting for C++ZZ where ZZ is the version that has a sane module system. Something like Cargo isn't even on the radar for C++ developers for a lot of reasons, but many of them can be traced back to textual inclusion.

Re: Rust and Go

#50

Post by TheHydroImpulse »

andolanra wrote: post #20
melling wrote: post #8

Earlier quoted context omitted.

I'm under the impression that Rust isn't near done and ready for production use. Go has been ready for a couple years. Rust could be 10 times better but I'm not going to touch it until they ship 1.0.

The plan is to release 1.0 around the end of the year. In that sense, Rust isn't done, but it is near done.

Unlike other languages that are "done" at 1.0, Rust will still be improving and iterating. 1.0 defines a backwards-compatible release that you can depend on but the language won't be "done".

"It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving. We will release new versions of Rust on a regular, frequent basis, and we hope that people will upgrade just as regularly. But for that to happen, those upgrades need to be painless." [0]

[0]: http://blog.rust-lang.org/2014/10/30/Stability.html

Post reply on HN