81–90 of 344 posts
Earlier quoted context omitted.
The performance of the compiled code is great, and the performance of the compiler is something they have identified as a major issue to fix, and are working to solve it.
So did the now-dead game companies. Performance is like money: it's easy to squander and hard to acquire.
The bootstrap problem is real and getting worse: go needs go, haskell needs haskell, rust needs rust; it's nasty. There are already "better" and "safer" languages that could easily replace the entire unix userland. Heck, awk can do half of it, but all of that C code is already written...
> go needs go, haskell needs haskell, rust needs rust And C needs C, or for more recent compilers, C++ needs C++. You just don't notice it because these two languages are already part of the base system.
That's painful. It's one big point which Nim [1] does better. It compiles to C and bootstraps from C. That makes porting to other platforms much easier.
I don't understand why Haskell and Rust don't provide bootstrapping from C. Did they write the first compilers with Assembler?
> You just don't notice it because these two languages are already part of the base system.
C (not C++) has become the essential foundation on any platform. You will likely not be able to sell your embedded system unless it supports C.
Earlier quoted context omitted.
Rust fell into the same trap that killed many, many gamedev companies: Performance matters. Even more than features.
Are you implying that Rust isn't performant?
The bootstrap problem is real and getting worse: go needs go, haskell needs haskell, rust needs rust; it's nasty. There are already "better" and "safer" languages that could easily replace the entire unix userland. Heck, awk can do half of it, but all of that C code is already written...
No it doesn't. You can use gccgo to bootstrap go.
Earlier quoted context omitted.
> go needs go, haskell needs haskell, rust needs rust And C needs C, or for more recent compilers, C++ needs C++. You just don't notice it because these two languages are already part of the base system.
> go needs go, haskell needs haskell, rust needs rust That's painful. It's one big point which Nim [1] does better. It compiles to C and bootstraps from C. That makes porting to other platforms much easier. I don't understand why Haskell and Rust don't provide bootstrapping from C. Did they write the first compilers with Assembler? > You just don't notice it because these two languages are already part of the base sy…
I don't know about Haskell, but the first Rust compiler was written in OCaml. See for instance the comments at https://www.reddit.com/r/rust/comments/6nt2j1/is_there_any_e...
A bit incendiary: I fail to see what advantage rewriting existing and proven tools with a new language would bring. Shouldn't the main value new tools bring to be enable writing of new things? Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value?
OpenSSL is a classic counter-example. Interestingly, there are two different approaches actually happening to fix OpenSSL:
- Taking the existing C code base, throwing a lot away and cleaning up the rest, e.g. LibreSSL (developed by the OpenBSD people)
- Taking the TLS spec and rewriting the library from scratch in a safe languange, e.g. ocaml-tls.
Earlier quoted context omitted.
> go needs go, haskell needs haskell, rust needs rust And C needs C, or for more recent compilers, C++ needs C++. You just don't notice it because these two languages are already part of the base system.
> go needs go, haskell needs haskell, rust needs rust That's painful. It's one big point which Nim [1] does better. It compiles to C and bootstraps from C. That makes porting to other platforms much easier. I don't understand why Haskell and Rust don't provide bootstrapping from C. Did they write the first compilers with Assembler? > You just don't notice it because these two languages are already part of the base sy…
We don't provide bootstrapping from C because no C-based toolchain has ever existed. However, it may in the future; see my link upthread.
The bootstrap problem is real and getting worse: go needs go, haskell needs haskell, rust needs rust; it's nasty. There are already "better" and "safer" languages that could easily replace the entire unix userland. Heck, awk can do half of it, but all of that C code is already written...
> go needs go, haskell needs haskell, rust needs rust And C needs C, or for more recent compilers, C++ needs C++. You just don't notice it because these two languages are already part of the base system.
Every time you add a new language feature you increase them time to write your bootstrapping compiler. Garbage collection means you will spend a few more months building a garbage collector. (remember we are writing in machine language so most of the abstractions you are used to dealing with - even in assembly - are missing. Thus complexity is growing exponentially)
Earlier quoted context omitted.
He has a point though... As we get more CPU/ram we as programmers don't even bother to check how many resources we are using. Personally, I don't know whether its a good thing or a bad thing. Also in terms of systems languages I believe only rust has some potential to truly replace C. Although, a large part of C usage still takes place in the embedded world where rust has yet to be ported to many embedded processors.…
I run full Windows 10 on a tablet (dual core, 2GB RAM), and it's pretty amazing to me how many websites that have no reason to run slow completely fail on it. I can only imagine it works fine on dev machines with much faster quad+ cores and 64GB of RAM or whatever. Just as an aside, it's done a lot to have the tablet be my primary "fiddle-at-home" machine: keeps me really conscious of resource limits, including ones…
The solution is to install 32-bit Linux on it. Then it won't suck.
A bit incendiary: I fail to see what advantage rewriting existing and proven tools with a new language would bring. Shouldn't the main value new tools bring to be enable writing of new things? Isn't focusing on existing utils more like a lack of imagination and OCD on optimizing a thing beyond any further value?
I think code safety is not an issue here because the Posix tools (and Unix/Linux as a whole) have already proven their extreme reliability.
The only real advantage to rewrite the Posix tools is motivation. A rewrite in a modern language like Rust will likely keep maintainance longer alive than old C code that no one likes to maintain.
It's the same reason why a new display manager (Wayland) is wanted instead of X11. There is basically no technical reason to replace the X server which works very well to this day. However, there are not much people anymore who like to maintain the old X code, or to support new graphics cards in X.