I am thinking if there could be one universal efficient programming language that could perform multiple tasks then it had been cool... Maybe it may cause programming languages singularity !!!

Maybe if there would be a single most efficient Race and Religion of People, there would be singularity and World Peace.

Kill all the current developers and teach the next generation only 1 language, that's the only solution.

@theabbie Yeah lol :)... There wouldn't be much tension regarding the compatibility of different tech stacks/technologies if there's one language... Though I think in the far future it may be a language that AI may generate/create ...

Why, that's what C++ tried to do - and it sucks.

@Fast-Nop Yeah... The way development is progressing ... huge no. of code lines with optimization is something to be tackled ....
I think even python tried to attempt the same but it's slow ... Also I believe in dev it's scope is just for backend... a language for frontend/backend/android would be cool.... I think there haven't been any known attempts in doing that...

Have you seen Rust though

@12bitfloat Nope ... I've to try it though!

@Surajv It's really amazing. As close to the "universal" programming language you can find

@12bitfloat Rust is designed as competitor for C, and it actually sucks at that role.

@Fast-Nop Where exactly does it suck at competing with C? It has basically the same performance and allows for the same low-level hardware access C does. It's also really portable, granted not as portable as C but still

@12bitfloat It sucks because the standard library is anaemic, you need crates for everything, only that there's no standardisation and you have no guarantee that crates from today will be maintained in 5 years.

It's dependency hell like NPM, which is no wonder because Rust came from a browser vendor where people think this is normal. And where the software product itself is short-lived because nobody uses 5 year old browsers.

The language itself isn't standardised either, and there's only one compiler vendor.

On top of that, Rust is a puzzle language where you spend more time to bend your architecture to Rust than actually coding. Even trivial shit like doubly linked lists or a data buffer shared between interrupt and application requires advanced Rust knowledge.

Or you just say "fuck this shit" and resort to "unsafe" whereever Rust gets in the way, negating the intended advantages as you go.

The only reason Rust code is "safe" is because it doesn't let you do anything.

Looking at history, its just not feasible. C++ tried it, Java tried it and JS is currently the latest runner.

@Fast-Nop First of all, the small std lib is because the Rust team doesn't want to cram bad code in there just for the sake of having it like PHP does (or did)
Still, it's UNIVERSES ahead of what C has, which let's be honest isn't even much of a stdlib and more a random set of more or less useful functions

Further, it's true that Rust has a lively, NPM-like ecosystem but I don't get your problem with it. You don't have to depend on any of it and code everything yourself ad-hoc style just like in C.
And even when a library gets abandoned your code doesn't just stop working, it may not get any new features but you still have what you signed up for

The fact that Rust doesn't have a spec is way blown out of proportion. It's only been 5 years since the lang stabilized with 1.0 and a lot of features ARE specified to great extents in their respective RFCs. It probably will get a spec at some point but it takes time

@Fast-Nop The last point deserves an extra comment because it's just categorically wrong.

Rust is a true systems language. All of it's memory safety mechanisms (apart from range checks, which all of your C code should have aswell!) happen entirely at compile time resulting in the the same code you would have written by hand in C.
*But that's exactly the issue*: Because you *wouldn't* have written the same safe code in C because you are human and you make mistakes.
70% of all bugs at Microsoft and in Chrome are memory saftey related. Almost ALL critical security vulnerabilities are memory safety related.

That's why Rust only allows you to dereference raw pointers in unsafe blocks.
And 99.9% of the time you don't need to do that.
And even if you do, at least it's apparant by the unsafe block where exactly the code you need to to audit is located at

@Fast-Nop RedoxOS is a unix-like OS written entirely in Rust. They didn't seem to have a problem with Rust holding them back, did they?

@12bitfloat If you don't see the problem with a language that has no ISO standard and only a single compiler vendor on the one hand and long-term projects on the other hand, I can only assume that you've never had to deal with long-term projects.

That problem won't get better because without ISO standard, you can't tell the compiler to use the standard from 2020 when it's 2030. Python is a cautionary example why you don't rely on non-standardised quicksand.

If you don't see a problem with an NPM like ecosystem and long term projects, I really can't help it. Oh you don't have to use... except you do have to because the standard library is anaemic.

That's the main reasons why most devs think Rust is super hot while next to nobody is using it in reality except for toy projects. And yeah, Redox OS is a very nice toy project that nobody uses written in a nice toy language.

Btw - C11 has thread support directly in the language, so the standard library isn't what it was in C99.

