Dart 2.0 Released As A "Reboot" To The Programming Language

[Michael_S]

Javas Integer does also default to null.

Yes, but Java has 'primitives' - int, long, float, double, char - that cannot be set to null.

[Weasel]

Rust is probably the best designed language in existence

C is the best designed language in existence.

It's far from perfect but you don't have to be perfect to be the best; it's enough to be better than all the other garbage out there, to fit the bill.

The fact that people like Linus Torvalds use it is a bonus, since he's the Chuck Norris of computing.

[duby229]

C is the best designed language in existence.

It's far from perfect but you don't have to be perfect to be the best; it's enough to be better than all the other garbage out there, to fit the bill.

The fact that people like Linus Torvalds use it is a bonus, since he's the Chuck Norris of computing.

I totally disagree. It's just too hard to get much parallelism out of it. Just look at multithreading, it's exponentially difficult. C was designed in an age when serial linear computing was the only possibility and those machines had tiny amount of memory. C has been updated numerous times, but it's still linear as fuck.

EDIT: C should have been universally replaced the moment multi-core CPU's were launched way back in like 2006 or so. It's at least 12 years too late already.

[Weasel]

I totally disagree. It's just too hard to get much parallelism out of it. Just look at multithreading, it's exponentially difficult. C was designed in an age when serial linear computing was the only possibility and those machines had tiny amount of memory. C has been updated numerous times, but it's still linear as fuck.

EDIT: C should have been universally replaced the moment multi-core CPU's were launched way back in like 2006 or so. It's at least 12 years too late already.

CPUs work in a "serial linear computing" manner so no idea what your point is. C works exactly the same way as a CPU does, in "linear" fashion.

It's also not dependent on stupid special "standard library multi-threading" garbage since, well, they're normal C libraries. For example you can simply use native threading APIs directly in C, since that's how the system works anyway. Literally ALL other languages in existence rely on "special behavior" from standard library or something equally stupid, because they have nothing to do with how computers actually work. (that's also why they're so bloated, given that their runtimes must be).

