Like Tree31Likes

Let's talk about Rust!

This is a discussion on Let's talk about Rust! within the General Discussions forums, part of the Community Boards category; Originally Posted by Neo1 This is absolutely toxic, and frankly i no longer see any reason to remain an active ...

  1. #121
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by Neo1 View Post
    This is absolutely toxic, and frankly i no longer see any reason to remain an active member here. Bye.
    I think you are overreacting. I do not believe you are fault or in error. You brought up a topic you wanted to discuss, discussed what you wanted to do. Who cares where the topic heads? If you don't like something, ignore it! You don't need to respond. Pick what interests you and focus on that.
    This topic was fun. I do not see it as damning. Btw, I am not included in the group who are "against" you.
    Last edited by Elysia; 06-19-2014 at 12:57 PM.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #122
    Registered User
    Join Date
    Oct 2006
    Posts
    2,407
    I'm surprised that nobody brought up Ada (equally surprised that I didn't think of it). Doesn't Ada already do the things that Rust is claiming to do (compiler-enforced safety, standard abi, C interop), and more? Ada has been around longer than C++, has evolved more-or-less in parallel with C++, with a roughly equivalent feature set, had the full force of the US DoD behind it in its early years, and still only sees limited, niche use (#32 on the TIOBE index, as of 2014). I think it's safe to expect an even lower adoption rate for Rust.
    stahta01 likes this.
    Code:
    namespace life
    {
        const bool change = true;
    }

  3. #123
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,700
    If you don't like something, ignore it! You don't need to respond.
    I guess he doesn't like C Board, and is ignoring it.
    There's no crying at CBoard!

  4. #124
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,465
    Quote Originally Posted by Neo1 View Post
    The reason there is no worthwhile content is because this place has become a reverberation chamber for those arguing the established 'truths' of the business. This is absolutely toxic, and frankly i no longer see any reason to remain an active member here. Bye.
    The only establishment in know of in this industry is that someone always ends up throwing up their arms when discussing what language is better. Which is essentially what you did here, despite your best attempt at painting yourself as a victim; you tried to indoctrinate that one language is better than the other and threw up your arms when, surprise, no one agreed.

    Best of luck in whatever new programming discussion group you end up.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #125
    Registered User
    Join Date
    Jun 2005
    Posts
    6,292
    Quote Originally Posted by Elkvis View Post
    I'm surprised that nobody brought up Ada (equally surprised that I didn't think of it). Doesn't Ada already do the things that Rust is claiming to do (compiler-enforced safety, standard abi, C interop), and more? Ada has been around longer than C++, has evolved more-or-less in parallel with C++, with a roughly equivalent feature set, had the full force of the US DoD behind it in its early years, and still only sees limited, niche use (#32 on the TIOBE index, as of 2014).
    Well, yes Ada supports a number of the things promised by Rust.

    Where Ada (arguably) fell down is that it was a huge specification so rarely taught at educational institutions, a large learning curve, and few obvious means of learning it gradually so programmers tended to gravitate to something else. The US DoD tried to mandate its usage by making it mandatory in contracts, and then ran into resistance from suppliers because development of compiler and run time was expensive, getting validated implementations more so, they had to swallow the investment of time needed for developers to learn it since they couldn't readily recruit people who were expert in it, and the US contracting model places a large emphasis on affordability (i.e. minimising billed cost).

    Quote Originally Posted by Elkvis View Post
    I think it's safe to expect an even lower adoption rate for Rust.
    Those things are hard to predict. Rust does have an advantage of a community of people who are interested in using it, rather than having to be forced by an employer to use it.

    We've also had one person here mention that the attraction of Rust is its relatively small size (a characteristic that would be hard to associate with Ada - even some of the standardised subsets are huge by various measures). Given the change between versions of Rust, I would suggest - assuming it remains popular - that it will grow.

    Pragmatically, the growth of popularity of any programming language relies on people being able to achieve useful things with it, and being able to see potential of doing MORE useful things with that language. Where the notion of "useful" is an individual thing, that depends on a person's preferences, the work they do, the work they want to do, and things like that. When people successfully do useful (to them) things, and see the scope to do much more, they'll invest the effort to learn. That learning involves a significant investment of time and effort, both to learn good techniques and (often more important) to learn what to avoid.

    Proselytising doesn't work, as anyone who has invested effort to learn a language has encountered its strengths and weaknesses - and accepted them. And has also probably been subjected to zealots claiming they've made the wrong choice - usually for the "better" choice to either not last, or to turn out to be suitable for a very different style of development. Telling people what to do without an honest attempt to understand what they're really about is not the way to win them over.

    Which is why a pitch for a new language, if made to a community of people with experience in another language, needs to openly discuss benefits and trade-offs with practical use cases. Without proselytising. People will then decide to look further, or not, depending on their individual interests.
    Right 98% of the time, and don't care about the other 3%.

  6. #126
    Registered User
    Join Date
    Jun 2014
    Posts
    13
    I wouldn't call Rust a small language. First of all, it has a lot of syntax like for, if, etc. in Smalltalk this is implemented with method calls and then inlined by the JIT (hopefully). Then you have pattern matching syntax, macros, and a complex type system that involves lifetimes and borrowed pointers. Then you have interactions between these features like the borrow checker doesn't know that the pattern matching on a slice borrow the rest of the array, so you get an error because it tries to move the value instead of making a reference to it because it's a value type. Then you just throw stars and refs at it until it compiles and you have no idea why it even works.

    When I think of a small language I think of a language like Lisp. Rust's philosophy is basically focusing on being the best low-level language possible.

  7. #127
    Registered User
    Join Date
    Jun 2005
    Posts
    6,292
    Quote Originally Posted by iopq View Post
    I wouldn't call Rust a small language.
    I don't claim to be an expert in Rust, but from my reading about it I wouldn't suggest it is small either.

    Quote Originally Posted by iopq View Post
    First of all, it has a lot of syntax like for, if, etc. in Smalltalk this is implemented with method calls and then inlined by the JIT (hopefully).
    To say the least, that (e.g. implementing an if as a special case of method dispatch, rather than as a separate language feature) was a rather unusual decision by the Smalltalk designers.

    Am I right in interpreting your point as being that Rust supports various abstractions using language features (i.e. there isn't an aim to slavishly minimise the size of the core language, and relegate everything else to the library)?

    How important is that sort of distinction in a discussion of utility of Rust though? Does it affect people implementing libraries for use by other Rust developers, the people writing the Rust compiler or library, or does it affect someone using Rust as a tool to do something else? Those sorts of questions are relevant to any languages - I'm just trying to get an idea of where Rust sits.

    Quote Originally Posted by iopq View Post
    Then you have pattern matching syntax, macros, and a complex type system that involves lifetimes and borrowed pointers. Then you have interactions between these features like the borrow checker doesn't know that the pattern matching on a slice borrow the rest of the array, so you get an error because it tries to move the value instead of making a reference to it because it's a value type.
    I assume that is more a reflection of maturity of the borrow checker (it's design, implementation, etc) than a flaw of what it is about (which I understand to be detecting invalidated iterators at compile time if possible).

    Quote Originally Posted by iopq View Post
    Then you just throw stars and refs at it until it compiles and you have no idea why it even works.
    From an assurance and safety perspective - that notion really makes me shiver. If a developer can't explain why their code works, let alone the conditions in which it works, it's really hard to convince someone else that it does.

    A similar phenomenon affects C and C++ developers (and makes me shiver just as much) when people play with multiple levels of indirection, and start throwing asterisks and ampersands around.

    Quote Originally Posted by iopq View Post
    When I think of a small language I think of a language like Lisp.
    Sorry, my cat just choked on a furball. A small one

    Quote Originally Posted by iopq View Post
    Rust's philosophy is basically focusing on being the best low-level language possible.
    Yeah, but what does that really mean? I'm not being flippant in that, but to be "best" at anything, it's necessary to articulate a set of measurable criteria that provide evidence for or against such a conclusion, and provide a level playing field for comparing alternatives. For that matter, what do you mean by "low-level"? People interpret that notion differently.

    Those aren't really fair questions though. Different people will have different notions of "best" and "low-level", which are influenced by (as distinct from being driven by) programming language of choice.

    Practically, I don't tend to worry about whether a language I'm using is high level, low level, best, or anything else. In software development I start from the perspective of trying to achieve something, and choose techniques (design approaches, requirements capture, etc) and tools that are appropriate to do the job, and to provide evidence I've met requirements. Choice of language (or languages), IDEs, toolchains, etc is just one of many choices - and is rarely black-and-white.
    Right 98% of the time, and don't care about the other 3%.

  8. #128
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,067
    Assembly best low level language!!!!

  9. #129
    Registered User
    Join Date
    Jun 2014
    Posts
    13
    Well, yes, it's the maturity of the borrow checker. But the borrow checker has to be mature because of the interaction of all the features in the language like borrowed slices and so forth.

    By "best low-level language" I mean it emphasizes interop with C, low cost abstractions, "pay for what you use", having a familiar syntax for C/C++ programmers, not having a mandatory GC, having hygienic macros
    at the same time it the requirements say it has to be memory safe and be good for concurrency

    this comes at the cost of abstractions, Smalltalk treats everything as an object (which has performance implications since it doesn't inline objects as structs in memory but has a lot of indirection instead) and in Lisp everything is a list (which I guess could theoretically still have good performance and low cost abstractions, but it wouldn't be familiar to C programmers)

    So the tradeoffs that are being made specifically target what C/C++ is normally used for

    Quote Originally Posted by MutantJohn View Post
    Assembly best low level language!!!!
    which assembly? Technically, you can have an assembly language that is C++ (that's what the Belt architecture uses)

  10. #130
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,627
    Quote Originally Posted by iopq View Post
    that's what the Belt architecture uses
    There is no such arch, perhaps you meant Mill.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  11. #131
    Registered User MutantJohn's Avatar
    Join Date
    Feb 2013
    Posts
    1,067
    x86 best architecture!!!!

    Well, it's the one I use. And what I use is the best, obviously.

  12. #132
    Registered User
    Join Date
    Jun 2014
    Posts
    13
    Quote Originally Posted by Yarin View Post
    There is no such arch, perhaps you meant Mill.
    that's what I meant, the assembly language of the Mill is C++

    Quote Originally Posted by MutantJohn View Post
    x86 best architecture!!!!

    Well, it's the one I use. And what I use is the best, obviously.
    I like x64 myself, but if what the Mill promises is true, you can actually have mobile devices as powerful as desktop computers (because of the lower heat and power requirements of the Mill architecture) and desktop computers that are capable of easily vectorizing for/while loops to execute 32 instructions in parallel and writing them all to an array instead of going one index at a time

    that means a fully-functional Mill can outperform the top of the line Intel/AMD processors in some tight loops by an order of a magnitude while still being just a as fast in general-purpose code

  13. #133
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    Quote Originally Posted by iopq View Post
    that means a fully-functional Mill can outperform the top of the line Intel/AMD processors in some tight loops by an order of a magnitude while still being just a as fast in general-purpose code
    That sounds a little too good to be true. I'm going to take that with a grain of salt. True, the x86 architecture isn't the most efficient around, but I honestly don't think it will loose out to another architecture on such a degree. It's not like Intel/AMD are rolling their thumbs.
    What does C++ being an assembly language mean anyway?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #134
    Registered User
    Join Date
    Jun 2014
    Posts
    13
    Quote Originally Posted by Elysia View Post
    That sounds a little too good to be true. I'm going to take that with a grain of salt. True, the x86 architecture isn't the most efficient around, but I honestly don't think it will loose out to another architecture on such a degree. It's not like Intel/AMD are rolling their thumbs.
    What does C++ being an assembly language mean anyway?
    As you know, nobody writes assembly by typing in machine code directly
    Each assembly language is a macro language

    in other words, most assembly languages have the capability of writing

    Code:
    repeat  3
    add     ax, [bx]
    add     bx, 2
    endm
    this would generate an intermediate code of

    Code:
    add     ax, [bx]
    add     bx, 2
    add     ax, [bx]
    add     bx, 2
    add     ax, [bx]
    add     bx, 2
    add     ax, [bx]
    and then get generated to machine code
    this is the "macro" part of the macro assembler language


    on the mill, that "macro" language is C++
    so you write

    Code:
    for (int i = 0; i < 3; ++i)
         addu(b3, b6);
    and that will generate an executable file
    that executable file contains three calls to the addu "function"

    all the addu "function" does is generate the correct machine code for that instruction, so once you call it three times, it's just the same thing as generating a temporary file that says

    Code:
    addu(b3, b6);
    addu(b3, b6);
    addu(b3, b6);
    this means that you can use all the if statements, loops, classes, templates, anything you want in C++, and eventually you'll get native Mill machine code as the output

    I attended this talk about the Mill where Ivan Godard explained how it worked: http://millcomputing.com/topic/specification/
    Last edited by iopq; 06-22-2014 at 03:21 AM.

  15. #135
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,604
    So in other words, it just generates more complex instructions. Though I'm not sure if that's an advantage all the times, as history has taught us that RISC architecture often perform better than CISC. x86 translate complex instructions into micro-ops that are more RISC-like too.
    But I'm pretty sure that x86 can (I am not an expert in x86 assembly, though) do:

    add ax, [bx + 0]
    add ax, [bx + 2]
    add ax, [bx + 4]
    add ax, [bx + 6]

    etc
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Do I talk too much?
    By GoodStuff in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 05-20-2003, 10:45 PM
  2. Who wants to talk on AIM?
    By Death Wish in forum A Brief History of Cprogramming.com
    Replies: 0
    Last Post: 07-05-2002, 06:29 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21