Thread 105839709

Please someone explain to me why some new typed languages are declaring variables by putting the data type after the name of the variable?

I've only heard reasoning that the variable name is more important than the type (not true) and that the conversion from JavaScript to TypeScript is easier for AI (not true either) and that it's better for visual representation for humans. None of this makes any sense to me.

In C/C++ we often use separate header files to list declarations, which could then be shared among different files. The name of the variable is most certainly not the most important thing there. Consider:
char sex;
int phone;
double height, weight;


versus
let height:double
let phone:int
let sex:char
let weight:double


It's pretty clear the latter is meant for script kiddies who learned to program with JavaScript, as for them everything is automatically a string/object. Commonly also used in Bash scripts.

As for real programmers, types matter the most. It's how computers actually work. You store types in memory. Back in the day when memory was limited (and still is in embedded devices), you would actually need to calculate the memory, e.g.
char is 1 byte
int is 4 bytes
long is 8 bytes
double is 8 bytes
And thus you would know that int can take 4 chars, long can take 8. So if you needed to store a letter with say, a newline character, you'd know you have to use int rather than char.

And the bottom line is, I don't think there was a reason to change from the C/C++/Java/C# style other than edgelords who wanted to be different. There's like a ton of actual reasons why the C style is superior.

And let me just add this, how we would do it in C++

private:
char a, b, c, d;
int e, f, g, h;
double i, j, k, l;
public:
string x, y;


Now compare having to write private or public on every line, on top of having to write the name of the variable on a new line separately:
private a:char
private b:char
private c:char
private d:char
private e:int
private f:int
private g:int
private h:int
private i:double
private j:double
private k:double
private l:double
public x:string
public y:string


This does not improve readability, security, or any other excuse.

all i know is i hate "let"

>>105839709 (OP)
I don't mind using either :)

because "types" were hacked into js after the fact

>>105839709 (OP)
var and let is an useless keyword
we know the declaration is declaration
the only thing that makes sense are modifiers like const/static

>>105839920
We could shorten that to “pub” …would that help?

>>105839709 (OP)
the reason is that it's easier to parse complex types because you don't need to go back and forth

>>105839709 (OP)
they have this insane theory that its okay to have type names that arent just one word

