Announcement

Collapse
No announcement yet.

The Tech Preview Of Servo/Browser.html Is Imminent!

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by eydee View Post
    When it's finished, and you have a browser powered by servo, if it does what you expect from a browser, then it's a good one. Written in C or LOLCODE, it doesn't matter a little bit.
    This idea that languages cannot be compared objectively is a poor one. The language should and does matter. Web browsers account for a majority of code exploits on a system, so we should be able to guarantee that the source code is safe at any and every point in time. This cannot be done with C or C++.

    Comment


    • #32
      Originally posted by Master5000 View Post

      So you see no problem building things using unfinished tools. No problem then....
      I see no problem building things using unfinished tools, so as to find possible problems as well as to identify new ideas that can make the unfinished tool even better. And then I can further improve this tool before it is finished, which is before it gets much less convenient to improve. And after that if the thing I built with this originally unfinished tool remains useful and not problematic after the tool is truly completed, I may as well further improve this and make it useful.

      It's really not that different than program testing. It's programming language testing: you only really get to test how good a language is and how you can improve it by actually putting it to use. Now the things you did, originally intended for testing, turn out good and very usable, so you use it instead of ditching it, would that be a problem?

      Comment


      • #33
        Originally posted by Master5000 View Post

        So basically C++ will assimilate some features from Rust. So I'm right. Rust will be DOA. Since we will continue to use C++ with some Rust features .
        Why aren't you in love with Lisp? If you learned Lisp, by your reasoning, you would never have to learn any language ever again, since it can (and does) seamlessly integrate ideas from other languages. If you want a One True Language that you can preach as the messiah forever, there are better options than C++... (not that I condone that kind of thinking)

        Comment


        • #34
          Originally posted by zamadatix View Post

          It's more D than C# but it's more C++ than D. Java/C# -> D -> Rust -> C++/C.
          Here, have an upvote.
          I'd have given you two (assuming I could) if you managed to extend this a bit further with a mention of Scala and Cyclone

          Comment


          • #35
            Originally posted by bug77 View Post
            I checked browser.html like a month ago. For browser written in HTML, it would only score 200 something points in html5test.
            I have a feeling this will be a really limited tech-preview. Still, it's a step forward.
            Yeah, I just updated yesterday and it has not gotten better.
            It rather haphazardly deals with pointer input, the browserhtml window doesn't resize the content if content>window<screen, layouts are broken on pretty much every page I've tried, and it is still super slow to provide a finished page.
            BUT, once the page is loaded, it scrolls faster than any other browser I've tried (I don't think this is due to webrender, directly, but that they are storing the entire page as a texture---or maybe just an image).

            Comment


            • #36
              BTW, why is everyone ack'n the TROLL?
              I've heard it said that they derive their power from attention.
              If you just turn your back and ignore them, they simply Keyser Söze-away.

              Comment


              • #37
                Originally posted by jrch2k8 View Post
                4.) Well syntax apart, i read part of the docs you linked (google it yesterday) and for many things seems to be competitive enough but for others there isn't an obvious relation, for example:

                a.) how do i bypass/override on demand heap and stack allocations to implement my own allocator? for many cases standard compiler allocation is a no no for me.
                b.) how do you access kernel infrastructure? lets say memfds and common aio syscalls
                c.) with threads, how you handle scheduling? affinity? offloading? private custom data? manual synchronization? lifetime?
                d.) how do you replace the vector and containers allocator?
                e.) how i can manipulate type size and aligment?

                just to name few things are not exactly intuitive on the docs, to be fair in C/C++ wasn't easy to learn either without some google fu through the years.
                An extensive array of documentation for further elaboration and example is provided on the website. It is also included with every installation of a Rust toolchain on your filesystem so there is no need to have Internet access to read this documentation.

                A) Everything is allocated on the stack unless you use `Box` to allocate on the heap, where it is generally recommended to keep everything on the stack. You can implement your own allocator if you think you can do a better job than jemalloc or the system allocator, but there's no evidence to support that this is would provide any improvement in performance and is a very bad idea. If you are trying to write a kernel or embedded software, then you would be using #[no_std] and exclusively sticking to libcore where you could create and use your own allocator if you wish, along with your own standard library with it. Redox has experience with this.

                However, for any other type of application there's no reason to do so as Rust carefully inserts calls to deallocate and allocate memory precisely based on the strict compiler rules. In example, if you borrow a value, that value will be freed after use. If you instead pass the value by reference, it will not be freed and you will continue to be able to borrow it elsewhere, or until the block where it was created exits, where it will be freed. You may even perform fine control over the freeing of memory by creating blocks within your blocks so that the values will be freed immediately after use.

                B) Rust's standard library has abstracted the features of each operating system so that you can write software that runs on all architectures without ever requiring to access OS-specific APIs. However, the standard library does provide of means of obtaining OS-specific features, such as from the std:s::unix module. You can, however, use the nix crate, whose Linux documentation is here, to gain low level access to Linux kernel APIs. You may also use the libc crate to access any C library on the system, alongside the standard library's ffi module which provides C types. In addition, there is an example of creating a Rust-based kernel module for Linux. There are similar projects that do the same for Windows.

                C) I thought that Rust's book covered this decently well along with the API's std::thread and std::sync pages. It is perhaps one of the most important primary goals of Rust, and one of the driving reasons of the ownership and borrowing model. It is a very advanced topic so it would be difficult to cover it here, as there are a number of different approaches for all levels of programming knowledge. Generally, as in Go, Rust also supports a channel mechanism with selectors. There are Multi-Producer, Single-Consumers provided in std::sync::mpsc; Single-Producer, Multi-Consumers like the bus crate; Multi-Producer, Multi-Consumers like the chan crate; and whatever else you want. Scheduling is not a problem as it's rather easy to synchronize.

                D) They use the same allocator as everything else: jemalloc or the system allocator.

                E) Rust does this for you automatically so that's never required, but you can create private fields in your structs that begin with _ in their name to pad alignment.

                5.) i'm not saying is not competing or could not, but still there are billions and billions of LoC of C/C++, trillion of $$$ in investments, million of developers, thousand of tools, millions of books, millions of helpful articles, papers and so on. So yeah it will take long time to reach that grade of maturity as a language(as an integral tool not as technical comparison).
                You don't have to throw away a codebase over night. You don't even have to throw it away to begin with. You can take a C/C++ function in a large codebase, rewrite it in Rust and then import it back into the original project, much as was done with the Rust implementation of Google's Zopfli library.
                Last edited by mmstick; 28 June 2016, 08:38 PM.

                Comment


                • #38
                  A.) Well in x86 desktop applications maybe, outside of it it is quite needed and common, some hardware need some real nasty allocation frameworks that no compiler will simply guess but sure i guess those aren't explicit rust targets and to be honest i'm not sure llvm can even compile on those. but yeah in X86(and other commercial platforms) is weird this kind of operations and not always recommended, i agree

                  b.) ok that nix crate seems to have some of the most common ones, i'll check it out later more deeply

                  c.) Well, yeah some common cases are there but i guess you can abstract some pthread magic in a C++ library and call it from rust later, as A in x86 single socket system you can let the tooling do most of the job but in other platform you need surgical control but ok, i'll try something later and see

                  d.) same as A

                  e.) same as A

                  Is nice rust uses jemalloc

                  thanks for the information and your time, i guess the harder part is find out if my brain can adapt to the language syntax(God i find it so horrible, at least initially ... maybe my brain is way too wired to the C/C++ syntax)

                  Comment


                  • #39
                    Originally posted by jrch2k8 View Post
                    thanks for the information and your time, i guess the harder part is find out if my brain can adapt to the language syntax(God i find it so horrible, at least initially ... maybe my brain is way too wired to the C/C++ syntax)
                    I have multiple projects like this, this, this, and this, written in Rust that you can use to learn from. I have made sure to carefully document everything within any project I write in Rust. I never got deeply involved with writing software in C or C++, so Rust was super easy for me to pick up, having also learned Haskell and Go beforehand. The more you write software with Rust, the more expressive you'll be able to be with it.

                    I generally recommend people new to the language to carefully study the Result and Option sum types and their methods. Write them down because they can be very powerful in everyday Rust code. After mastering their methods you can then proceed to try out combining sum types with pattern matching enums that possibly contain completely different types and number of values. Useful for error handling like so.

                    You can do a number of interesting things with sum types and pattern matching, like pattern-matched while loops and if expressions.

                    Code:
                    while (Some(a), Some(b)) = (iterator.next(), iterator.next()) { }
                    
                    if let Ok(value) = attempted_action() { }
                    Last edited by mmstick; 28 June 2016, 11:00 PM.

                    Comment


                    • #40
                      Originally posted by starshipeleven View Post
                      Here kids we can see a troll in his natural environment, a forum thread full of more or less knowledgeable people.

                      Note how he impersonates (more or less unsuccessfully) a developer when he isn't.

                      How with consummate skill in name-calling he is shitting on the subject most likely to cause reactions.

                      Some unsuspecting victims bite his bait and answer, only to get called names and all their points summarily dumped.

                      Oh, look, now he is chest-tumping! Take photos, fast!
                      I'm beginning to suspect he is impersonating a Microsoft/Windows zealot to make people hate Microsoft/Windows.
                      If so, it's beginning to work.

                      His comments combined with the BS currently going on with my developer machine (trashed registry prevents me from installing apps or using the background download API. Worked before I went into the weekend, then it mysteriously stopped the moment I stepped into the office again, Monday morning) definitely pull me in that direction, so it definitely works ...

                      Comment

                      Working...
                      X