With C you can even compile something completely functional with zero standard library use (there's the -nostdlib command line you can supply to GCC), and make it fully threaded and extremely efficient, by using the APIs directly. Anything else is an abstraction that will lower performance, and if you're looking for multi-threaded stuff, you clearly care about performance.

[bug77]

CPUs work in a "serial linear computing" manner so no idea what your point is. C works exactly the same way as a CPU does, in "linear" fashion.

It's also not dependent on stupid special "standard library multi-threading" garbage since, well, they're normal C libraries. For example you can simply use native threading APIs directly in C, since that's how the system works anyway. Literally ALL other languages in existence rely on "special behavior" from standard library or something equally stupid, because they have nothing to do with how computers actually work. (that's also why they're so bloated, given that their runtimes must be).

With C you can even compile something completely functional with zero standard library use (there's the -nostdlib command line you can supply to GCC), and make it fully threaded and extremely efficient, by using the APIs directly. Anything else is an abstraction that will lower performance, and if you're looking for multi-threaded stuff, you clearly care about performance.

sed 's/C/ASM/g'

[duby229]

CPUs work in a "serial linear computing" manner so no idea what your point is. C works exactly the same way as a CPU does, in "linear" fashion.

It's also not dependent on stupid special "standard library multi-threading" garbage since, well, they're normal C libraries. For example you can simply use native threading APIs directly in C, since that's how the system works anyway. Literally ALL other languages in existence rely on "special behavior" from standard library or something equally stupid, because they have nothing to do with how computers actually work. (that's also why they're so bloated, given that their runtimes must be).

With C you can even compile something completely functional with zero standard library use (there's the -nostdlib command line you can supply to GCC), and make it fully threaded and extremely efficient, by using the APIs directly. Anything else is an abstraction that will lower performance, and if you're looking for multi-threaded stuff, you clearly care about performance.

I hate to be the one to tell you this, but every modern CPU has at least 2 fully functional and parallel integer pipelines. It's a fact and it's been a fact for a looooong time already. Just extracting enough parallelism out of C for 2 threads is ridiculous, and 8 threads is nearly impossible. But here we are in todays world with single socket processors with a full 16 pipelines able to run 32 threads. There are some types of loads like GCC where passing a -jx to make allows it to run multiple GCC processes simultaneously. That's called multiprocessing, but there the is -no- chance in any hell you could write GCC to extract even just 4 threads out of a single process let alone 32. That won't happen ever on any load, not with C.....

EDIT: And because of how retarded object orienting is the fact of the matter is that most apps -cannot- be effectively multiprocessed. Which means almost all of almost everything ever written in C is single thread and single process. Facts whether you like them or not.

[Sniperfox47]

I hate to be the one to tell you this, but every modern CPU has at least 2 fully functional and parallel integer pipelines. It's a fact and it's been a fact for a looooong time already. Just extracting enough parallelism out of C for 2 threads is ridiculous, and 8 threads is nearly impossible. But here we are in todays world with single socket processors with a full 16 pipelines able to run 32 threads. There are some types of loads like GCC where passing a -jx to make allows it to run multiple GCC processes simultaneously. That's called multiprocessing, but there the is -no- chance in any hell you could write GCC to extract even just 4 threads out of a single process let alone 32. That won't happen ever on any load, not with C.....

EDIT: And because of how retarded object orienting is the fact of the matter is that most apps -cannot- be effectively multiprocessed. Which means almost all of almost everything ever written in C is single thread and single process. Facts whether you like them or not.

I hate to agree with Weasel but you're pretty wrong here. C absolutely *can* be used to make massively threaded applications. You can manually bind all the interthread locking and communication system no problem. They're platform specific so any compiler is going to need to do platform specific stuff to make threading work.

There's a reason why most GPGPU shaders used to be written in raw C (prior to things like OpenCL and CUDA).

You'd have to hate yourself to do it, it would be painful and asinine, but it can be done. And as Weasel mentioned, it can (at least theoretically) be done at higher performance than other more abstracted languages. C is not JS by any stretch of the imagination. That being said you can also make totally threaded applications in assembly. That doesn't mean it's a good idea to do.

But maybe we can get back on topic?

Yet again I would have to provide a list of things. There is no killer feature that if Dart did this I would use it but instead a lots of smaller features of TypeScript that ways up its weaknesses.

1. Object literals. Not having to classify everything makes it easier to start something, to refactor and to create good solutions for specific problems. The class tree creates a lot of overhead that it doesn't repay later on.
2. Serialization. As objects doesn't come from classes, they have no logic and is just data. That makes it super simple to (de)serialize which is a very common task in Web or near-web environments as you have storage on server and client side, lots of network traffic, server and client side logging and more. Sure many languages have in built tools or good libraries to deal with this, but not having the problem in the beginning is even better.
3. Integration in the platform. The web is developed JavaScript first. I can directly access every feature of the platform with it while with Dart I either have to wait for it to be included in the core or develop workarounds myself.
4. Libraries. There are certain key libraries that are just so good that they influence the language choice quite a lot. React is one of them.

That's the most immediate that pop up. Number 2 might not sound important but I promise you that having developed basically the same things in Dart and TS, it is.

How do you deal with threading in Typescript though? Just manual web-workers?

Dart has Isolates which are proper threads in dedicated Dart VMs (Chrome, Flutter, and Android/iOS) and automagically get converted to web workers for you when exporting to JavaScript. It's pretty nifty from what little I've played with it.

[duby229]

I hate to agree with Weasel but you're pretty wrong here. C absolutely *can* be used to make massively threaded applications. You can manually bind all the interthread locking and communication system no problem. They're platform specific so any compiler is going to need to do platform specific stuff to make threading work.

There's a reason why most GPGPU shaders used to be written in raw C (prior to things like OpenCL and CUDA).

You'd have to hate yourself to do it, it would be painful and asinine, but it can be done. And as Weasel mentioned, it can (at least theoretically) be done at higher performance than other more abstracted languages. C is not JS by any stretch of the imagination. That being said you can also make totally threaded applications in assembly. That doesn't mean it's a good idea to do.
.

Just because something can be done in abstract does not mean that a person actually -could- do it. Multithreading in C is exponentially difficult. Given the most optimal workload only a handful of people could write efficient 2 thread code and basically nobody at all can write efficient 8 thread code. Not with C. Any example you think you could come up with would almost certainly perform better in a single thread. And this at a time when 16 core processors are available now and 2 core processors have been available for over a decade.

EDIT: And also that's not even considering the fact that basically all C/C++ programmers are taught object orienting like it was a religion.... Most programmers might as well forget multithreading because the way most people are taught C makes even multiprocessing an extremely difficult prospect.

[bug77]

Just because something can be done in abstract does not mean that a person actually -could- do it. Multithreading in C is exponentially difficult. Given the most optimal workload only a handful of people could write efficient 2 thread code and basically nobody at all can write efficient 8 thread code. Not with C. Any example you think you could come up with would almost certainly perform better in a single thread. And this at a time when 16 core processors are available now and 2 core processors have been available for over a decade.

EDIT: And also that's not even considering the fact that basically all C/C++ programmers are taught object orienting like it was a religion.... Most programmers might as well forget multithreading because the way most people are taught C makes even multiprocessing an extremely difficult prospect.

1. What language is Linux (the kernel) written in?
2. Is Linux multi-threaded?
3. yw

[Weasel]

I hate to be the one to tell you this, but every modern CPU has at least 2 fully functional and parallel integer pipelines. It's a fact and it's been a fact for a looooong time already. Just extracting enough parallelism out of C for 2 threads is ridiculous, and 8 threads is nearly impossible. But here we are in todays world with single socket processors with a full 16 pipelines able to run 32 threads. There are some types of loads like GCC where passing a -jx to make allows it to run multiple GCC processes simultaneously. That's called multiprocessing, but there the is -no- chance in any hell you could write GCC to extract even just 4 threads out of a single process let alone 32. That won't happen ever on any load, not with C.....

EDIT: And because of how retarded object orienting is the fact of the matter is that most apps -cannot- be effectively multiprocessed. Which means almost all of almost everything ever written in C is single thread and single process. Facts whether you like them or not.

I literally have no idea what you're talking about, to me looks like techno-babble.

Maybe try learning x86 assembly language? Would really help if you want to talk about such low level stuff as pipelines. (pipelines are completely transparent in a given core to an application, you can't control that, it's done dynamically at execution time by the CPU, and it does matter because it depends on which branches are taken and so on, you cannot fill them up properly "statically" or "at compile time", that's why VLIW failed for most "normal" desktop workloads)

Also -jx is a make thing, it simply runs GCC for each file that doesn't depend on another, as a wholly separate process. Nothing about C there, just basic Unix stuff. Ever used xargs with the -P option? It's similar.