5 ms·

I haven't touched C or C++ in over 10 years as I've been living like a free spirit in the Perl world. I've always wanted to go closer to the metal, but Perl did

I haven't touched C or C++ in over 10 years as I've been living like a free spirit in the Perl world. I've always wanted to go closer to the metal, but Perl did everything I ever wanted. But I slowly started to feel that dynamic languages had kind of boxed me in, almost making me timid of memory management and handling resource allocation. So I wanted to go deeper. I played with Go for a while, but kept an eye on Rust. However over the past couple of months, Rust just felt like they got it right. It made me care free about resources just like how Perl took care of everything, while being a strongly typed, static language with generics, and without the problems that might get in my way that Go has (GC and a heavy runtime). If you still haven't had a look but are interested, take a look at the Rust Guide: http://doc.rust-lang.org/guide.html http://doc.rust-lang.org/guide.html

geofft 12y ago
"Rust" was an interesting but slightly confusing language a year-ish ago, when it had chans and tasks and libuv and M:N threading and three kinds of pointers with their own funny symbol. That language, as far as I can tell, basically stopped existing (for lots of small good reasons that added up). Rust 1.0 will be an interesting head-on competitor to C/C++ without the awfulness of C/C++, which seems like a very different thing, and a thing I personally have more of a use case for. I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.
- mietek 12y ago
  > I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story Not really. Here’s an example of writing shared libraries for C in Haskell: https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example
  - nostrademons 12y ago
    The "called from C" case isn't the interesting one, even though it's what the grandparent mentioned. It's the "called from a scripting language" case. You can call Haskell or Ocaml or even Java code from within CPython or Matz Ruby. However, if you do this, you bring along an entirely different runtime system and memory layout. Usually this means that you face some very odd memory management bugs and lose any speed advantage you gain as soon as you have to marshal objects across the language boundary.
    - mietek 12y ago
      Interesting opinion. What are the applications?
      - steveklabnik 12y ago
        One of the first production deployments of Rust is such an application: https://www.skylight.io/ https://www.skylight.io/ Their Ruby gem is actually written in Rust.
      - geofft 12y ago
        Servo is doing some things to outsource GC to JavaScript, because the DOM (and therefore object lifetime tracking) needs to interact tightly with both JavaScript and native code: https://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
  - geofft 12y ago
    Cool! What are the limitations here? I'm quite a bit surprised you're able to make this work properly with pthreads... I somehow thought the GHC runtime will automatically multithread pure functions that can be evaluated in parallel. How much can you call back into C from a Haskell function and have things behave reasonably? I suppose there's actually a bit of advantage in that such a thing would need to return a type in the IO monad, but I'm super unfamiliar with the GHC runtime.
- sanderjd 12y ago
  This is a great comment, and very much in line with my experience. The tightening of Rust's focus over the last year has been really impressive, and I think it has become more of a great language for a few things than a good language for everything.
IgorPartola 12y ago
On living on free in Perl: I consider Perl, Python, and Ruby to be a part of the broad category of dynamicly typed, OO, interpreted languages. They are all different, but do have a very similar basic concept. In my experience, for writing scalable code there is nothing better than a Python/Perl/Ruby developer who can and does also write C. When the programmer can make a mental translation from their P/P/R to C, they have a much better chance of writing fast code that scales well. This IMO is a killer combination of skills: you write fast code because you know how to avoid expensive operations, and you write code fast because you don't have to declare every struct and accessor method as you would in C. Then again, there is fast and scalable code, and there is actually shipping. Just because the code is very well written, counting every implied malloc() and memset(), does not mean it's worth anything if it's just sitting on your harddrive. Write code in whatever you are good at, and ship.
- Cyther606 12y ago
  Sums up the appeal of Nim [1], which recently benchmarked favorably to C++ [2]. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive [1] https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers [2] https://www.reddit.com/r/programming/comments/2pvf68/armv7_vs_x8664_pathfinding_benchmark_of_c_d_go/cn0fkn1 https://www.reddit.com/r/programming/comments/2pvf68/armv7_v...
Sir_Substance 12y ago
I didn't find the rust guide helpful at all. I had a quick poke a few months ago, and found that a lot of the documentation was conflicting (one of the key resources everyone talked about was so out of date it was unusable) and unhelpful, because of the rate the language was evolving at. I'll get started with it about 6 months after version 1.0 is formally released, I think. Hopefully, the docs will have stabilised by then.
- steveklabnik 12y ago
  > I didn't find the rust guide helpful at all. Is this today, or months ago? Note that a few months ago I _completely re-wrote_ what was then the Tutorial, and it's now the Guide. If you have any specifics on the current version, I'd appreciate some GitHub issues :)

geofft 12y ago

