Goodbye OOP

[Tenaja]

Got+ was written in c.

[tj1010]

That was all marketing for abstract languages like Python, .NET, and PHP etc..

All those really addressed was development overhead...

And this language is doing the same thing. It claims zero-cost abstraction, when in reality, that cost is being exacted in the form of huge executables.

Truly low-level languages don't fall victim to that.

The size of the PE/COFF means little outside map-space made by the NT loaders. In the case of Windows OS. A 2MB exe or dll can easily be more efficient than a 1.2KB one because of dynamic allocation and CPU timing and stack frame cleaning algorithms. Not to mention hardware and software cache optimization.

I only know about Rust because people famous for reverse engineering and security say it remedies a lot around memory corruption attacks and byte optimization.

[TI-994A]

A 2MB exe or dll can easily be more efficient than a 1.2KB one ... it remedies a lot around memory corruption attacks and byte optimization.

Two thousand times bigger binaries for security and optimisation?

[Lunasole]

Twenty times bigger binaries for security and optimisation?

It uses some embedded runtime, like one that MS C++ compiler allows to add (to prevent several errors while app running, like buffer overflow).
But unlike MS or GCC stuff, that one is really bloated, also includes things like garbage collection and many other. So not strange if they made another .NET, but all runtime is packed to executable, instead of placing it to a system folders, lol.

Nothing new, that's old google concept of code sandboxing, another trend to make monkeys life easier.
At the beginning google write all it's scripts and servers on php, then they realized how it is slow and wastes electricity, were making attempts to translate php to C, then using other faster toys like python, but seems finally got tired and decided to create own php, which is compiled to native from the beginning ^^

None of the C coders I know found that "Go" tool for webmonkeys useful or migrated to it. They only saying It has few interesting things like deferred functions, but generally is useless.
But I'm afraid the google has enough resources to make it popupar, so soon we will see mouse drivers not of 50mb in size (there were jokes about it in 2006, now it is reality), but whole 500 ^^

[the.weavster]

None of the C coders I know found that "Go" tool for webmonkeys useful or migrated to it. They only saying It has few interesting things like deferred functions, but generally is useless.

Some monkeys that do find Go useful:
Google
Dropbox
Soundcloud
Docker
BBC


And here's an interesting blog post on Rust.
To summarise: Monkeys will love it

[Lunasole]

To summarise: Monkeys will love it

Surely they love ^^. Go is almost like php for them, but without performance and some other problems. It is hard to imagine that web-monkeys (even from google) can code something on languages with low abstraction like C, that's why they reinvented such hybrid of php and C to write all they doing and replace python and other such.

But well, enough from me talks about monkeys :3 I was talking about coders who writing in C, still only very few of them seeing Go or Rust as really possible alternative and that is good (but don't know how this may change in future).

[TI-994A]

...not strange if they made another .NET, but all runtime is packed to executable, instead of placing it to a system folders...

Yes; all statically linked. I believe that it could also be dynamically linked, but that would only result in runtime dependencies; same bloat.

Hardly feels like a low-level powertool; the way PureBasic does.

[tj1010]

File system size has nothing to do with runtime. One of my PB games is 2.76MB but averages over 8MB private memory at idle in background and I only procedural generate some strings and use them for a canvas based display with some embedded PNG.

I'd be willing to bet a Rust program is more efficient than the same program written in c++ by the average c++ coder, or NASM or FASM if you choose.

[TI-994A]

File system size has nothing to do with runtime. One of my PB games is 2.76MB but averages over 8MB private memory at idle in background...

That's not what is meant by runtime. You're referring to memory footprint. The runtimes being referred to are the dependencies that are bundled with the executables, that are causing the bloat in the file sizes.

I'd be willing to bet a Rust program is more efficient than the same program written in c++ by the average c++ coder...

That'll be a bet you'd lose. Through managed code, as with many other high-level languages, it might be able to reduce illegal operations and unstable processes. But unless it is equipped with an AI compiler that could understand the intentions of the coder, and then re-write that code efficiently, it's not going to be able to produce a more efficient program; just a safer one, at best. At the end of the day, the efficiency of any program would boil down to the code structure and coder practices. GIGO.

On the other hand, the development platform and compiler are responsible for the execution speed and file size of the resulting binaries.

[the.weavster]

Mozilla's Servo (written in Rust) massively outperforms Gecko (written in C++).

[tj1010]

File system size has nothing to do with runtime. One of my PB games is 2.76MB but averages over 8MB private memory at idle in background...

That's not what is meant by runtime. You're referring to memory footprint. The runtimes being referred to are the dependencies that are bundled with the executables, that are causing the bloat in the file sizes.

I'd be willing to bet a Rust program is more efficient than the same program written in c++ by the average c++ coder...

That'll be a bet you'd lose. Through managed code, as with many other high-level languages, it might be able to reduce illegal operations and unstable processes. But unless it is equipped with an AI compiler that could understand the intentions of the coder, and then re-write that code efficiently, it's not going to be able to produce a more efficient program; just a safer one, at best. At the end of the day, the efficiency of any program would boil down to the code structure and coder practices. GIGO.

On the other hand, the development platform and compiler are responsible for the execution speed and file size of the resulting binaries.

All languages use lexical analysis to convert to byte code stack frames that use returns and jumps. There is no need for AI. This is where optimizations are implemented like short-jumps, type conversion etc.. Then you have things like CPU branch prediction etc..

I'd bet any day that the average C++ coder not only bails on most big projects do to language design bottlenecks, but also writes inefficient and vulnerable code.

[TI-994A]

There is no need for AI.

The bit about the AI compiler was meant as a quip. We're not there, just yet.

[Keya]

how about superoptimization introduced in 1987 by Alexia Massalin she also worked on GCC
https://en.wikipedia.org/wiki/Superoptimization

btw programmers are putting a lot of people out of jobs ... how long until programmers develop programs that put perhaps most programmers out of jobs?!? surely it's probably "only a hundred years or so" away? or will programming always be job-secure in that sense!?

[tj1010]

how about superoptimization introduced in 1987 by Alexia Massalin she also worked on GCC
https://en.wikipedia.org/wiki/Superoptimization

btw programmers are putting a lot of people out of jobs ... how long until programmers develop programs that put perhaps most programmers out of jobs?!? surely it's probably "only a hundred years or so" away? or will programming always be job-secure in that sense!?

StackGuard and ProPolice have been implemented a long time and people are still finding vulnerable memory corruptions and exploiting them. The same goes for GCC optimizations and actual binary performance. What good is saving a couple bytes on the RETN of a stack frame if the coder has memory leaks?

Don't be scared of A.I. replacing humans any time soon. Just look at all the fail happening despite massive spending and talent around self-driving cars. I'd say centuries away before we even get semi-automated A.I. with an acceptable rate of failure. Self-driving cars and the bitmap pattern algorithms around that are far more simple than something like a functioning bipedal A.I. bot that can drive a car or cook food or clean a house. Quad-copter auto-correct algorithms have also hit a human-intelligence plateau. Self-teaching AI can go very deep in to context but is still limited to what human creators can comprehend if even that much.

Extremely specific A.I. for data science work very well though if you spend the time gathering back-data.