@Fast-Nop The difference between Rust and Python is that the Rust team actually has some common sense and doesn't introduce breaking changes. Outside of editions there is no backwards breaking change, ever.
Would a spec be good? Sure. But C++ has a spec which is almost useless because all compilers do fuckshit that is not in the spec.

If anything, calling Rust a toy language proves that you live in a low-level bubble with zero experience outside of it.
You only know C so C must be the be all end all of programming languages

Also kinda ironic since "C has multithreading in the std lib now" is the worst defense you could have possibly made when calling another language a "toy" lmao
Rust has always had multithreading in the stdlib including efficient mpsc channels and all sorts of other sync primitives. Because that's what you would expect from a systems language worth anything

Rust also prevents data races at compile time. Guess C isn't toy enough for something like that, huh?

@12bitfloat C11 is from 2011, that's nine years. Oh Rust has had it for one year longer when it was completely unusable, big deal.

The only reason why Rust prevents data races is the same why Rust is safe: because stuff like lockless access to shared buffers (extremely common in ring buffers) is moved to the "unsafe, we don't care" area anyway.

And yeah, betting on the Rust team as only "vendor" having common sense sounds like a great basis for industrial projects.

But I'm sure you'll have fun when you update a project from five years ago and shit won't even build anymore.

And no, threading isn't to be expected in a systems language because such a language will be used to IMPLEMENT threading in the first place.

There is a shitton of universal languages suitable for a lot of different tasks. Some optimized for speed, some for maintainability.
You can even choose any combination of paradigms and syntaxes - and chances are good that there is a reasonably performant universal language wich has been designed with the chosen set in mind.

So what are you missing?

@Fast-Nop @12bitfloat This discussion is exactly why a universal programming language is impossible.

I'm on the Rust-evangelists side. I've written backends (using Rocket.rs) and API clients (Reqwest) with it, networking proxies (Tokio), file conversion tools, web assembly frontends, a desktop application (Azul).

It can fucking handle everything, and its type system is at 95%-Haskell-level S-tier perfection.

