10 ms·

Screw it, we might as well use Go Seriously though, why not just use a rec keyword and then disallow any of the things that don't play nicely when you're in th

Screw it, we might as well use Go Seriously though, why not just use a rec keyword and then disallow any of the things that don't play nicely when you're in the recursive function? If you really wanted to be cool you could put those things right into the type system.

coldtea 14y ago
They don't want to be cool. They want to create a usable, pragmatic and fast language.
- Rickasaurus 14y ago
  Sounds mostly like a pile of empty words to me. Usable and pragmatic are purely contextual. Is rust faster than Haskell?
  - coldtea 14y ago
    >Sounds mostly like a pile of empty words to me. All words are empty until we put meaning on them. Go and read what they are trying to achieve and how, and then they won't be empty anymore. >Usable and pragmatic are purely contextual. Is rust faster than Haskell? It's not highly optimized yet, as it's in pre-alpha stage. But it's goal is to be faster than Haskell, and close to C/C++/ADA speed. Usable and pragmatic means that it should work for their goals, which are very real and tangible themselves: to use it as a compiled language to create a fast, parallel and secure web browser engine. They don't want to pile on academic concept and programming features or compiler tricks just to be "cool", "interesting", or "cutting edge". They don't even care if they would be "nice to have". They care about: what helps their goals, and what can be implemented without overcomplicating things. If Rust cannot become a language in which it's able to write a fast (faster than the currently available), parallel (more parallel than the currently available) and safe (safer than the currently available) browser engine, then it would have failed on its targets.
    - Rickasaurus 14y ago
      My point above about Go (but put somewhat trollishly I admit) was that if rust forsakes the things which make functional programming great, what about it is compelling? I was under the impression that it was supposed to be the functional systems programming alternative.
      - pnathan 14y ago
        Well, there are a couple compelling points about Rust: - deterministic memory management - actual generics. :P - an advanced type system (vs. java/c++) - design choices taken towards efficiency - default-immutable memory
      - steveklabnik 14y ago
        > I was under the impression that it was supposed to be the functional systems programming alternative. The elevator pitch is "Speed of C++, safety of ML, concurrency of Erlang."
        Rickasaurus 14y ago
        Wouldn't self/co-recursion be a safety of ML feature? Otherwise wouldn't you need mutation to do anything useful without worrying about your stack?
        steveklabnik 14y ago
        From a certain perspective, yes. You're confusing the tool with its purpose.
        Rickasaurus 14y ago
        What do you mean? Combinators are great (even if implemented imperatively) until you really care about performance and isn't that what this rust discussion is all about. Did you mean something other than combinators?
  - Offler 14y ago
    They eventually want to be competitive against C++ code and it seems they won't support TCO as that would harm their performance target.
    - pjmlp 14y ago
      The thing is that most C and C++ compilers actually do TCO when applying -O2 or similar, if they see the possibility to do so.
      - pcwalton 14y ago
        As I stated above, the C and C++ optimization is only sibling call optimization, which Rust does too.
        pjmlp 14y ago
        Ah ok, I missed that, thanks for pointing it out.
    - jacquesm 14y ago
      Not having TCO might lead to a much bigger problem than not hitting a performance target for large numbers of loop iterations. I'd rather have a program that is slightly slower and that works correctly for all input than one that has a built in - but invisible and hard to test for - hard limit.
      - qznc 14y ago
        I assume you mean that without TCO the stack might overflow for certain inputs and it is easy to miss those cases during testing. Is that actually a real problem? I never hear C/C++/Java/Python/Ruby/Javascript/D/Go/Clojure programmers complain about such bugs. On a Linux/Windows/OS X system the stacks are big enough to practically never hit such bugs. Whenever I get a stack overflow, I coded an infinite loop, which is actually easier to find without TCO, because the program is terminated.