"Rust" was an interesting but slightly confusing language a year-ish ago, when it had chans and tasks and libuv and M:N threading and three kinds of pointers with their own funny symbol. That language, as far as I can tell, basically stopped existing (for lots of small good reasons that added up). Rust 1.0 will be an interesting head-on competitor to C/C++ without the awfulness of C/C++, which seems like a very different thing, and a thing I personally have more of a use case for. I think, to some extent, this is why Rust keeps being compared with Go. Last year's "Rust" was definitely something that merited comparisons with goroutines and the like. Rust 1.0 is going out of its way to make sure that it can be used for writing dynamic libraries that can be called from C or any other language with an FFI, and is possibly easier than C++ for that use case. This is completely not doable in Go (I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story). Go seems to be a good language, but it's addressing a very different use case from what Rust is (now) addressing.

mietek 12y ago
> I suspect that this goal is fundamentally incompatible with having goroutines or a similar built-in concurrency story Not really. Here’s an example of writing shared libraries for C in Haskell: https://github.com/mietek/haskell-so-example https://github.com/mietek/haskell-so-example
- nostrademons 12y ago
  The "called from C" case isn't the interesting one, even though it's what the grandparent mentioned. It's the "called from a scripting language" case. You can call Haskell or Ocaml or even Java code from within CPython or Matz Ruby. However, if you do this, you bring along an entirely different runtime system and memory layout. Usually this means that you face some very odd memory management bugs and lose any speed advantage you gain as soon as you have to marshal objects across the language boundary.
  - mietek 12y ago
    Interesting opinion. What are the applications?
    - steveklabnik 12y ago
      One of the first production deployments of Rust is such an application: https://www.skylight.io/ https://www.skylight.io/ Their Ruby gem is actually written in Rust.
    - geofft 12y ago
      Servo is doing some things to outsource GC to JavaScript, because the DOM (and therefore object lifetime tracking) needs to interact tightly with both JavaScript and native code: https://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ https://blog.mozilla.org/research/2014/08/26/javascript-serv...
- geofft 12y ago
  Cool! What are the limitations here? I'm quite a bit surprised you're able to make this work properly with pthreads... I somehow thought the GHC runtime will automatically multithread pure functions that can be evaluated in parallel. How much can you call back into C from a Haskell function and have things behave reasonably? I suppose there's actually a bit of advantage in that such a thing would need to return a type in the IO monad, but I'm super unfamiliar with the GHC runtime.
sanderjd 12y ago
This is a great comment, and very much in line with my experience. The tightening of Rust's focus over the last year has been really impressive, and I think it has become more of a great language for a few things than a good language for everything.

IgorPartola 12y ago

On living on free in Perl: I consider Perl, Python, and Ruby to be a part of the broad category of dynamicly typed, OO, interpreted languages. They are all different, but do have a very similar basic concept. In my experience, for writing scalable code there is nothing better than a Python/Perl/Ruby developer who can and does also write C. When the programmer can make a mental translation from their P/P/R to C, they have a much better chance of writing fast code that scales well. This IMO is a killer combination of skills: you write fast code because you know how to avoid expensive operations, and you write code fast because you don't have to declare every struct and accessor method as you would in C. Then again, there is fast and scalable code, and there is actually shipping. Just because the code is very well written, counting every implied malloc() and memset(), does not mean it's worth anything if it's just sitting on your harddrive. Write code in whatever you are good at, and ship.

Cyther606 12y ago
Sums up the appeal of Nim [1], which recently benchmarked favorably to C++ [2]. import rdstdin, strutils let time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt) hours24 = time24[0] minutes24 = time24[1] flights: array[8, tuple[since: int, depart: string, arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."), (583, "9:43 a.m.", "11:52 a.m."), (679, "11:19 a.m.", "1:31 p.m."), (767, "12:47 p.m.", "3:00 p.m."), (840, "2:00 p.m.", "4:08 p.m."), (945, "3:45 p.m.", "5:55 p.m."), (1140, "7:00 p.m.", "9:20 p.m."), (1305, "9:45 p.m.", "11:58 p.m.")] proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int = hours * 60 + minutes proc cmpFlights(m = minutesSinceMidnight()): seq[int] = result = newSeq[int](flights.len) for i in 0 .. <flights.len: result[i] = abs(m - flights[i].since) proc getClosest(): int = for k,v in cmpFlights(): if v == cmpFlights().min: return k echo "Closest departure time is ", flights[getClosest()].depart, ", arriving at ", flights[getClosest()].arrive [1] https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers https://github.com/Araq/Nimrod/wiki/Nimrod-for-C-programmers [2] https://www.reddit.com/r/programming/comments/2pvf68/armv7_vs_x8664_pathfinding_benchmark_of_c_d_go/cn0fkn1 https://www.reddit.com/r/programming/comments/2pvf68/armv7_v...

Sir_Substance 12y ago

I didn't find the rust guide helpful at all. I had a quick poke a few months ago, and found that a lot of the documentation was conflicting (one of the key resources everyone talked about was so out of date it was unusable) and unhelpful, because of the rate the language was evolving at. I'll get started with it about 6 months after version 1.0 is formally released, I think. Hopefully, the docs will have stabilised by then.

steveklabnik 12y ago
> I didn't find the rust guide helpful at all. Is this today, or months ago? Note that a few months ago I _completely re-wrote_ what was then the Tutorial, and it's now the Guide. If you have any specifics on the current version, I'd appreciate some GitHub issues :)