But full-featured type systems (and in Rust's case ownership/borrowing/lifetimes/etc) do come with overhead. They warn you about risky code, or even make risky code impossible.

Sometimes you don't want risky code to be impossible. Sometimes, race conditions aren't a big deal -- like when you want a backend up and running TODAY, and it will handle 10 requests per hour.

I mean, I'm helping my wife to learn coding. Sure, Rust is perfection in my eyes -- but throwing someone in that pit is just mean. So of course I installed PyCharm & sent her a bunch of Python tutorials!

@12bitfloat @Fast-Nop Also, both C & C++ have the same exact problem as Rust:

High level of entry. For JS/Python, you ONLY need some logic and syntax. For PHP, and even more so for Java, you need a bunch of object oriented knowledge ("Why the fuck is my code in a class? What the fuck is a constructor? WTF WHY DO YOU KEEP TALKING ABOUT DEPENDENCY INJECTION?")

For C, someone must also have a deep understanding about memory management, filesystems, low-level networking, and complicated CS topics. I'm not going to explain what a Mutex is in dev bootcamp day 1.

Rust circumvents the C problem of memory management with a rock solid type system & ownership concept -- which is just as much of a steep learning curve as learning manual memory management.

Having that strict type system does come with a bunch of advantages in my opinion -- but no matter your preference, neither language is exactly suitable for:

* Teaching coding 101

* Quick prototyping

* Hiring a cheap team

@Nanos RISC-V ASM 🤔

@Fast-Nop I see you are not a follower of the way of the C++. Brother Stroustrup loves all. lol

Lol, started thinking of programming languages like religions:

C is the Jews

C++ is Christians

C# is Mormons

Javascript is Heavens Gate cult

@Fast-Nop Ruby is used in production, Go is used in production, JavaScript, Python, PHP, Perl. All used in production

So I don't see the problem with adopting Rust. It's not made by a company, it's fully open source. The "Rust team" is just the governing body having the last say.

How is that any different from the C or C++ commitee? It's not, and at the end of the day you'll always have to trust someone somewhere to not fuck shit up, no matter if that's a committee or a core team

Maybe I'm too naive to give this trust to the people behind Rust but I don't think so. They have proven themselves to do the right thing and advance the language in a great direction while being extremely careful about preserving backwards compatibility

@Nanos Java is Scientology, Assembler is atheism.

@12bitfloat With C/C++, you don't have just one compiler, you have several. Therefore, you have several teams arguing. This also prevents people from declaring stuff standard just because it's easier for their specific compiler to implement.

I won't trust a language that locks me to any single team and a single compiler vendor, no matter their track record. No second source == no, thank you.

And then you have ISO standards which mean that even e.g. current GCC 10 can compile ANSI C code from 30 years ago when I give -std=c89 as compiler option. Similar for C++98.

But without ISO standard and compiler switch support for them, future compiler versions may be required because of bugfixes, but will still fail to build current code even if it's archived completely locally.

Also, the ecosystem with anaemic std lib and hundreds of competing crates is a lottery in future maintenance.

Besides, I'm not really a fan of puzzle languages.

@Fast-Nop
So new languages only have a chance to become usable for you if there is enough dispute between users to make multiple compilers emerge?

@Oktokolo That's a pretty odd way to put it, which makes it a loaded question. The only correct way to deal with loaded questions is refusing to answer.

@Fast-Nop Just all the Rust teams combined, exluding all other contributors, consist of over 100 people and they argue non stop.
Which async/await syntax to choose was a months long debate with thousands of people chipping in.
So in fact, I'd say this way of doing things is better than C or C++ because design by commitee doesn't work. If you don't agree then why aren't you using C++?

As to implementations, having one official implementation is always gonna be better than having many non-portable ones.
Competition is only advantageous when you don't have a completely open source project in the first place. It's a waste of energy building a competitor when you could just make the official implementation better

Also stop with this dumb argument over the std lib. You're defending C. You have no ground to stand on whatsoever talking about a standard library

@12bitfloat I disagree. Having several implementations bound by a common standard is way better, not to mention that this makes them portable.

Which harks back to the problem that Rust doesn't have a standard and thus doesn't have an implementation - instead, whatever the current compiler code happens to be, that's the "spec".

And no, competition e.g. between GCC and LLVM is totally healthy although both are OSS, plus that there are a lot of other compilers in industrial use.

@12bitfloat I think I already mentioned C11, and I won't explain it again. If you compare 2020's Rust to 1990's C, that's your problem.

@Fast-Nop Does C11 have logging, UTF-8 strings (owned and slices, growable), growable vectors, deques, lists, hashmaps, btrees, error handling stuff, futures, composable iterators, panic handling stuff including backtraces, file path parsing/handling, reference counted smart pointers, mpsc channels, threads barriers?
No, it doesn't. Whether it's C99 or C11, they have the bare essentials

Compare the entirety of the C std lib (https://en.cppreference.com/w/c/... ) with that of Rust (https://doc.rust-lang.org/std/ ) and then tell me which one is anemic

@Fast-Nop
Okay, let me rephrase: You would only use languages where the compiler-building community is wasting resources by maintaining two different compilers instead of working together on one?

@12bitfloat Come on, stuff like growable vectors is trivial. Anyway, my issues remain, and I don't see Rust taking over any time soon. Since the discussion is turning in circles, I'm dropping out.

@Oktokolo Same kind of loading, just re-worded. I won't even reply to a third loaded question.

@Fast-Nop
No problem, you actually where pretty clear on both topics already.

@Nanos
Yes, it clearly is much more readable for everyone...
who speaks english.
The I in ISO stands for "international".

Current most-spoken language on this planet:
Mandarin Chinese with 918 million speakers.
Would you like to have "2012年9月27日" (google thinks, they use that format) instead of "September 27, 2012"?
I mean, it would still be pretty readable as they use our digits. ;)

You cannot mention C++ without mentioning the major libraries and ecosystems. They don't exist in isolation.

Boost (the testbed for standardization)

Qt (which has tons of objects that cover most of the objects that went into the stl)

Also, C++17/20 is way further along than C++11.

@Nanos

Get out with your imperial ISO dates!

Metric time FTW. And none of this Unix timestamp bullshit either.

435 petaseconds since big bang. 2 petaseconds since the dinosaurs roamed the planet. Heh, it feels like yesterday.

@Demolishun C++ is a foundation. Which is important... but I'd argue that a PyQt app will be finished faster than a C++ Qt app.

Sometimes you want a concrete foundation with a prefab wooden house on top.

Other times you just want to pitch an ugly tent, and write an electron app.

@bittersweet I have run into issues with Python ecosystem when freezing code (making exes). I am currently converting some apps I wrote in Python to C++ due to this problem. While I like Python, the problems with freezing and lack up libraries being updated to Python 3 has made me rethink using Python for desktop apps.

@Demolishun Yeah, building a neighborhood with wooden houses is faster, until there's a forest fire or hurricane.

@Nanos
If it starts with a year, the numbers are pretty unambiguous.
But you can also just memorize, that ISO dates are written like other numbers: Most significant digits first.

@Nanos Why the redundancy? You have a value and a unit.

The only true SI time unit we have is the second. The only true SI prefixes we have are kilo, mega, giga, etc.

Minutes, hours, days, weeks, all irrelevant.

A lunch break takes 1 or 2 ks (~17-34 minutes).

A human might focus on a single task for about 10 ks (2.7 hours) before needing a break.

A work period might last 25 ks (7h) per 100 ks (1.15d). A series of consecutive work periods could be 0.5 Ms (5.7d), after which you have 0.2 Ms (2.3d) completely off work.

You celebrate your birth once every 30 Megaseconds, or once per 0.1 Gigaseconds if you're not that social. Not because the planet completed a circle around a star, just because it seems like a good frequency to have people you don't like that much in your house.

Also instead of using 1970 or the Big Bang, both of which are impractical, we should use consider "now" to be roughly the 400th Gigasecond -- using 12000 years ago, approximately the start of human history.

@bittersweet
That is brilliant. Laughed hard.
But seriously: I would expect that to work pretty well after an accomodation time of 30 Ms.

@Nanos
Yes, standras only if people use them exclusively.

While transitioning from one standard to another, it obviously is important to make sure, that everyone involved knows what they are dealing with.
The cm/inch fuckup was definitely foreseeable and thank you for warning the management in advance (not your fault that they did not route the message to the one actually placing the order).
By the way: Next fuckup will be when switching from cm to mm, wich seems to be the real standard when it comes to machining stuff...

The beauty of current short date formats is their space-efficiency while still being exceptionally easy to parse for humans _and_ machines alike.
ISO did not invent that format. They just picked the only one of them that also supports easy sorting. Some countries already used it.
"2020-10-08" does not need any language translation for almost the entire population. Add words and you hinder sortability for all and readability for most.

@Oktokolo The advantages of not coupling time to periodic events of our planet (day/night, seasons) is also that:

1. It works for all timezones
2. It is planet-neutral
3. Having no new year's is culture-neutral

@bittersweet
Yes. I really am of the opinion, that it would work pretty well.
But the first reaction of the tech people is laughter regardless. And non-tech people will just outright call it "madness".
So while it would be a good thing, it certainly will not happen.

By the way: TAI for the win.

@Nanos
Yes, that is why a lot of things aren't sorted alphabetically - their alphabetic order differs from the order, people would want to sort them.

The beauty of a standard wich leds to intrinsic sortability of values is, that you do not need to define specific sort orders for each language.

Being language agnostic also most obviously is an especially beneficial trait for a format to be used in data interchange between international entities.

@Nanos
Actually, adding units to the datetime components isn't that bad.
2020y-10m-09d reads a bit noisier than 2020-10-09, but it still sorts fine and would indeed ease communication with people from random-component-order countries.
But y, m, and d are SI prefixes but only m is a SI unit - and also the wrong one. So we need some other markers (keep them ASCII for maximum compatibility).
Or just ask them, if they want to add your variant to the set of formats. They already have year-dayOfYear, wich also nobody uses, so maybe you have a chance.

That lightswitch stories are hilarious.
Even if it looks like an automated guessing solution would work reasonably well, a switch is almost always better.

@Nanos
Yes there is hope for the human race.
Only a few countries don't use ISO standards and SI units now.
The remainder might become economically irrelevant in the near future anyways (see trumps trade war and brexit).

Proper driving side obviously is right. Technically both sides would work, but the overwhelming majority drives on the right side.

Power plugs need at least two pins - one more if you need a protective conductor for safety reasons.
But you could make a plug wich is like the Europlug but has a third pin in the middle for the protective conductor. Then the Europlug would even keep being compatible to the new standard.
But i don't know, whether the Europlug format can safely be upgraded to support currents above 2.5 A...
By the way: Grid voltage could be normalized to 240 V, 50Hz sine per phase with three phases delivered to buildings (so you can charge your car at decent speeds if you want to).

@Oktokolo LOL, the economies of most of Europe would die if the USA takes a dive. If not large parts of the world. It is literally a house of cards. Be careful what you wish for.

@Demolishun We don't need the USA anymore because we're already at USB anyway.

@Nanos I worry we are fast tracked to USWTF

@Demolishun
If it happens while the USA is _not_ economically irrelevant yet: Yes.
If USA becomes economically irrelevant first: No.

@Fast-Nop Ultima Online is coded in C++ and its also used with Unreal. It may not be the easiest language to work with but it's still a big player in the industry. At least that my take.