>>105840516
Even if this was true (it's not), you decide that because of one type (complex) we should make all types follow the weird syntax? In fact, objects and structs are capable of returning complex numbers
double squared(double d)
{
double a, b, result;
a = d;
b = d;
result = a * b;

return result;
// and of course you could just write, return d * d;
}


Even with the actual complex type, C++ has always used the C style syntax of having the type name before the variable name. Look it up. In C++ the declaration goes as follows:
double complex comp1;


Maybe I misuderstood something here, but then again the message didn't make much sense.

for structs and classes:
class Squared
{
double a, b;

public:
Squared(double first, double second)
{
a = first;
b = second;
}

double retval { return a * b; }
};


In a way Squared holds two double values making it kinda like a complex number.
You can even put any function in the class other than retval.
None of this requires putting the type after the variable name, fr.

>>105839709 (OP)
Because the developers are honestly retarded and don't understand how adjectives work.

>>105839709 (OP)
Things go in circles, this new way with the type after is how you did things in Visual Basic. It was seen as bad at the time and now we are going back to doing that again.

Neither is superior, provided both are equally expressive, they just have different conveniences. Prefix style allows using the same type specifier across multiple identifiers in the same statement, whereas suffix style reduces headaches with certain convoluted expressions.

>char is 1 byte
Depends on what you define "byte" to be.
>int is 4 bytes
>long is 8 bytes
>double is 8 bytes
Implementation details, not safe to portably assume.

>>105840426
I hate most "modern" languages because of this ugly abbreviations everywher.

>>105839709 (OP)
With good type inferance you don't really need to annotate types

>>105841191
>suffix style reduces headaches with certain convoluted expressions
Give some examples.

>Depends on what you define "byte" to be
Pretty sure it's almost universally defined to be 8 bits.

>Implementation details, not safe to portably assume.
Yes, I just gave it as an example. But it's about valid with most 64-bit Linux, Mac and Windows machines. For compatibility reasons int is still 4 bytes and not 8.

>>105839709 (OP)
>>105839920
you're making disingenuous counter-examples. why do you make the assumption that name:type has to have some noise keyword like "let" in front of it? also why do you assume that name:type cannot have multiple variables declared to the same type like type:name syntax does?

sex : char;
phone : integer;
height, weight : double;

additional keywords like public/private could be on the same side as the type:
a, b, c, d : private char;
e, f, g, h: private int;
i, j, k, l : private double;
x, y : public string;

looks fine to me

>>105839920
>This does not improve readability, security, or any other excuse.
The indentation from the C++ way does hurt readability, I prefer the second even if it is a bit redundant.

>>105841334
True, but the still multiple publics. Also it look ugly

>>105841344
What?

>>105841191
>Implementation details, not safe to portably assume.
#include and use those if you have bitsize requirements. my embedded code is exclusively using those types except where interfacing 3rd party code
float/double are 4/8 byte. if not you're targetting something where this will be least of your concerns, and where you probably want to avoid floating point math at all costs due to lack of FPU
>long
i havent seen that being used in any piece of code written since the first AMD64 cpus were released

>>105841376
>THIS DOES NOT IMPROVE READABILITY, SECURITY, OR ANY OTHER EXCUSE.
THE INDENTATION FROM THE C++ WAY DOES HURT READABILITY, I PREFER THE SECOND EVEN IF IT IS A BIT REDUNDANT.

>>105841363
>multiple publics
then have it be
private
a, b, c, d : char;
e, f, g, h : int;
i, j, k, l : double;
public
x, y : string;

Pascal does that kind of thing with var and const

also on the topic Pascal, I like its way of returning a value from a function by assigning a value to the function's name instead of "return "
function Add(a, b: integer): integer;
begin
Add := a + b;
end;
though I believe "function" keyword is unnecessary, could be implicit from the "name([params]):type" syntax
also "begin" and "end" are a bit too verbose, braces are more convenient as well as conventional

>>105841426
in js this is just const add = (a,b) => a + b

>>105841376
>>105841424

This guy is like my coworker who claims XML is easier to read than TOML.
Who knows what goes in that mind... Perhaps paragraphs and punctuation also get in the way.

>>105841473
I think I am. XML is great

>>105841473
after 30 seconds of looking up what TOML looks like, I'm inclined to agree with your coworker
XML might be verbose and boiler-platy but it's really simpler
TOML looks deceptive - why would something that looks like a .ini or .properties file have multi-line strings? or its own syntax for defining numeric values? what if I have some specific data that I don't want parsed the way TOML defines it?

>>105841473
TOML is just ini with a meme name. Most of the software world is going in circles

>>105841473
TOML is nice until you need to have arrays of tables.

>>105841313
>Give some examples.
void (*(*name)[])()

In C-style, this declares "name" as a pointer to an array of unspecified size of pointer(s) to functions taking unspecified argument(s) and returning nothing. Assuming I remember the unary precedence correctly, which is another salient point.
name::Ref{AbstractArray{Ref{Function}}}

In Julia-style, declares name as a reference to an array of unspecified size of references to functions taking unspecified argument(s). Julia's Function type does not allow specifying arguments or return type(s) due to certain language design restrictions.

>Pretty sure it's almost universally defined to be 8 bits.
The abstract C machine does not adhere to that assumption. sizeof(char) == 1 will always hold, by definition, but you must query CHAR_BIT and adhere to whatever the implementation provides.

>>105841381
I do concur on , which is retrospectively how it always should have been done but alas. On the other hand, float is allowed to alias double if memory serves me right. I do not recall many (if any) systems doing so, but it is absolutely legal.

>>105841344
Intendation is not forced by C/C++ and you could easily write the code without it. There are some newer programming languages where this is not possible due to the fact that semicolons are omitted.

>>105841334
In C/C++ we put declarations in separate header files as they could be shared between many program files. And the way we usually do it is by putting the types in order, usually primitive types go before typedefs, structs and classes. For real programmers it makes it easier to count how much memory your program will take. It's the same for classes, easy to count how much memory the class will take.

In your example you put simple letters like I did, but in real world applications those variable names are very long and include many underscores, e.g.
number_of_apples_and_oranges_seen_so_far, number_of_bananas_and_pears_seen_so_far, number_of_tomatoes_and_potatoes_seen_so_far, etc... : int
// next one will be short
sex:char


Compare with
char sex;
char letter;
int phone;
int number_of_apples_and_oranges_seen_so_far, number_of_bananas_and_pears_seen_so_far, number_of_tomatoes_and_potatoes_seen_so_far, etc..
double floating_point_x;
double floating_point_y;


And as some have already said, the suffix syntax of type declaration was used before C and it was largely frowned upon back then as well.
The prefix syntax is there also to help the compiler, which are still needed when writing real computer programs that must handle memory manually.

>>105841444
Yeah because JavaScript is a script kiddie language. The actual JavaScript engine like SpiderMonkey is written in C/C++, because the browser is a real computer program that must handle memory properly. Bash is also a real computer program but Bash scripts don't require types at all, because Bash handles the type conversions automatically for you. This is not even remotely the same thing. We are talking about the syntax for typed languages.

>void (*(*name)[])()
So you're saying that (again for rare declarations) this should be written as
(*(*name)[])():void

What have you achieved there? Rare declaration, but somehow because of this, all types have to be suffixed in the syntax?

>The abstract C machine...
The modern de facto standard defined in ISO/IEC 2382-1:1993, is 8 bits.
I consider that to be universally defined, because most machines and compilers we use today, adhere to byte being 8 bits. I do get it that you could implement a different value like 1 bit, which could be very useful if tinkering with logic gates or some other specialized use.

>>105841621
real programmers work out their practices in accordance to what they're working with, that's why each language has its own conventions and best practices, often opposite to other languages'
if there were a programming language with "the other" syntax that also used header files as extensively as C/C++ does, you can be sure there would be an at least equally readable convention to it

>it was largely frowned upon back then as well
undoubtedly mostly by C people who prefer their own syntax

>The prefix syntax is there also to help the compiler
don't see how it helps, just lex it slightly differently

>real computer programs that must handle memory manually
real programs solve real business problems, where implementation details like memory management is a secondary concern

>>105841621
>The prefix syntax is there also to help the compiler, which are still needed when writing real computer programs that must handle memory manually.
If your compiler's parser needs your help with such a basic task in then you need to reconsider your choice(s).

>>105841799
>...
Given the website and subsection we are in, I will entertain this (possibly intentional) dense obtuseness. Pointer and array qualifiers are an inseparable part of an identifier's type information, it is incredibly disingenuous to merely transform the void prefix into a void suffix whilst ignoring everything else. The example I provided matches one fully-qualified C identifier to another fully-qualified Julia identifier containing (nearly) identical type information.
In any case, I am not arguing for either style. What matters is the ability to have the same level of expressiveness using either syntax and not get in the way of a competent programmer to complete the task they wish to perform. I, personally, might be intimately familiar with C-style declarations, operator precedences, and other idiosyncrasies such that they do not constitute a major obstacle when reading and/or writing convoluted jargon, but that need not be the case for everyone.
>The modern de facto standard defined in ISO/IEC 2382-1:1993, is 8 bits.
The C standard still maintains that the characteristics of a byte are an implementation detail. Even your mention of ISO/IEC 2382-1:1993 notes that "The number of bits in a byte is USUALLY 8."

>>105841381
>i havent seen that being used in any piece of code written since the first AMD64 cpus were released
I think Linux and Windows machines define int to be 4 bytes. If you want to use all 64-bits of your processor you should use long (longlong on Windows) because double is a floating point number not suitable for long integer numbers. I'm actually not sure how valid this is today but some time ago I did the sizeof(type) check on 64-bit Linux and then Windows. Linux says long is 64-bits while Windows says it's 32-bits. So on Windows you need to use longlong.

>>105841934
>undoubtedly mostly by C people who prefer their own syntax
>don't see how it helps, just lex it slightly differently
>real programs solve real business problems, where implementation details like memory management is a secondary concern
No. Writing a compiler has a lot to do with types having a prefix rather than suffix.
Compilers usually work in steps, the first runs count the number of keywords, of which types are some of the most important. Variable names will not even make it to assembly. They are there only for the high-level programmer, to make it easier for humans to read the code.
You can test this by writing a simple C program and compile it to assembly using the
gcc -S file.c

command. You will see that there are no variable names, only the types have mattered.
So when sending your code to an actual compiler like gcc, it does make a difference if the first run of the compiler only counts the first words before whitespace to determine how much memory is needed and how to organize it. On the second run it will store the values (from the variables) to those memory slots and create pointers to them. In simple programs it will use the processor stack.

Furthermore, language syntax has nothing to do with real business problems. In real programming languages, memory management is a primary concern. You're storing data to memory, and this is the key to everything else your program does. Without memory and processors, your program does not work, and will not solve a single real business problem.

>>105841996
>If your compiler's parser needs your help with such a basic task in then you need to reconsider your choice(s)
You're a script kiddie. Don't ask how I know. You really should download the gcc code and study how the compiler works. GCC 13.4 was released on June 5, 2025. In large programs it makes a huge difference if the primitive types can be counted first, as the variable names do not even make it to assembly.

>>105841996
>dense obtuseness
Sounds like you just want to argue because you believe you're always correct. Please don't be a teacher teaching programming. If you are, KYS.
You literally wrote
>"The number of bits in a byte is USUALLY 8."
as a response to me saying a byte is normally considered to be 8-bits.
You honestly argue for the sake of arguing even if you fully know that the other person is correct.

The suffix syntax for types makes it difficult for humans to read the code. Example here:
>>105841621

You already know that for human readers it's more difficult to read the type when it could be near the beginning of the line and on the very next line it's at the very end. Multiply this by a hundred and you should understand why it's better to have the type in the prefix. You have literally no argument for the suffix syntax. All you can do is write a pseudo-intellectual nonsense rather than admitting you're fucking wrong.

>>105842169
Truth be told, compilers are not my forte given that (classical) computer science is not even among my top three disciplines. My point remains the same, any compiler worth its salt should produce identical binaries whether type information is provided in prefix or suffix notation, provided that the language grammar treats both styles equivalently. The question of whether the parsing/compilation processes can be conducted quicker/more-efficiently in one representation or another is a different question that must be addressed separately.

>>105839709 (OP)
>I don't think there was a reason
I can grep let whatever and find exactly what I want without knowing its type, can't do that with C.
Checkmate cniles.

>>105841614
>In Julia-style
You literally compare a variable name for an inherited object to primitive types. Why?
Maybe you thought you're a smart guy and I wouldn't notice?

Inheritance in C++ means something like
class BMW : Car
{
//code
};


And in your Julia example your variable name is clearly an object inherited from other objects. As you can see, in my example code the BMW class is inherited from the Car class, and this very common C++ syntax only applies to classes, not primitive types. Your Julia example also uses reference types, which are "pointers", which are commonly found in scripting languages, which Julia by default is. How the fuck do you compare a scripting language to C?
> Julia's Function type does not allow specifying arguments or return type(s) due to certain language design restrictions
Yeah, by default it's a fucking scripting language. Those are massive restrictions compared to real programming languages where memory matters and the program will be compiled into assembly.

>>105842267
Programs such as compilers do not read strings (like script kiddies believe) they read one letter at a time. Compilers only need to know the type so they can allocate memory. The names of the primitive types in C are commonly char, int, float, double. That makes 7 characters with the whitespace, tops. It will then replace the following word (variable name) with a pointer. It does not need to read the variable name, as it will not be used. After that it will store a value to the address where the pointer points to. When running the binary program, it will call the value using the pointer.

Suffix syntax makes for significantly slower compilers, but also makes it very difficult for human readers to read the code. On the first line the type could be near the beginning, like sex:char, and on the very next line it could come after 200 characters of variable names. Multiply by hundreds of lines and you will go right back to C style prefixes.

>>105842417
Yes you can. In C you can typedef any primitive type or even structs using the word let, as it's not a taken keyword.
As an example
typedef char *let;

let message = "hello";

Your checkmate is invalid.

>>105841799
NTA, but why wouldn't it be clearer as something like
name: *((*( () -> void ))[])

The only problem I can see is that it could be difficult to tell whether parentheses are for arguments or grouping a type for a unary
You could even argue that the difference between a function and a function pointer is moot and that you don't even need that inner asterisk

>>105839709 (OP)
Hey, you know how function pointer syntax in C and C++ looks like absolute shit and requires a spiral rule to read properly? Turns out, trailing return types makes that a lot cleaner. And if you're going to have trailing return types, you might as well have trailing typenames as well for consistency. That's why. It's because function pointers.

>long is 8 bytes
I need you to understand that this is a very stupid assumption to make.

long is 4 bytes on 32-bit Linux
long is 8 bytes on 64-bit Linux
long is 4 bytes on 32-bit and 64-bit Windows

There is a reason why many newer languages like Rust and Zig are using typenames like i32 and usize. Platforms get very little decision on how big these get to be.

>char sex
>not bool sex
>2025

>>105841191
>Depends on what you define "byte" to be.
A byte is defined as the smallest addressable unit of memory on a system. In C, sizeof(char) is always 1. It is 1 byte, whether a byte is 8 bits or 9. The number of bits in a byte on a system is given by CHAR_BIT. I know of a very small number of machines where 1 byte is 9 bits, and C is probably the only language that is supported on them. I don't know of anything with CHAR_BIT as anything other than 8 or 9. Your other statements about int, long, and double are valid concerns.

>>105841313
>But it's about valid with most 64-bit Linux, Mac and Windows machines
long is 4 bytes on 64-bit Windows. Welcome to hell. You can no longer treat long as if it's int64_t or as if it's ptrdiff_t.

>>105842676
Because then you'd need the same shit for every primitive type no matter how mundane the declaration is.
For mundane declarations, the type could be near the beginning, like sex:char
On the very next line it could come after 200 characters of variable names.
Multiply by hundreds of lines and you will go right back to C style prefixes.
Not to mention it helps the compiler significantly. Programs that actually run on your computer are commonly written in C/C++ including browsers and their JavaScript engines (SpiderMonkey, V8, etc).
What ever JavaScript/TypeScript does, is interpreted by the JavaScript engine (written in C/C++) and translated into valid memory allocations.

If we assume that JavaScript objects are all strings (they're not but this is just a simple example), they will be stored in the computers memory as strings. This is one of the major flaws of JavaScript. In order to calculate numbers, the JavaScript engine has to parse the strings into integers or doubles, and only after that the processor can calculate. Strings are stored differently by the processor.

And here's the Big Enchilada. TypeScript programs are converted into normal JavaScript before they can be run by the JavaScript engine. TypeScript does not help the conversion from TypeScript to C++, it simply helps the developers to catch bugs during development, to serve as documentation for different types, etc. In other words, your browser does not understand TypeScript directly. TypeScript code must be compiled into plain JavaScript before it runs in a browser or any other JavaScript environment. And then it has to be translated again by the JavaScript engine to store typed values into memory.

>>105842807
You're full of shit. I already mentioned that long is 64-bits on Linux but 32-bit on Windows. In Windows you have to use longlong. Your favorite language Rust is basically C with macros. The compiler just make things "memory safe" which can be bypassed with the unsafe keyword. They're utter shit and it surprises me why Torvalds allowed that shit to stain the Linux kernel. And the LLVM compiler used by Rust is fucking written in C++ so it looks like your shitty language can't even compile to assembly huh? And Zig? Are you fucking kidding me mate?
pub fn main() void { // laughable shit code }

In C that would be
main(){ // checkmate }

The only thing Zig does is add unit testing into the language, and the retarded "option types". Do you really need to change the syntax to add unit testing into C? No, you don't.

The function pointer syntax in C/C++ makes perfect sense when you realize that they are fucking pointers. If you understand how to link a memory address to a pointer, you wouldn't call it a "spiral rule", nor make the claim that trailing return types make it a lot cleaner. You're literally saying
>it's because function pointers
as if your shitty script kiddie language has them to begin with. Show me an example of TypeScript function pointers.

>>105839709 (OP)
The way Nim does it is best. Every other way suvks because Nim is the only valid language to use in 2025.

>>105839709 (OP)
Because if your language has type deduction then you would still need some keyword as a placeholder. If you put type after the variable you can often design your syntax so it can be skipped without anything extra. Also, if you are writing generic code, types can be long and it becomes increasingly harder to parse the code, both by compiler and with your eyes.

>>105843120
NTA, but:
C lacks many if Rust features that couldn't be included with simple macros.
Rust is compiled to assembly.
There is no void type in Rust.
You need -> for declaring return type in Rust
C function pointer syntax doesn't many sense.
Trailing return types do make higher order functions easier to type.

>>105842676
>>105841799
*[*fn() -> void]

>>105843120
>Your favorite language Rust is basically C with macros
I could describe a lot of languages as "C with macros", if we're calling "having a proper type system" a macro. The whole point of having a high level programming language is being able to reason about things abstractly, so don't write off all the abstractions that Rust, Zig, or even C++ add on top of C.

>The compiler just make things "memory safe" which can be bypassed with the unsafe keyword. They're utter shit and it surprises me why Torvalds allowed that shit to stain the Linux kernel.
I don't think you understand what memory safety even means, and I think you are approaching it as some sort of a boolean property. Either it's 100% impossible for memory bugs to occur, or you have a 100% probability of a memory bug occurring, from this mindset. In reality, we're concerning ourselves with risk. How much less likely is a memory bug to occur if we can guarantee it won't originate from 90% of our codebase? Probability theory was a mandatory class for an undergraduate computer science degree when I was doing my Bachelor's. Why do you refuse to adapt this mindset?

>The function pointer syntax in C/C++ makes perfect sense when you realize that they are fucking pointers. If you understand how to link a memory address to a pointer, you wouldn't call it a "spiral rule"
"Pointer" and "memory address" are the same thing. It is an integer value that describes a location in memory. Nonetheless, think higher level. What is a pointer TO? It's a function. Functions have a set of parameters and a return type. How should we write the type signature of that? Consider:
let foo: fn(f32) -> f32;
foo is a pointer to a function taking f32 as input and returning f32 as output.

>>105843190
>Rust is compiled to assembly.
wrong it goes into llvm

>>105839709 (OP)
because it mimics the language of mathematical proofs.

>>105843190
Show me an example of TypeScript function pointers.

Rust is compiled to assembly using a compiler LLVM that is written in C++.
So what ever you say about the low-level qualities of Rust, is a lie.
Just by using the keyword let, the compiler has to spent a lot of time to determine what the stored value will be. An integer? Double? String? Object? The compiler has to spend a lot of time to determine this. Real programmers know what value they are storing. The only reason why Rust programs may be almost as fast as C, is because they are eventually compiled with a C++ compiler (LLVM) which basically converts the shitty macro code into real C++ style assembly.

You say there's no void type in Rust, but there is. All functions are void by default.
fn printHello()
{
println!("Hello.");
}


Void in C exist so that you can write functions which do not return an integer.
In Rust you have to use the -> syntax to override void.
fn add(a: i32, b: i32) -> i32 {
return a + b;
}

In C the i32 is commonly int32_t, which is something the idiot here >>105842807
seemingly did not know about.
So, fn is a macro for void. Also, the let keyword in Rust is taken from JavaScript, although it originates from the 1970s (ML, MetaLanguage). Hardly a new feature. Already mentioned that it makes the compilation process very slow. Good luck making video games with Rust.

C function pointer syntax is the same as any other pointer syntax. You do know C originated as a very simple language primarily made to write assembly code for different machines? The C syntax for pointers is considerably better than the Assembly syntax of the time, and still is. Your shitty language just doesn't compile to assembly without using a compiler written in C++.

And, trailing return types are essentially overriding fn (macro for void).
fn add(a: i32, b: i32) -> i32 { return a + b; }
// in C, no overrides needed
int32_t add(int a, int b) { return a + b; }

>>105842169
>>105842633
you continue your argument against name:type syntax in very heavy contextualization of how C works - of course a specific language will be optimized for its own syntax, but it's like arguing that rear-wheel drive cars are bad because a specific car that was designed to be front-wheel drive would not work well if you just moved the engine to the back

>Suffix syntax makes for significantly slower compilers
Pascal used to be known for compiling noticeably faster than C and it had the name:type syntax
feel free to start an argument about different strategies for linking, optimization, etc. but making that argument would only mean the syntax by itself is in fact insignificant

>also makes it very difficult for human readers to read the code
no, it doesn't
seems you are just too accustomed to C style syntax and conventions and refuse to even consider a different approach

>>105840216
literally this

>>105839709 (OP)
>As for real programmers, types matter the most. It's how computers actually work.

>>105843364
I see I touched a nerve here.
The difference between Rust and C++ is that C++ compilers can 100% compile legacy C. Your Rust compiler cannot do that because the syntax is too far off. And the syntax is macros mainly, fn stands for void, let slows down the compiler to determine what the return value will be. Both keywords function and let are clearly borrowed from JavaScript, where compile times did not matter at all.

There is a reason why C++ is still the number one choice of video game programmers and large applications. In my opinion security comes from testing the code. You write a simple C program (a library for example) and then you test it with unit tests until you're satisfied with the result. You do not need to write a new syntax for C in order to achieve that. Everything you say about Rust is null because we are talking about the syntax, which was unnecessarily changed. The people who created the language had a JavaScript background and they were total edgelords. They just had to make a different syntax even when it didn't have any effect on safety.

You're also telling me that pointers and memory addresses are the same thing. Utterly wrong.
A pointer is 8 bytes on a 64-bit system, storing an address in memory. Pointer can hold an 8 byte value, while a memory address you can get with the &-operator written at the start of a variable name and even store it to normal long or longlong. They are not the same thing.
let foo: fn(f32) -> f32;

Cool, but that's not a pointer, as understood in traditional C. It declares a variable with a type but does not initialize it. In your example you would have to initialize it also. In C you can simply write the name of the function variable and add & to the beginning.
int add(int a, int b) { return a + b; } // initialize
int (*pointer)(int, int) = add; // or &add

If you already know what your function is returning, why use fn or let? Why would you leave unit testing to the compiler?

>>105843377
LLVM is just the compiler backend. In the end, it ends up as native code.

>>105843503
>Show me an example of TypeScript function pointers.
type JSFun = () => void;

>Rust is compiled to assembly using a compiler LLVM that is written in C++.
>So what ever you say about the low-level qualities of Rust, is a lie.
I haven't said anything about low level qualities. Only that it is compiled to assembly.

>Just by using the keyword let, the compiler has to spent a lot of time to determine what the stored value will be. An integer? Double? String? Object? The compiler has to spend a lot of time to determine this.
Type deduction is orthogonal to declaration syntax order.

>Real programmers know what value they are storing.
Not every type is nameable.

>The only reason why Rust programs may be almost as fast as C, is because they are eventually compiled with a C++ compiler (LLVM) which basically converts the shitty macro code into real C++ style assembly.
The speed of languages in which compiler is written does not dictate the speed of compiled binary. You could transpile LLVM to python which runs in brainfuck interpreter executed on a redstone computer and the outputted binary would be just as fast.

>You say there's no void type in Rust, but there is. All functions are void by default.
An incomplete type void is not the same thing as a singleton.
I was only referring to your snippet of pseudo Rust where you wrote 'void' anyway.

>So, fn is a macro for void.
fn is a keyword, not a macro. The default return type in Rust is an empty tuple, (), not void.

>Also, the let keyword in Rust is taken from JavaScript, although it originates from the 1970s (ML, MetaLanguage).
It's from math. let in JavaScript has different meaning, it declares a mutable, block-scoped variable, which results in TDZ schenanigans.

>>105843503
>Hardly a new feature. Already mentioned that it makes the compilation process very slow. Good luck making video games with Rust.
Having a dedicated keyword for variable declaration makes parsing faster actually.

>C function pointer syntax is the same as any other pointer syntax.
It's not, it's known for being very hard to read.

>The C syntax for pointers is considerably better than the Assembly syntax of the time, and still is.
Assembly is untyped.

>Your shitty language just doesn't compile to assembly without using a compiler written in C++.
I have never made a programming language.

cniles are dumber than js script kiddies

>>105843641
>it's like arguing that rear-wheel drive cars are bad because a specific car that was designed to be front-wheel drive would not work well if you just moved the engine to the back
What the fuck does this even mean? Why would you move the engine to the back when the whole point of front-wheel drive is to make the drivetrain more simple? This is why Porsche and some Ferraris and Lambos have the engine in the back, because they're rear-wheel drive. Front-wheel drives have the engine in the front.

>Pascal used to be known for compiling noticeably faster than C
Bullshit. C was initially designed as a systems programming language with a focus on flexibility. The C libraries were made for many platforms, which made the compilation times slower. Later on C compilers surpassed Pascal compilers and today C++ compilers are way ahead. The early Pascal compilers were heavily optimized and for a much more simple language. The syntax itself was a major factor early on. The type syntax of name : type helped because the compiler could just jump to the word after colon. In C based languages the colon is reserved for other purposes. It was desided that the type name syntax would be sufficient because of whitespace.

>no, it doesn't
Reading lines where the type is in the beginning (letter:char) and with the next line it could be 200 characters away, makes reading the code difficult. Already provided examples here >>105841621
Read the thread and stop wasting my time.

>>105843743
>C++ compilers can 100% compile legacy C
No they can't. C++ is not a superset of C. It is not even a superset of C89.
>Your Rust compiler cannot do that because the syntax is too far off.
Yeah, because it's not trying to be C. Stop being a baby duck who thinks every language has to look like yours. The entire point of programming language development is to find new ways to make the task of programming easier by introducing new ways of abstracting things, new forms of syntax, etc... there's no point in just cloning C all the time.
>And the syntax is macros mainly
I think you don't know what a macro is.
>fn stands for void
See the fucking function pointer example I posted earlier. Uses the fn keyword. Neither takes void arguments nor returns void. The void keyword in C does not mean function.
>let slows down the compiler to determine what the return value will be
Have you profiled that or are you just stupid?
>Both keywords function and let are clearly borrowed from JavaScript, where compile times did not matter at all
1. Compile time matters a fuckload in JavaScript because it has to go from text to executed code in a web browser while a page is loading.
2. They are borrowed from ML, which came out in 1973. Also, the term "let" is frequently used in mathematical proofs for defining values.
>Pointer can hold an 8 byte value, while a memory address you can get with the &-operator written at the start of a variable name and even store it to normal long or longlong.
You are speaking exclusively in terms of C. I am not. The C programming language did not invent pointers. Its conventions are not the defining authority on what terms mean.

>>105843848
Man, I'm a fucking PhD student who's done plenty of work with C and C++, and now mostly works in Python, with the occasional Rust for tasks that need to either run fast or have low memory requirements. I have plenty of appreciation for C and C++ because they were my first programming languages, and they have helped me understand a lot about other programming languages. But goddamn some cniles today have baby duck syndrome. They have no appreciation for the history of programming language design and the idea that anyone would want to use anything different confuses them. The cnile in this thread is tragically not unique, I've seen plenty like him before on this board. I can think of plenty of reasons to criticize Rust or other programming languages, but these people do not raise real concerns about other languages, because their primary issue is that they're not C.

>>105843813
>LLVM is just the compiler backend. In the end, it ends up as native code.
Man I wish I was this retarded. You feed your Rust code to a compiler written in C++ so of course it ends up as native code. If you feed your C/C++ code to a compiler written in C/C++ it ends up as native code too.

type JSFun = () => void;

Not a function pointer. Try again.

>Type deduction is orthogonal to declaration syntax order.
Slows down the compiler a lot. Try to write massive video games with Rust and you'll understand how much quicker C++ compilers are.

>Not every type is nameable.
But they are. That's the whole purpose of types. Unless of course you're letting the user define their own types during runtime. I can't even fathom how stupid that would be.

>The speed of languages in which compiler is written does not dictate the speed of compiled binary.
What the fuck? I'm literally saying that the Rust compiler has unit testing built in and after that it's compiled with LLVM because now the Rust code has been checked for "memory safety" and it's known that the LLVM can write fast binaries. There is no reason for the vastly different syntax of Rust. I could very easily write a compiler that does the same "memory safety" checks as Rust compilers but using standard C syntax. The keywords fn and let are taking us back to the 60s.

>An incomplete type void is not the same thing as a singleton.
Rust functions are not singletons. Stop lying.

>The default return type in Rust is an empty tuple, (), not void.
It's similar to void in other languages. Literally makes no difference. In C void means no meaningful return value, where as in Rust it means (there's nothing here). Same fucking thing. You're really talented in moving the goalposts. Tell me, do you ever admit being WRONG?

>It's from math.
I was talking about programming languages ffs. I know Rust let is immutable and JavaScript is mutable, which is why Rust had to make it let mut, rather than using const.

>>105843818
>It's not, it's known for being very hard to read.
Sure, if you're a script kiddie.

>Assembly is untyped.
The types are converted into bytes or bits. The code creates space in the stack and puts the "type" there. Most processors also have separate registers for strings. Processors also have pointer registers, counters, and a lot of other stuff. I'm almost certain you have no idea of what you're on about.

>>105844117
>Sure, if you're a script kiddie.
just use assembly bro

>>105844162
>just use assembly bro
Can't AI turn any language into assembly now?

>>105843931
>C++ is not a superset of C
Okay big bertha C++ doesn’t have VLAs or int class = 4; int new = delete; delete += class;

variables, control flow, and loops are trash

>>105843931
>No they can't.
Yes they can. I've compiled ANSI C with C++ compilers many times.

>Yeah, because it's not trying to be C
Rust is trying to be a mix of JavaScript and C. I just can't understand why you insist using JavaScript to replace perfectly functional qualities of C syntax. You do know none of the syntax helps with memory safety? It's there just to make JavaScript kiddies feel better about all their wasted years with JavaScript. Keywords fn and let are pointless if you already know the value returned, which you should.

>I think you don't know what a macro is.
No u.

>Have you profiled that or are you just stupid?
No u.

>1. Compile time matters a fuckload in JavaScript
Funny, I always thought the JavaScript engine doesn't compile anything to binary.
>2. They are borrowed from ML, which came out in 1973. Also, the term "let" is frequently used in mathematical proofs for defining values.
Nobody cares. You can't use let in typed languages, JavaScript should be enough evidence here. Why does TypeScript exist, I wonder?

>You are speaking exclusively in terms of C. I am not. The C programming language did not invent pointers. Its conventions are not the defining authority on what terms mean.
You were talking about how the function pointers in C are bad. So of course I will speak exclusively in terms of C. God I wish you weren't so stupid.

>>105844117
>The types are converted into bytes or bits. The code creates space in the stack and puts the "type" there.
You don't know what a type is, do you?
>Most processors also have separate registers for strings.
So... between i686, x86_64, ARM, AArch64, MIPS, Power, and RISC-V (some of the most widely distributed instruction sets I can think up off my head, though I could name drop some versions more common in embedded spaces if need be) - which have one or more registers dedicated for strings? What are those registers called?
>Processors also have pointer registers, counters, and a lot of other stuff.
Aside from the base pointer, stack pointer, and instruction pointer, which are not used for general purpose pointer storage, which registers do you generally consider to be "pointer registers"?

>>105843701
babby's first Tarski universes

>>105844185
>Yes they can. I've compiled ANSI C with C++ compilers many times.
"There are some C programs that can be compiled with a C compiler" is not the same statement as "C++ compilers can compile C programs". There are valid ANSI C programs that cannot be compiled with any standards compliant C++ compiler, treating that C as if it were C++. C++ is not a C superset - do not treat it like it is.
>Rust is trying to be a mix of JavaScript and C
Rust is trying to fill a role currently filled by C - that is, systems programming languages - but it is not trying to be C. It's *definitely* not trying to be JavaScript, since all of its influences come from other languages. And while C++ is one of those influences, its primary contributions are features not present in C, like smart pointers and RAII.
https://doc.rust-lang.org/reference/influences.html
>You do know none of the syntax helps with memory safety?
Memory safety is not the only goal of Rust. But for what it's worth, Rust syntax does actually prevent some bugs in C. One of which is using = as an expression, which isa common typo. In Rust, you cannot "accidentally" use variable assignment as a boolean expression.
>No u.
No, really. You made a claim earlier, that the let keyword is slowing down compilers. Did you profile that? Can you demonstrate with evidence that a significant amount of additional time is spent during compilation because of a three byte keyword? Because the lexing step (whereby source code gets turned into tokens) generally is where compilers spent the least amount of time. You have written your own compiler, haven't you? Surely, you would not make bold claims about compilation times without having taken a compilers class or personally fooling around with writing a compiler, right?
>Funny, I always thought the JavaScript engine doesn't compile anything to binary.
It is frequently JIT compiled into native machine code.
>You can't use let in typed languages
Haskell would like a word with you.

>>105844173
No because it depends on the machine and implementation. You can try if you give it a common processor etc.

>>105843986
>baby duck, cnile, I love Rust
Very easy to tell you've been writing most of the comments here. I can tell because you flip out when I say Rust fucking sucks. Try writing a large video game with Rust. Compare compile times with a C++ compiler. There was no reason to change syntax if the only goal was to make C memory safe. The reason why Rust uses a lot of JavaScript/TypeScript syntax is this "JavaScript everywhere" idea and now that you've infiltrated the Linux kernel, you will be called upon. If you would use types as prefixes rather than fn, let, let mut, and the return type would be in the scope of a function rather than using the retarded -> shortcut (also from JavaScripts => retval) then I'd probably leave you alone for the most part. But you decided to declare war on C/C++ and make stupid claims that your "new" features are infact new at all, when most of the stuff comes from 60s and 70s programming languages like ML, Pascal and other shit like BCPL from 1967:
LET START() BE WRITES("Hello, World")

or
LET START() = VALOF $(
FOR I = 1 TO 5 DO
WRITEF("%N! = %I4*N", I, FACT(I))
RESULTIS 0
$)

AND FACT(N) = N = 0 -> 1, N * FACT(N - 1)


The C syntax largely fixed this idiocy by keeping the keywords limited at 32 so that it would be easy to learn and be portable. It was literally just a higher level assembly language and yet very simple and elegant. And then you fucksticks are saying retarded shit like
>Rust will replace C
when C is literally just a better assembly language, which can be used and exploited just the same. I don't hear you idiots going after assembly. Nope. It's always the cniles who get the call,
>oh but in C you can't this that and the other, our "new" language is soooo much better
Most of the time it's not true at all, but man I wish you'd attack assembly just for the sake of variety.

>>105844360
>Compare compile times with a C++ compiler
C++ compile times are notoriously quite slow if you aren't just writing C in C++.
>There was no reason to change syntax if the only goal was to make C memory safe
I have already told you that memory safety was not the only goal of Rust. Also, "changing the syntax" implies Rust started as C, and then had changes bolted on top of it. Rust is not C++, and it was not designed to be an extension of C (though I reiterate that despite being designed like an extension to C, C++ is not a superset of it). Rust was designed as a brand new language from the ground up. It primarily used a handful of ML-based languages like SML and OCaml to inspire its syntax.
>But you decided to declare war on C/C++ and make stupid claims that your "new" features are infact new at all, when most of the stuff comes from 60s and 70s programming languages like ML, Pascal and other shit like BCPL from 1967:
The Rust developers are quite clear that Rust does not have any new features other than the borrow checker. It borrows from ML, but also borrows from some other functional languages. Many of these features are not in C++ (or at least were not at the time Rust came out), and therefore part of Rust's contributions is "putting these features from functional languages into a systems language".
>The C syntax largely fixed this idiocy by keeping the keywords limited at 32 so that it would be easy to learn and be portable
Oh man, I have to learn *keywords*? The horror...

this thread is hilarious. cniles never fail to make me laugh.

>>105844191
>You don't know what a type is, do you?
Yeah I do and also I know how space is made on the stack.

>which have one or more registers dedicated for strings? What are those registers called?
AMD64 has RSI and RDI (ESI, EDI for 32-bits, SI, DI for 16-bit) which stand for Source Index and Destination Index for string operations. They are used for copying memory, as an example.

>which registers do you generally consider to be "pointer registers"?
General purpose registers. R8 to R15 on a AMD64 architechture.

>There are valid ANSI C programs that cannot be compiled with any standards compliant C++ compiler
Give examples.

>Rust syntax does actually prevent some bugs in C
They're not bugs. The programmer wrote the bug. What your language does is it tries to prevent every skript kiddie mistake ever, and in the end this will end sadly. I give Rust another 5 years before it's deadware.

>Did you profile that?
Yeah you can do that using the C++ auto keyword. You won't notice it with smaller programs but when the types get complex and have a lot of variables in the structure, e.g. video games, and the program is very large, you can rest assured it will take a lot longer. If Rust had the option to use manual types with something like C++ auto keyword, it probably would be better. But you see, Rust people want total control. They don't want any of it to trickle down to programmers.

>It is frequently JIT compiled into native machine code.
Oh is that a binary file somewhere? Where is it stored?

>Haskell would like a word with you.
Where do you need let if it's typed? I mean, where do you write let if you already wrote string? And where are the fucking semicolons? Are you forced to write indentations? I'm starting to get the feeling that people who love Rust, Zig, Haskell, Julia and all the other shitty languages have no idea why the C syntax is the way it is.

>>105844484
I know it's you. You can stop now.

>>105844425
>Rust was designed as a brand new language from the ground up
...
>The Rust developers are quite clear that Rust does not have any new features other than the borrow checker.

Yeah, you're fucking retarded.

>Oh man, I have to learn *keywords*? The horror...
The keywords are limited to 32 so that the compilers are portable you fuckstick cunt. You can go ahead and learn all 700 keywords of SQL. You just know SQL used as a system programming language is not portable.

>>105844637
most retarded post I've read on g for a long time

>>105844761
I know it's you. Seems like you ran out of arguments. You're still trying desperately to move goalposts even though you already know you're dead wrong. You can't answer a single line on that comment. It destroyed you.

>>105844637
>Yeah I do and also I know how space is made on the stack.
Oh man, subtracting from the stack pointer register. SOOOOOO complicated. And no, you don't know what a type is, because you think it's stored on the stack. When I do this:
int x = 2;
The compiler might put 2 on the stack. It will not put "int" on the stack. The type int is not a value that gets translated into that machine code. Types are an abstraction that exists only at the language level. There is a concept called "runtime type information" which exists for certain kinds of polymorphism, but that is not something that can be a general statement about types. In terms of programming language theory, types are sets. Specifically, they are the set of all values that could be assigned to some variable of that type. Thus for instance, you might think of "unsigned int" as the set { 0, 1, 2, ... 4294967295 }. When we say a language does not have types, we mean that there is no language level abstraction to reason that two variables have incompatible types. Assembly languages do not have types, they just have raw data. Bash doesn't have types either, since everything is a string.
>AMD64 has RSI and RDI
These are general purpose registers. While they do play a special role in being the only registers compatible with the movs instruction, this is no longer a common approach for code generators to handle copying memory.
>General purpose registers
1. Don't call general purpose registers pointer registers. They can store pointers, but they are not specialized for that purpose.
2. On AMD64, you will note that rax, rbx, rcx, rdx, rdi, and rsi are also general purpose. It's not just R8-R15. Technically, rbp and rsp are as well, but if you use them as such you will shoot yourself in the foot.
>Give examples
https://gcc.godbolt.org/z/G14Esd3zr
Valid C89. Invalid C++.
Objective-C is a valid C superset, btw.
>They're not bugs. The programmer wrote the bug.
Bugs are mistakes made by programmers.

damn i wish i had the energy to keep arguing like this while being completely wrong

congrats op you might just be the most retarded poster ive read all year

and this other guy replying with walls of text might not be retarded but hes on the spectrum for sure

>>105844637
>You won't notice it with smaller programs but when the types get complex and have a lot of variables in the structure, e.g. video games, and the program is very large, you can rest assured it will take a lot longer.
The problem here is not the auto keyword. The problem is that C++'s type system is turing complete. You can execute arbitrary code in template definitions that needs to be executed to resolve the type. This occurs whether you use the auto keyword or write out the full typename yourself.
>If Rust had the option to use manual types with something like C++ auto keyword, it probably would be better
You do have the option to manually write out type names. The syntax is
let variable_name : type_name = expression;
There is functionally no difference between that and
type_name variable_name = expression;
once lexical analysis is complete.
>Oh is that a binary file somewhere? Where is it stored?
In memory. The browser does lexing and parsing, and then instead of executing the AST, it does a malloc, throws a bunch of instructions on it, changes the memory protections from write to read+execute, and then throws the instruction pointer at the allocated block. This is called "Just In Time Compilation"
>Where do you need let if it's typed?
You seem to think that having "type inference" means a language is not typed.
>>105844685
C's portability doesn't come from having few keywords. It comes from making very few assumptions about where the fuck it's running. It doesn't even need to assume a byte is 8 bits. Also, SQL is a query language. That it cannot be used for systems programming is because it isn't trying to do anything other than querying relational databases. You could design a language with 700 keywords and make it run everywhere.

>>105844986
>might not be retarded but hes on the spectrum for sure
Guilty as charged. And I know way more about C than OP despite not religiously defending it as if it's the only language that deserves to exist.

>>105839709 (OP)
what a retarded post

>>105839709 (OP)
tell me how i know you don't know what you're talking about

>>105839709 (OP)
Anon, I agree, but why do you insist on explicitly declaring the data type? It is not useful. Nobody cares.
let sex;
let phone;
let (height, weight);

Are you going to assign those variable or what?

>>105839709 (OP)
Am I mistaken or does this originate from the ML language line?

>>105845609
It does, and in fact a lot of Rust's design is based on ML.

>>105839709 (OP)
char sex;

Is context-sensitive thanks to typedef
You need the lexer to know the types you declared, thanks to ambiguities like:
foo * bar;

Is this foo multiplied by bar, or a foo pointer called bar?
This was not intended in the original C, but over time they added stuff without caring for parsers

This is unambiguous
let sex:char
let ass:char *
let bar: foo *
bar * sex

So the lexer doesn't need to be context-sensitive, and in fact you can parse with a LL(1) parser

>>105839709 (OP)
i have a very specific kind of autism where i wish it was "set" instead of "let"

>>105845905
In Batch scripts, you can use set to assign variables.

>>105843893
>What the fuck does this even mean?
it illustrates the nonsensicality of your arguments - you continue to make arguments about name:type by putting it in contexts heavily optimized for another syntax
do you have difficulties imagining how would you feel if you hadn't had breakfast?

>Later on C compilers surpassed Pascal compilers and today C++ compilers are way ahead.
do you understand the phrasing, "used to be"?
and, predictably, you introduce a bunch of other unrelated factors, making syntax itself insignificant in the compilation time argument

>Reading lines where the type is in the beginning (letter:char) and with the next line it could be 200 characters away, makes reading the code difficult.
have you considered that 200-character variable names are difficult to read regardless where the type is, and that even the most verbosity-loving Java developers don't do them that long?

>>105843893
>Reading lines where the type is in the beginning (letter:char) and with the next line it could be 200 characters away, makes reading the code difficult.
in Rust this is just
let
user_input_for_the_current_session_which_is_being_processed_by_the_system_to_determine_the_next_action_based_on_the_user_preferences_and_historical_data
: &str
= "exampleInput";

>>105841334
Doesn't that happen with unsigned too?

Never bothered to learn any syntax
I just google a minimum example of whatever language to use and move on.
Do you also learn every x86 instruction by heart lol

>>105839709 (OP)
>256 sexes

>>105844986
>and this other guy replying with walls of text might not be retarded but hes on the spectrum for sure
There is at least 3 people who were making fun of OP this way.

>>105839709 (OP)
Why even define data types? Come on, it's 2025.

>>105847052
>Why even define data types?
unambiguity

>>105841191
long is 4 bytes too bro, you need __int64 (win) or long long (unix) for 8.

>>105839709 (OP)
>variable name is more important than the type (not true)
Yes true
>As for real programmers, types matter the most. It's how computers actually work. You store types in memory.
No it isn't. No you don't.

Don't get me wrong, I think types are the best abstraction in all of programming, just specifically because of the exact opposite of your reasons

>>105843893
>Reading lines where the type is in the beginning (letter:char) and with the next line it could be 200 characters away
If you average variable names and type names in a project, the types will always be longer on average

>>105848774
this but unironically