No such thing as C runtime, otherwise it would be impossible to program a kernel in C.
Do you mean that they provide runtime services, and are written in C?
If someone has a kernel providing C++ runtime services (except, of course, for libc) to userspace programs, they're just asking for userspace programs failing to cause kernel panics. C++ runtime should be in userspace.
Hm are you sure I know cython is used for writing c python extensions in python but if you want to use it with pypy you need to use CPyext and that is a python c API emulation.
I thought pypy first runs on another python interpreter then compiles the compiler and jit compiler written in a subset of python called RPython to assembler and then the compiled compiler and jit compiler modules are used to compile / jit compile your python code.
I could be wrong though maybe it transpiles it to C too but what I am pretty sure of is that it does not use cython.
Yeah, some guy named Dennis and some other guy named Ken got hired at Bell Labs and they tasked them with writing UNIX.
C was a tool to add a higher level of abstraction and somewhat Natural Language.
The Boomers take credit for EVERYTHING.
> they tasked them with writing UNIX.
Not exactly. In fact, Bell Labs literally told them not to do any more operating systems after they had pulled out of the Multics project. [Their actual was task was simply to "investigate interesting problems in computer science"](https://www.i-programmer.info/history/people/547-ritchie-a-thompson.html). It was for this reason that Ken Thompson started Unix on an old PDP-7 minicomputer. Bell Labs wasn't going to contribute some fancy setup for them to do that. After that, they moved to a PDP-11, but their proposal for doing Unix was presented under somewhat of a ruse. They said they were just going to do some sort of automation system app for the AT&T patent department. They then turned around, and used the automation system app as an excuse to write an OS for it to run on.
It wasn't until later that AT&T found out that they had an OS, and then started selling licenses for it. Even then, they couldn't sell it to anyone except universities until even later than that due to anti-trust laws, so it's not like they were looking for an OS to be written.
5 years after his birth the Baby Boom began.
Good point though. BUT I feel more kindred spirit with guys born during and after the war, The Boomers, than I do with Millennials.
"Someone"'s name is*Admiral* Grace Murray Hopper, thank you very much, and it's the best kind of laziness that leads you to invent the idea of a compiler to get out of writing assembly language.
Before there was assembly language, there was machine language. John von Neumann didn't understand why you'd want assembly language; weren't the opcodes easy enough to remember already?
This is sort of like asking if slang (like a shorthand phrase for a more complex concept) is “in English” or not - C is an abstraction and a tool for writing assembly which is itself an abstraction for simplifying writing binary instructions - none of them are “more” or “less” abstract tools for writing binary, they just have a different position in the many layers of abstraction that save us from having to write binary machine code and all boil down to the same architecture eventually…
Indeed. The mind boggles.
I am just going to pretend that at the very bottom, there is a magical C compiler that generates machine code directly, to break out of this recursion.
I believe in the dark old days, the first C compilers were a wierd mix of primitive assembler and "C". So it probably wasn't far off.
Assembly is not necessary, nor was it ever necessary for programming language to work. Assembly is an intermediate step between compiling your program into an executable. Some compilers use it, but they don't have to. It's usually easy to understand a program in terms of a particular Assembly language, so, when a program is disassembled, it is presented to the user as an Assembly source code.
You are confused between the generated in this way Assembly code and what the actual program is.
Needless to say that there are plenty of different Assembly languages, even for the same CPU architecture. So, saying that "every programming language is just a wrapper around Assembly" is complete bullshit, because it begs the immediate question: *which Assembly?*
It's amazing how retarded by and large programmers are when it comes to the only thing they are supposed to be experts at. I mean, this is fucking basic, and yet, you are not alone in believing your bullshit. Probably 9 in 10 will believe the same, if not more.
Hell, not every processor works with assembly either! That should be pretty obvious, given the fact that I have designed a processor. Well, it's more of a heating pad.
FYI, assembly is human readable translation of machine code. Every processor runs off some form of machine code, thus, every processor has assembly. Also any programming language just compiles into assembly such as C
I know, but I meant that not every processor probably has C compiler support, meaning the only way to program it is with an assembler for the instruction set.
Hell, I could invent a processor that fits that description.
Processors don’t all just do the same thing described through different instruction sets, modern processors can generally do equivalent things, but c expects certain things to be true of a device that aren’t necessarily true if some old obscure processors. Also statically compiled languages often don’t use platform native assembly and instead use some ir to translate to machine code. Assembly is for humans, not programs to interface with software. (It is worth noting some compilers may use assembly if they only target one architecture and many compiler IRs resemble assembly. Gcc and the go compiler for example)
Except I don't see a cause for celebration: one of the worst technologies programming had came up with unequivocally won. This is like that scene where Palpatine declares the creation of the empire.
Just because a language is used a lot doesn't mean it's good. Rust is a relatively new language and the low level industry it specializes in is slow moving. It will take some time to permiate.
For a embedded language, it's moving pretty fast though. Rust is now used for parts of the Linux kernel, a major testament to it's stability and speed.
20 years into my career and I still stand by the opinion that everyone should understand C, at least in a basic sense. Pretty much every other language is implemented in C, on some level, and if you ever want to do any serious device or embedded development, you're gonna need it. I definitely wouldn't want to write a web page or data science project in it though. Use the tool that's made for the job.
Well, if you insist...
20 yearth intho my career and I sthill sthand by the opinion that everyone should underthand C, at leasth in a bathic thenth. Pretty much every other language ith implemented in C, on thome level, and if you ever want to do any therious device or embedded development, you're gonna need it. I definitely wouldn't want to write a web page or data thience project in it though. Uth the tool thath made for the job.
I once had to endure Guy Steele play [this song](https://www.youtube.com/watch?v=5-OjTPj7K54) at a conference once. I got the impression that as a conference speaker he was a one trick pony for proclaiming the gospel of Lisp.
This comment downplays the importance of getting rid of C. Yes, it's important to understand C *today*. But the reason should be not preservation, but elimination. C should die, if we want to write reliable and robust software, be able to experiment more with different kinds of hardware, be more consistent and transparent in our discussion of how computers work and how to build new ones.
biggest joke of all time. pyscript, without explicit browser support, is literally throwing python back 100 years, back when it was slower than a tied-up crow. It lives from a C backend. If you remove that, even if you can install all the packages SOMEHOW, they would be just interpreted..
It's definitely a cool project, but I don't see it as anything revolutionary.
> "You never know where [the assembler is] going to put things", he explained, "so you'd have to use separate constants".
> It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value.
https://www.cs.utah.edu/~elb/folklore/mel.html
I would say most "toy languages" aren't even languages. They are simply C or C++ programs that read fancy config files and do different things based on what is read.
Systems languages are few and far between unfortunately; Rust and Go are probably the last ones and even then Go was started by the same guys behind C and Bell Labs legacy (they are some cool boomers admittedly).
In some ways I feel our generation has a serious skills shortage when it comes to compiler design and writing very low level code required.
Go is not a system language, unless you want to put every other managed language in that same category. Is python a systems language as well?
And Go is even less a low level language, unless js is as well.
Go is not a managed language. It doesn't need a VM to execute, it generates machine instructions that is executed by the processor directly. cgo (the main implementation), up until a later 1.x revision actually even used a modified version of Ken Thompsons C compiler (for Plan 9, UNIX "successor") to generate the assembly. This legacy is what allows for "pseudo" [direct calling of C code](https://go.dev/blog/cgo) within Go without things like FFI or JNI, etc. Still not on the same level of C++ as a (close) superset of C.
It "does" however have a garbage collector which is what helps it achieve a little more memory safety (at the expense of some portability / manual handling of stack layouts). A little bit like bolting [Boehms GC](https://www.hboehm.info/gc/) onto C.
Go is a "mid-level" language, like Rust. This is a bit of a grey area naturally but what it means in practical terms is that to interact directly with the underlying system, it needs bindings against C (and to a lesser extent, C++) libraries. Naturally this is what brings about language based package managers like NPM, [crates.io](https://crates.io), PIP, CPAN and all that cruft. Golang seems to use i.e GitHub directly as its bindings package manager which seems a bit fragile to me personally.
A tracing garbage collector require a runtime, so Go is absolutely a managed language. Also, VM doesn’t mean what you think it does - Java spends most of its time executing code as machine code the exact same way.
Rust is absolutely a low level language, it has nothing in common with Go. Go is closer to javascript than to rust.
And frankly I have no idea what you are talking about regarding crares. Dependency management is absofuckinglutely has nothing to do with the topic at hand.
>Java spends most of its time executing code as machine code the exact same way.
No it doesn't. The VM (JVM) written in C and C++ generates the machine code. The bytecode emitted from Java (discounting gcj) cannot be run directly by the processor and needs to be i.e JITed. It is a managed language.
Go lang is not a managed language. That is why it has an assembler. If it interests you, read up on: [https://go.dev/doc/asm](https://go.dev/doc/asm)
>require a runtime, so Go is absolutely a managed language
Go has a runtime (as does C and Rust). Doesn't mean its managed. Just like those languages, you can even compile the runtime in statically.
>A tracing garbage collector require a runtime
No, all it would require is extra info compiled in (i.e more than C will generate) such as map of stack frame, offsets of pointers in all functions, datatypes and maps of object layouts. This is all very possible and something that Go is providing.
Again in the assembler [link](https://go.dev/doc/asm):
>*For garbage collection to run correctly, the runtime must know the location of pointers in all global data and in most stack frames. The Go compiler emits this information when compiling Go source files, but assembly programs must define it explicitly.*
And:
>Rust is absolutely a low level language, it has nothing in common with Go. Go is closer to javascript than to rust.
Rust is on par with C++. They are both mid-level languages. They provide access to the raw data (safety aside) but also provide higher level abstractions. But so is Go. Superficially it may "look" a little like Javascript with its async-style approach to things but is completely different in terms of underlying tech. Javascript was traditionally interpreted (like Python) for one.
C is an example of a low level language. Saying Rust is a low level language like C would be incorrect. But I did say it was a gray area; there is no clear cut. Some guys even say that C is a mid-level language because it provides abstractions above data.
>And frankly I have no idea what you are talking about regarding crares
To access the, i.e Linux DRM framebuffer in i.e Rust; you can't do it. You need to go through C, so you need a binding. This is a symptom of a higher level language.
I am using this meaning of “managed”, and accordingly Go is a managed language.
https://softwareengineering.stackexchange.com/questions/164332/managed-languages-vs-compiled-language-difference
I don’t see how your first paragraph is not in line with my quoted sentence. Java byte code gets JIT compiled into machine code and during runtime it will spend *the majority of its execution time as machine code*.
AOT vs JIT is not the differentiator of managed languages - GC is. Haskell also compiles to machine code, but has a GC and is thus regarded as a managed language.
> No, all it would require is extra info (i.e more than C will generate) such as map of stack frame, offsets of pointers in all functions, datatypes and maps of object layouts. This is all very possible and something that go is providing.
And what happens with that extra info? A runtime will have to periodically scan the stack for pointers and mark objects that can still be achieved, sweeping the rest. All done on usually a separate thread *managed* by the runtime.
Static compilation is again a completely separate axis.
C++, Rust and C are all on the exact same level. There are no agreed upon definition of low-level PLs (traditionally it means assembly, so according to that even C is a high level language). A way I see it used often is in line with what can be expressed in the language. The above mentioned languages provide fine-tuned control over memory allocation and deallocation, while managed languages like Go, Haskell, Java, etc don’t generally. Go and C# does have pointers and value types which let’s one tweak a bit more, but they are still generally thought of as high-level languages.
In a way, Rust and C++ are actually lower level than C, since they have native support for SIMD instructions as well, allowing more control over the execution. C can only do it with inline assembly which is not considered the language.
The only reason C is *required* for DRM is because the linux kernel is written in C and thus the interfaces are described in the form of C FFI. There is nothing inherent to C here, hell, two Rust programs can expose a C-like external interface just fine *without any contribution from C*. Or alternatively one could come up with a new agreed upon format like protobuf or whatever.
(my reddit buggered up, hope I didn't spam you too much!)
>and during runtime it will spend the majority of its execution time as machine code.
Mainly because the Java didn't turn it into the machine code being executed. The C++ did (as part of the VM). The VM is "managing" the program.
>AOT vs JIT is not the differentiator of managed languages - GC is
I strongly disagree with that. If you add Boehm's GC to C or C++ it doesn't make it a managed language.
So many [links](https://en.wikipedia.org/wiki/Managed_code) are dead from the days where managed languages were cool but the general idea is a language is managed if it
>requires and will execute only under the management of a Common Language Infrastructure (CLI); Virtual Execution System (VES); virtual machine, e.g. .NET, Core
FX, or .NET Framework; Common Language Runtime (CLR); or Mono. The term was coined by Microsoft.
So this is the Java JVMs, the .NET Mono, Limbo Dis, etc.
>All done on usually a separate thread managed by the runtime
Absolutely managed by the runtime. In the same way that Rust and C++'s runtimes will manage garbage collection.
https://isocpp.org/wiki/faq/cpp11-library#gc-abi
C++ actually has a primitive garbage collection API. It is just rarely used. Again, this does not define whether a language is managed or not.
>The above mentioned languages provide fine-tuned control over memory allocation and deallocation
C++ and Rust don't particularly lend themselves to fine-tuned control of memory. For one, memory management should be automatic if correct RAII is utilised. The difference is that C++ makes it easier for direct memory access unlike Rust. Chucking in a GC does make this problematic in that you need to "pin" memory down during access but that is a complexity rather than a high/low level kind of thing.
>In a way, Rust and C++ are actually lower level than C, since they have native support for SIMD instructions as well
Rust and C++ provide a "high level" interface to SIMD / AVX. Those go down a considerable rabbit hole.
Also, is SIMD even part of the C++ standard? I believe it is only vendor extensions (a bit like OpenMP).
(No problem, you didn’t spam me)
Well VM = runtime manages the problem. But it is not an important distinction I would say.
Boehm’s GC is a good point, it definitely blurry the picture a bit, though it is a conservative GC only.
I would consider it to be managed. As you pointed out previously, correctly, we are talking about implementations, not languages. Boehm’s GCd C is not regular old C.
As far as I know there is no implementation for C++’s GC apis.
I’m sorry, but how on Earth does rust and C++ not lend themselves for fine-tuned memory control?
>I’m sorry, but how on Earth does rust and C++ not lend themselves for fine-tuned memory control?
When you create and use an `std::vector` do you know how much memory it has allocated? Maybe so but if you then resize it to 999 elements, you will not end up with an additional `sizeof(int) * 999` bytes allocated. Likewise if you resize it again back to 0, is the memory reclaimed? It is protected from you, you don't know, it is implementation dependent (you can write a custom std::allocator) but you could arguably do that in Python (many guys also drag in numpy as a dependency to do so).
C operates on blocks of memory, not objects. Whereas, if you find yourself in C++ manually managing blocks of memory or allocations via new or delete or even raw arrays new\[\], delete\[\], you are probably doing something wrong.
That’s expressivity of the language, not low- or high-levelness.
C++ and Rust allows for proper abstractions, while C doesn’t. For example, look at C strings - they are slow and error prone, because you can’t create a proper data structure from it. While in case of c++, the stdlib’s string implementation can do something called small string optimizations - for small enough strings, it will be allocated in-place, while for larger ones it will be the usual size+pointer to data. This is all cleverly encoded in the pointer. C can’t do that, as then you would have to call this “abstraction” at every single *use*-site.
Also, vectors are ridiculously fast as well as they are very productive. You know what is the equivalent to them in C? God damn linked list with abysmal performance, again, due to lack of expressivity of the language.
It is no accident that for serious performant-oriented workloads C++ is used most often in the industry. (Also, while new[] and the like are seldom used, it has std::array for more than a decade now, which is both safe and fast)
(@Muoniurn for some reason reddit didn't let me reply directly to your post)
>and during runtime it will spend the majority of its execution time as machine code.
Mainly because the Java didn't turn it into the machine code being executed. The C++ did (as part of the VM). The VM is "managing" the program.
>AOT vs JIT is not the differentiator of managed languages - GC is
I strongly diagree with that. If you add Boehm's GC to C or C++ it doesn't make it a managed language.
So many [links](https://en.wikipedia.org/wiki/Managed_code) are dead from the days where managed languages were cool but the general idea is a language is managed if it
>requires and will execute only under the management of a Common Language Infrastructure (CLI); Virtual Execution System (VES); virtual machine, e.g. .NET, CoreFX, or .NET Framework; Common Language Runtime (CLR); or Mono. The term was coined by Microsoft.
So this is the Java JVMs, the .NET Mono, Limbo Dis, etc.
>All done on usually a separate thread managed by the runtime
Absolutely managed by the runtime. In the same way that Rust and C++'s runtimes manage gabage collection.
https://isocpp.org/wiki/faq/cpp11-library#gc-abi
C++ actually has a primitive garbage collection API. It is just rarely used. Again, this does not define whether a language is managed or not.
>The above mentioned languages provide fine-tuned control over memory allocation and deallocation
C++ and Rust don't particularly lend themselves to fine-tuned control of memory. For one, memory management should be automatic if correct RAII is utilised. Again C++ just makes it easier to access directly vs both Go and Rust.
>In a way, Rust and C++ are actually lower level than C, since they have native support for SIMD instructions as well
It isn't a standard part of the C++ API. It is a vendor extension in many cases. But in both cases, Rust and C++ provide a "high level" interface to SIMD / AVX.
I know it's not true, but Macs do feel like toys in my mind. Never used one, but I can't help but imagine it's just a computer version of iPhone (read: restrictive, closed, meant for being easy to use)
I am finding no obvious matches for those initialisms and have no idea what you're referring to. Not that I expect it to matter, but I thought I should throw an exception at you.
Bloody kids, running around the place, claiming python is the best and not understanding the first thing about low-level coding. Go get your nappy changed and have a cup of warm milk.
Etc.......
When I was younger, I used to say things like Python is stupid because it is slow.
Now I am older and perhaps wiser. Now I think C is just there because some lazy ass of a person cannot comprehend binary and work with op codes.
I write MY hello world programs the way Alan Turing intended!
01001000011001010110110001101100011011110010110000100000010101110110111101110010011011000110010000100001
Every programming language is just a thinner or thicker wrapper around Assembly. It all started because someone in the late 50's was lazy.
And many of them are wrappers around C
Modern operating system kernels are pretty much C runtime environments.
No such thing as C runtime, otherwise it would be impossible to program a kernel in C. Do you mean that they provide runtime services, and are written in C?
Kernel provides high level features for c++ programs I guess
If someone has a kernel providing C++ runtime services (except, of course, for libc) to userspace programs, they're just asking for userspace programs failing to cause kernel panics. C++ runtime should be in userspace.
Like Python is written in C.
Python is to C what ChromeOS is to Linux
>ChromeOS is to Linux You mean any everyday Linux distro is to Linux kernel?
https://www.python.org/download/alternatives/ The pure python implementation of python is faster than the c version.
Irrelevant.
Pypy isn't really pure python though, it's python transpiled to C using Cython
Hm are you sure I know cython is used for writing c python extensions in python but if you want to use it with pypy you need to use CPyext and that is a python c API emulation. I thought pypy first runs on another python interpreter then compiles the compiler and jit compiler written in a subset of python called RPython to assembler and then the compiled compiler and jit compiler modules are used to compile / jit compile your python code. I could be wrong though maybe it transpiles it to C too but what I am pretty sure of is that it does not use cython.
Maybe, I'm sure it complies to C
PyPy will also use JIT compilation, which will convert Python code directly into machine code & avoid interpreter overhead.
Thank goodness for laziness
Yeah, some guy named Dennis and some other guy named Ken got hired at Bell Labs and they tasked them with writing UNIX. C was a tool to add a higher level of abstraction and somewhat Natural Language. The Boomers take credit for EVERYTHING.
RIP Bell Labs I’m sure that Schon would have eventually gotten those carbon transistors working eventually /s
Clearly you’re just bad if you can’t replicate my experiment result /s
> they tasked them with writing UNIX. Not exactly. In fact, Bell Labs literally told them not to do any more operating systems after they had pulled out of the Multics project. [Their actual was task was simply to "investigate interesting problems in computer science"](https://www.i-programmer.info/history/people/547-ritchie-a-thompson.html). It was for this reason that Ken Thompson started Unix on an old PDP-7 minicomputer. Bell Labs wasn't going to contribute some fancy setup for them to do that. After that, they moved to a PDP-11, but their proposal for doing Unix was presented under somewhat of a ruse. They said they were just going to do some sort of automation system app for the AT&T patent department. They then turned around, and used the automation system app as an excuse to write an OS for it to run on. It wasn't until later that AT&T found out that they had an OS, and then started selling licenses for it. Even then, they couldn't sell it to anyone except universities until even later than that due to anti-trust laws, so it's not like they were looking for an OS to be written.
Ritchie was also involved with the development of the Plan 9 and Inferno operating systems, and the programming language Limbo.
Indeed. Also, Thompson was involved with Golang. Good stuff.
Ken Thompson and Dennis Ritchie both pre-date the boomers.
5 years after his birth the Baby Boom began. Good point though. BUT I feel more kindred spirit with guys born during and after the war, The Boomers, than I do with Millennials.
"Someone"'s name is*Admiral* Grace Murray Hopper, thank you very much, and it's the best kind of laziness that leads you to invent the idea of a compiler to get out of writing assembly language. Before there was assembly language, there was machine language. John von Neumann didn't understand why you'd want assembly language; weren't the opcodes easy enough to remember already?
To an extent. Most assemblers are also written in C (or C++)
The snake has bitten its tail.
Well, technically the truth. The Assembler is written in C especially for the user I/O. It still complies to Machine Code.
Use C to create a compiler for C, so you can compile C in a compiler that was written in C.
Be careful, you could create a compiler bootstrap paradox
humans are just bootstraps for AI
Is that where cross compilation comes in?
This is sort of like asking if slang (like a shorthand phrase for a more complex concept) is “in English” or not - C is an abstraction and a tool for writing assembly which is itself an abstraction for simplifying writing binary instructions - none of them are “more” or “less” abstract tools for writing binary, they just have a different position in the many layers of abstraction that save us from having to write binary machine code and all boil down to the same architecture eventually…
But the C code from the compiler assembles other code into assembly. So more like the C code builds the wrapper but the C code is not the wrapper
Indeed. The mind boggles. I am just going to pretend that at the very bottom, there is a magical C compiler that generates machine code directly, to break out of this recursion. I believe in the dark old days, the first C compilers were a wierd mix of primitive assembler and "C". So it probably wasn't far off.
Machine code
Just as assembly itself is a thin wrapper around CPU opcodes..
Lazy people are best.
Assembly is not necessary, nor was it ever necessary for programming language to work. Assembly is an intermediate step between compiling your program into an executable. Some compilers use it, but they don't have to. It's usually easy to understand a program in terms of a particular Assembly language, so, when a program is disassembled, it is presented to the user as an Assembly source code. You are confused between the generated in this way Assembly code and what the actual program is. Needless to say that there are plenty of different Assembly languages, even for the same CPU architecture. So, saying that "every programming language is just a wrapper around Assembly" is complete bullshit, because it begs the immediate question: *which Assembly?* It's amazing how retarded by and large programmers are when it comes to the only thing they are supposed to be experts at. I mean, this is fucking basic, and yet, you are not alone in believing your bullshit. Probably 9 in 10 will believe the same, if not more.
Every other language has lost. There is a C compiler for every single processor out there.
Because why fix what works. Claiming "every processor" seems a bit of a stretch though, some probably require assembly.
Hell, not every processor works with assembly either! That should be pretty obvious, given the fact that I have designed a processor. Well, it's more of a heating pad.
FYI, assembly is human readable translation of machine code. Every processor runs off some form of machine code, thus, every processor has assembly. Also any programming language just compiles into assembly such as C
I know, but I meant that not every processor probably has C compiler support, meaning the only way to program it is with an assembler for the instruction set. Hell, I could invent a processor that fits that description.
Processors don’t all just do the same thing described through different instruction sets, modern processors can generally do equivalent things, but c expects certain things to be true of a device that aren’t necessarily true if some old obscure processors. Also statically compiled languages often don’t use platform native assembly and instead use some ir to translate to machine code. Assembly is for humans, not programs to interface with software. (It is worth noting some compilers may use assembly if they only target one architecture and many compiler IRs resemble assembly. Gcc and the go compiler for example)
Except I don't see a cause for celebration: one of the worst technologies programming had came up with unequivocally won. This is like that scene where Palpatine declares the creation of the empire.
Sh, the crustaceans might hear you
*rustaceans
I've seen Forth, Cobol, and Fortran in the wild more than rust.
Just because a language is used a lot doesn't mean it's good. Rust is a relatively new language and the low level industry it specializes in is slow moving. It will take some time to permiate. For a embedded language, it's moving pretty fast though. Rust is now used for parts of the Linux kernel, a major testament to it's stability and speed.
Rust is better than C because C set an abnormally low bar for itself.
I do hope it takes off
20 years into my career and I still stand by the opinion that everyone should understand C, at least in a basic sense. Pretty much every other language is implemented in C, on some level, and if you ever want to do any serious device or embedded development, you're gonna need it. I definitely wouldn't want to write a web page or data science project in it though. Use the tool that's made for the job.
Lisp. Just lisp.
Well, if you insist... 20 yearth intho my career and I sthill sthand by the opinion that everyone should underthand C, at leasth in a bathic thenth. Pretty much every other language ith implemented in C, on thome level, and if you ever want to do any therious device or embedded development, you're gonna need it. I definitely wouldn't want to write a web page or data thience project in it though. Uth the tool thath made for the job.
C should just be Thí lol
I once had to endure Guy Steele play [this song](https://www.youtube.com/watch?v=5-OjTPj7K54) at a conference once. I got the impression that as a conference speaker he was a one trick pony for proclaiming the gospel of Lisp.
Nothing beats an anemic ecosystem with a shallow developer pool and a horrific syntax.
How to anaphoric macro in C
Which Lisp?
Is C++ good enough?
Its C with added features
C with classes! And everything else under the sun
This comment downplays the importance of getting rid of C. Yes, it's important to understand C *today*. But the reason should be not preservation, but elimination. C should die, if we want to write reliable and robust software, be able to experiment more with different kinds of hardware, be more consistent and transparent in our discussion of how computers work and how to build new ones.
Tell me you don't know the UNIX Philosophy without telling me you don't know the UNIX Philosophy
We should have a program that literally does everything in the world! We'll call it...the Master Program!
this also violates the UNIX Philosophy lol
python is just good shellscript
I mean it is a scripting language no one claimed otherwise (or at least I hope not)
there are lots of people "developing" multi-10k-loc projects in python. i would rather not code at all
Or worse there a poor souls somewhere making a website with pyscript
biggest joke of all time. pyscript, without explicit browser support, is literally throwing python back 100 years, back when it was slower than a tied-up crow. It lives from a C backend. If you remove that, even if you can install all the packages SOMEHOW, they would be just interpreted.. It's definitely a cool project, but I don't see it as anything revolutionary.
You have one too many "good" in your comment. Otherwise, yeah.
I think it is good shellscript. But nothing more.
> "You never know where [the assembler is] going to put things", he explained, "so you'd have to use separate constants". > It was a long time before I understood that remark. Since Mel knew the numerical value of every operation code, and assigned his own drum addresses, every instruction he wrote could also be considered a numerical constant. He could pick up an earlier "add" instruction, say, and multiply by it, if it had the right numeric value. https://www.cs.utah.edu/~elb/folklore/mel.html
Both my grandpas programmed back in the punch-holes in paper strips/cards days
I'm 15 and solely use C
Good lad
Flair checks out
Raised right
Average zoomer: ah, python, the language that will last and be popular forever! One day all operating systems will be made from this!
I would say most "toy languages" aren't even languages. They are simply C or C++ programs that read fancy config files and do different things based on what is read. Systems languages are few and far between unfortunately; Rust and Go are probably the last ones and even then Go was started by the same guys behind C and Bell Labs legacy (they are some cool boomers admittedly). In some ways I feel our generation has a serious skills shortage when it comes to compiler design and writing very low level code required.
Fancy config files. Yeah ok that's one way to call it. And you aren't wrong since config files are often programs in their own right.
It's more of a, why fix what isn't broken situation.
This
Can I have some examples of toy languages?
Go is not a system language, unless you want to put every other managed language in that same category. Is python a systems language as well? And Go is even less a low level language, unless js is as well.
Go is not a managed language. It doesn't need a VM to execute, it generates machine instructions that is executed by the processor directly. cgo (the main implementation), up until a later 1.x revision actually even used a modified version of Ken Thompsons C compiler (for Plan 9, UNIX "successor") to generate the assembly. This legacy is what allows for "pseudo" [direct calling of C code](https://go.dev/blog/cgo) within Go without things like FFI or JNI, etc. Still not on the same level of C++ as a (close) superset of C. It "does" however have a garbage collector which is what helps it achieve a little more memory safety (at the expense of some portability / manual handling of stack layouts). A little bit like bolting [Boehms GC](https://www.hboehm.info/gc/) onto C. Go is a "mid-level" language, like Rust. This is a bit of a grey area naturally but what it means in practical terms is that to interact directly with the underlying system, it needs bindings against C (and to a lesser extent, C++) libraries. Naturally this is what brings about language based package managers like NPM, [crates.io](https://crates.io), PIP, CPAN and all that cruft. Golang seems to use i.e GitHub directly as its bindings package manager which seems a bit fragile to me personally.
A tracing garbage collector require a runtime, so Go is absolutely a managed language. Also, VM doesn’t mean what you think it does - Java spends most of its time executing code as machine code the exact same way. Rust is absolutely a low level language, it has nothing in common with Go. Go is closer to javascript than to rust. And frankly I have no idea what you are talking about regarding crares. Dependency management is absofuckinglutely has nothing to do with the topic at hand.
>Java spends most of its time executing code as machine code the exact same way. No it doesn't. The VM (JVM) written in C and C++ generates the machine code. The bytecode emitted from Java (discounting gcj) cannot be run directly by the processor and needs to be i.e JITed. It is a managed language. Go lang is not a managed language. That is why it has an assembler. If it interests you, read up on: [https://go.dev/doc/asm](https://go.dev/doc/asm) >require a runtime, so Go is absolutely a managed language Go has a runtime (as does C and Rust). Doesn't mean its managed. Just like those languages, you can even compile the runtime in statically. >A tracing garbage collector require a runtime No, all it would require is extra info compiled in (i.e more than C will generate) such as map of stack frame, offsets of pointers in all functions, datatypes and maps of object layouts. This is all very possible and something that Go is providing. Again in the assembler [link](https://go.dev/doc/asm): >*For garbage collection to run correctly, the runtime must know the location of pointers in all global data and in most stack frames. The Go compiler emits this information when compiling Go source files, but assembly programs must define it explicitly.* And: >Rust is absolutely a low level language, it has nothing in common with Go. Go is closer to javascript than to rust. Rust is on par with C++. They are both mid-level languages. They provide access to the raw data (safety aside) but also provide higher level abstractions. But so is Go. Superficially it may "look" a little like Javascript with its async-style approach to things but is completely different in terms of underlying tech. Javascript was traditionally interpreted (like Python) for one. C is an example of a low level language. Saying Rust is a low level language like C would be incorrect. But I did say it was a gray area; there is no clear cut. Some guys even say that C is a mid-level language because it provides abstractions above data. >And frankly I have no idea what you are talking about regarding crares To access the, i.e Linux DRM framebuffer in i.e Rust; you can't do it. You need to go through C, so you need a binding. This is a symptom of a higher level language.
I am using this meaning of “managed”, and accordingly Go is a managed language. https://softwareengineering.stackexchange.com/questions/164332/managed-languages-vs-compiled-language-difference I don’t see how your first paragraph is not in line with my quoted sentence. Java byte code gets JIT compiled into machine code and during runtime it will spend *the majority of its execution time as machine code*. AOT vs JIT is not the differentiator of managed languages - GC is. Haskell also compiles to machine code, but has a GC and is thus regarded as a managed language. > No, all it would require is extra info (i.e more than C will generate) such as map of stack frame, offsets of pointers in all functions, datatypes and maps of object layouts. This is all very possible and something that go is providing. And what happens with that extra info? A runtime will have to periodically scan the stack for pointers and mark objects that can still be achieved, sweeping the rest. All done on usually a separate thread *managed* by the runtime. Static compilation is again a completely separate axis. C++, Rust and C are all on the exact same level. There are no agreed upon definition of low-level PLs (traditionally it means assembly, so according to that even C is a high level language). A way I see it used often is in line with what can be expressed in the language. The above mentioned languages provide fine-tuned control over memory allocation and deallocation, while managed languages like Go, Haskell, Java, etc don’t generally. Go and C# does have pointers and value types which let’s one tweak a bit more, but they are still generally thought of as high-level languages. In a way, Rust and C++ are actually lower level than C, since they have native support for SIMD instructions as well, allowing more control over the execution. C can only do it with inline assembly which is not considered the language. The only reason C is *required* for DRM is because the linux kernel is written in C and thus the interfaces are described in the form of C FFI. There is nothing inherent to C here, hell, two Rust programs can expose a C-like external interface just fine *without any contribution from C*. Or alternatively one could come up with a new agreed upon format like protobuf or whatever.
(my reddit buggered up, hope I didn't spam you too much!) >and during runtime it will spend the majority of its execution time as machine code. Mainly because the Java didn't turn it into the machine code being executed. The C++ did (as part of the VM). The VM is "managing" the program. >AOT vs JIT is not the differentiator of managed languages - GC is I strongly disagree with that. If you add Boehm's GC to C or C++ it doesn't make it a managed language. So many [links](https://en.wikipedia.org/wiki/Managed_code) are dead from the days where managed languages were cool but the general idea is a language is managed if it >requires and will execute only under the management of a Common Language Infrastructure (CLI); Virtual Execution System (VES); virtual machine, e.g. .NET, Core FX, or .NET Framework; Common Language Runtime (CLR); or Mono. The term was coined by Microsoft. So this is the Java JVMs, the .NET Mono, Limbo Dis, etc. >All done on usually a separate thread managed by the runtime Absolutely managed by the runtime. In the same way that Rust and C++'s runtimes will manage garbage collection. https://isocpp.org/wiki/faq/cpp11-library#gc-abi C++ actually has a primitive garbage collection API. It is just rarely used. Again, this does not define whether a language is managed or not. >The above mentioned languages provide fine-tuned control over memory allocation and deallocation C++ and Rust don't particularly lend themselves to fine-tuned control of memory. For one, memory management should be automatic if correct RAII is utilised. The difference is that C++ makes it easier for direct memory access unlike Rust. Chucking in a GC does make this problematic in that you need to "pin" memory down during access but that is a complexity rather than a high/low level kind of thing. >In a way, Rust and C++ are actually lower level than C, since they have native support for SIMD instructions as well Rust and C++ provide a "high level" interface to SIMD / AVX. Those go down a considerable rabbit hole. Also, is SIMD even part of the C++ standard? I believe it is only vendor extensions (a bit like OpenMP).
(No problem, you didn’t spam me) Well VM = runtime manages the problem. But it is not an important distinction I would say. Boehm’s GC is a good point, it definitely blurry the picture a bit, though it is a conservative GC only. I would consider it to be managed. As you pointed out previously, correctly, we are talking about implementations, not languages. Boehm’s GCd C is not regular old C. As far as I know there is no implementation for C++’s GC apis. I’m sorry, but how on Earth does rust and C++ not lend themselves for fine-tuned memory control?
>I’m sorry, but how on Earth does rust and C++ not lend themselves for fine-tuned memory control? When you create and use an `std::vector` do you know how much memory it has allocated? Maybe so but if you then resize it to 999 elements, you will not end up with an additional `sizeof(int) * 999` bytes allocated. Likewise if you resize it again back to 0, is the memory reclaimed? It is protected from you, you don't know, it is implementation dependent (you can write a custom std::allocator) but you could arguably do that in Python (many guys also drag in numpy as a dependency to do so).
C operates on blocks of memory, not objects. Whereas, if you find yourself in C++ manually managing blocks of memory or allocations via new or delete or even raw arrays new\[\], delete\[\], you are probably doing something wrong.
That’s expressivity of the language, not low- or high-levelness. C++ and Rust allows for proper abstractions, while C doesn’t. For example, look at C strings - they are slow and error prone, because you can’t create a proper data structure from it. While in case of c++, the stdlib’s string implementation can do something called small string optimizations - for small enough strings, it will be allocated in-place, while for larger ones it will be the usual size+pointer to data. This is all cleverly encoded in the pointer. C can’t do that, as then you would have to call this “abstraction” at every single *use*-site. Also, vectors are ridiculously fast as well as they are very productive. You know what is the equivalent to them in C? God damn linked list with abysmal performance, again, due to lack of expressivity of the language. It is no accident that for serious performant-oriented workloads C++ is used most often in the industry. (Also, while new[] and the like are seldom used, it has std::array for more than a decade now, which is both safe and fast)
(@Muoniurn for some reason reddit didn't let me reply directly to your post) >and during runtime it will spend the majority of its execution time as machine code. Mainly because the Java didn't turn it into the machine code being executed. The C++ did (as part of the VM). The VM is "managing" the program. >AOT vs JIT is not the differentiator of managed languages - GC is I strongly diagree with that. If you add Boehm's GC to C or C++ it doesn't make it a managed language. So many [links](https://en.wikipedia.org/wiki/Managed_code) are dead from the days where managed languages were cool but the general idea is a language is managed if it >requires and will execute only under the management of a Common Language Infrastructure (CLI); Virtual Execution System (VES); virtual machine, e.g. .NET, CoreFX, or .NET Framework; Common Language Runtime (CLR); or Mono. The term was coined by Microsoft. So this is the Java JVMs, the .NET Mono, Limbo Dis, etc. >All done on usually a separate thread managed by the runtime Absolutely managed by the runtime. In the same way that Rust and C++'s runtimes manage gabage collection. https://isocpp.org/wiki/faq/cpp11-library#gc-abi C++ actually has a primitive garbage collection API. It is just rarely used. Again, this does not define whether a language is managed or not. >The above mentioned languages provide fine-tuned control over memory allocation and deallocation C++ and Rust don't particularly lend themselves to fine-tuned control of memory. For one, memory management should be automatic if correct RAII is utilised. Again C++ just makes it easier to access directly vs both Go and Rust. >In a way, Rust and C++ are actually lower level than C, since they have native support for SIMD instructions as well It isn't a standard part of the C++ API. It is a vendor extension in many cases. But in both cases, Rust and C++ provide a "high level" interface to SIMD / AVX.
Me, 17yo:
Me, but also rust lol
Boomer called my MacBookPro a toy once. This was before Windows had Linux Sub System. -edit abbreviations-
I know it's not true, but Macs do feel like toys in my mind. Never used one, but I can't help but imagine it's just a computer version of iPhone (read: restrictive, closed, meant for being easy to use)
I am finding no obvious matches for those initialisms and have no idea what you're referring to. Not that I expect it to matter, but I thought I should throw an exception at you.
MacBook Pro, Linux SubSubsystem?
Never seen Windows Subsystem for Linux be initialized like that, I’ve always used WSL.
Same lol that was just my best guess based on the context 😅
C is for latte drinkers, the real programmer uses cobalt or Fortran
COBOL is KING 🤴🏻
There are no toy languages, only toy programmers.
Your favorite language is written in C or Java, hippie
Bloody kids, running around the place, claiming python is the best and not understanding the first thing about low-level coding. Go get your nappy changed and have a cup of warm milk. Etc.......
so op lives his/her toy languages. 🤔🤭
When I was younger, I used to say things like Python is stupid because it is slow. Now I am older and perhaps wiser. Now I think C is just there because some lazy ass of a person cannot comprehend binary and work with op codes.
I write MY hello world programs the way Alan Turing intended! 01001000011001010110110001101100011011110010110000100000010101110110111101110010011011000110010000100001
OK, Zoomer.
The truth.
\*inhales\* OK BOOMER
Cringe.
“All platforms are built in C, how can it not be cross platform?”