- nnq 14y ago
  at what point did people start to use the word "pragmatic" for "opinionated"? (and I've heard it a lot lately...) I'm ok with opinionated technologies, but stop calling them "pragmatic": when the implementer of a language or technology makes a choice that restricts how its users can do some things, it makes an opinionated decision, that just happens to be pragmatic in the use-context he has thought of, but may not be pragmatic at all for the use-context that some technology user imagines, like a language feature that may be hard-to-impossible to implement but that when done properly (and it only has to be done once) would simplify the lives of a large group of programmers that just want to do things in a certain way.
  - coldtea 14y ago
    >at what point did people start to use the word "pragmatic" for "opinionated"? I don't think people are doing that. It's just that being pragmatic also makes you opinionated by necessity. Actually that would a very good definition: being pragmatic means you are "opinionated by necessity" (as opposed to opinionated by other concerns, e.g pureness, advancing the state of the art, etc). So being pragmatic is a subset of being opinionated, not a synonym. >when the implementer of a language or technology makes a choice that restricts how its users can do some things, it makes an opinionated decision, that just happens to be pragmatic in the use-context he has thought of, but may not be pragmatic at all for the use-context that some technology user imagines A language has thousands (millions) of users and every one can imagine whatever use-context. Not catering to all of them doesn't make you opinionated: merely pragmatic. Nobody has the time and the means to cater to all possible use-contexts. And we all know that adding too many things can ruin a language, over-complicate it and such. So that's another pragmatic concern. >like a language feature that may be hard-to-impossible to implement but that when done properly (and it only has to be done once) would simplify the lives of a large group of programmers that just want to do things in a certain way. Sounds like a very horrible feature to build into a language. Especially when you are starting out. If it's "hard-to-impossible to implement" then you are wasting tons of resources to something that might very well not pan out in the end. To reject this is not opinionated in the bad way. It's merely being pragmatic again, ie understanding that you have to prioritize things, and not go on a wild goose chase.
cpeterso 14y ago
Rust has/had a `be` keyword reserved for potentially implementing TCO.
ufo 14y ago
As they mentioned in the original post, a big problem is that TCO does not play nice with two other important features they want. 1. deterministic destructors that run at the end of functions (therefore making things that look like tail calls not actually tail calls) and 2. binary compatibility with C and C++ libraries and tools (they say that tail recursion doesn't let you usethe C calling conventions that these tools and libraries expect you to use) There is no point in allowing tail recursion in restricted contexts if you can't use these restricted functions to do the sort of stuff Rust was actually made to do
- ihnorton 14y ago
  > binary compatibility with C and C++ libraries and tools >(they say that tail recursion doesn't let you use the C > calling conventions that these tools and libraries expect > you to use) I've read variations of this comment about Rust C++ compatibility a few times, but haven't managed to find a source. Any references you could point me to?
  - kibwen 14y ago
    AFAIK there's no plan to support any sort of C++ interop natively in Rust. However, it should work just fine if your C++ code exposes a C-compatible interface. Servo has to be able to call into SpiderMonkey somehow.
    - kragen 14y ago
      GCC C++ ABIs are unstable enough that cross-platform C++ libraries usually export a C-compatible interface already.
      - ihnorton 14y ago
        g++ vs itself, or g++ vs msvc? g++ uses Itanium C++ ABI on at least linux/mac/mingw, and the mangling and vtable layouts seem to be the same (I'm very interested in any information to the contrary - though I realize vtables are only part of the story).

coldtea 14y ago

They don't want to be cool. They want to create a usable, pragmatic and fast language.

Rickasaurus 14y ago
Sounds mostly like a pile of empty words to me. Usable and pragmatic are purely contextual. Is rust faster than Haskell?
- coldtea 14y ago
  >Sounds mostly like a pile of empty words to me. All words are empty until we put meaning on them. Go and read what they are trying to achieve and how, and then they won't be empty anymore. >Usable and pragmatic are purely contextual. Is rust faster than Haskell? It's not highly optimized yet, as it's in pre-alpha stage. But it's goal is to be faster than Haskell, and close to C/C++/ADA speed. Usable and pragmatic means that it should work for their goals, which are very real and tangible themselves: to use it as a compiled language to create a fast, parallel and secure web browser engine. They don't want to pile on academic concept and programming features or compiler tricks just to be "cool", "interesting", or "cutting edge". They don't even care if they would be "nice to have". They care about: what helps their goals, and what can be implemented without overcomplicating things. If Rust cannot become a language in which it's able to write a fast (faster than the currently available), parallel (more parallel than the currently available) and safe (safer than the currently available) browser engine, then it would have failed on its targets.
  - Rickasaurus 14y ago
    My point above about Go (but put somewhat trollishly I admit) was that if rust forsakes the things which make functional programming great, what about it is compelling? I was under the impression that it was supposed to be the functional systems programming alternative.
    - pnathan 14y ago
      Well, there are a couple compelling points about Rust: - deterministic memory management - actual generics. :P - an advanced type system (vs. java/c++) - design choices taken towards efficiency - default-immutable memory
    - steveklabnik 14y ago
      > I was under the impression that it was supposed to be the functional systems programming alternative. The elevator pitch is "Speed of C++, safety of ML, concurrency of Erlang."
      - Rickasaurus 14y ago
        Wouldn't self/co-recursion be a safety of ML feature? Otherwise wouldn't you need mutation to do anything useful without worrying about your stack?
        steveklabnik 14y ago
        From a certain perspective, yes. You're confusing the tool with its purpose.
        Rickasaurus 14y ago
        What do you mean? Combinators are great (even if implemented imperatively) until you really care about performance and isn't that what this rust discussion is all about. Did you mean something other than combinators?
- Offler 14y ago
  They eventually want to be competitive against C++ code and it seems they won't support TCO as that would harm their performance target.
  - pjmlp 14y ago
    The thing is that most C and C++ compilers actually do TCO when applying -O2 or similar, if they see the possibility to do so.
    - pcwalton 14y ago
      As I stated above, the C and C++ optimization is only sibling call optimization, which Rust does too.
      - pjmlp 14y ago
        Ah ok, I missed that, thanks for pointing it out.
  - jacquesm 14y ago
    Not having TCO might lead to a much bigger problem than not hitting a performance target for large numbers of loop iterations. I'd rather have a program that is slightly slower and that works correctly for all input than one that has a built in - but invisible and hard to test for - hard limit.
    - qznc 14y ago
      I assume you mean that without TCO the stack might overflow for certain inputs and it is easy to miss those cases during testing. Is that actually a real problem? I never hear C/C++/Java/Python/Ruby/Javascript/D/Go/Clojure programmers complain about such bugs. On a Linux/Windows/OS X system the stacks are big enough to practically never hit such bugs. Whenever I get a stack overflow, I coded an infinite loop, which is actually easier to find without TCO, because the program is terminated.
nnq 14y ago
at what point did people start to use the word "pragmatic" for "opinionated"? (and I've heard it a lot lately...) I'm ok with opinionated technologies, but stop calling them "pragmatic": when the implementer of a language or technology makes a choice that restricts how its users can do some things, it makes an opinionated decision, that just happens to be pragmatic in the use-context he has thought of, but may not be pragmatic at all for the use-context that some technology user imagines, like a language feature that may be hard-to-impossible to implement but that when done properly (and it only has to be done once) would simplify the lives of a large group of programmers that just want to do things in a certain way.
- coldtea 14y ago
  >at what point did people start to use the word "pragmatic" for "opinionated"? I don't think people are doing that. It's just that being pragmatic also makes you opinionated by necessity. Actually that would a very good definition: being pragmatic means you are "opinionated by necessity" (as opposed to opinionated by other concerns, e.g pureness, advancing the state of the art, etc). So being pragmatic is a subset of being opinionated, not a synonym. >when the implementer of a language or technology makes a choice that restricts how its users can do some things, it makes an opinionated decision, that just happens to be pragmatic in the use-context he has thought of, but may not be pragmatic at all for the use-context that some technology user imagines A language has thousands (millions) of users and every one can imagine whatever use-context. Not catering to all of them doesn't make you opinionated: merely pragmatic. Nobody has the time and the means to cater to all possible use-contexts. And we all know that adding too many things can ruin a language, over-complicate it and such. So that's another pragmatic concern. >like a language feature that may be hard-to-impossible to implement but that when done properly (and it only has to be done once) would simplify the lives of a large group of programmers that just want to do things in a certain way. Sounds like a very horrible feature to build into a language. Especially when you are starting out. If it's "hard-to-impossible to implement" then you are wasting tons of resources to something that might very well not pan out in the end. To reject this is not opinionated in the bad way. It's merely being pragmatic again, ie understanding that you have to prioritize things, and not go on a wild goose chase.

cpeterso 14y ago

Rust has/had a `be` keyword reserved for potentially implementing TCO.

ufo 14y ago

As they mentioned in the original post, a big problem is that TCO does not play nice with two other important features they want. 1. deterministic destructors that run at the end of functions (therefore making things that look like tail calls not actually tail calls) and 2. binary compatibility with C and C++ libraries and tools (they say that tail recursion doesn't let you usethe C calling conventions that these tools and libraries expect you to use) There is no point in allowing tail recursion in restricted contexts if you can't use these restricted functions to do the sort of stuff Rust was actually made to do

ihnorton 14y ago
> binary compatibility with C and C++ libraries and tools >(they say that tail recursion doesn't let you use the C > calling conventions that these tools and libraries expect > you to use) I've read variations of this comment about Rust C++ compatibility a few times, but haven't managed to find a source. Any references you could point me to?
- kibwen 14y ago
  AFAIK there's no plan to support any sort of C++ interop natively in Rust. However, it should work just fine if your C++ code exposes a C-compatible interface. Servo has to be able to call into SpiderMonkey somehow.
  - kragen 14y ago
    GCC C++ ABIs are unstable enough that cross-platform C++ libraries usually export a C-compatible interface already.
    - ihnorton 14y ago
      g++ vs itself, or g++ vs msvc? g++ uses Itanium C++ ABI on at least linux/mac/mingw, and the mangling and vtable layouts seem to be the same (I'm very interested in any information to the contrary - though I realize vtables are only part of the story).