Rust "makes programming fun again".

[bakul]

Sounds like <assert.h> to me. Yeah, I'm being facetious. Of course, Rust does have some technical merits, moving that type of constraint validation, from run-time to compile time.

assert.h is for checking of assertions at runtime. Too late!

 

[kpedersen]

I am actually surprised at the amount of pushback against a programming language that -for me- fits in a legitimate niche. So does Perl.

The pushback is really because it doesn't fit into a number of use-cases that the Rust community can't identify and hence can't improve. Its a bit of a lost opportunity. For me, the language itself is reasonable but the churn of dependencies and bindings is not scalable or maintainable enough. This could almost be fixed but would require a different mindset.

assert.h is for checking of assertions at runtime. Too late!

When it gets down to it, as soon as you take in external variables (files, socket, input, etc) the checking can only be done at run-time. I would even suggest that run-time checking with Rc<T> in Rust tends to be more common than at compile-time via the borrow checker.

 

[bakul]

When it gets down to it, as soon as you take in external variables (files, socket, input, etc) the checking can only be done at run-time. I would even suggest that run-time checking with Rc<T> in Rust tends to be more common than at compile-time via the borrow checker.

I meant as a replacement for the type & attribute system. At runtime panic()ing is usually the worst choice for a service.

 

[astyle]

Agile.. often seems meant to facilitate the managerial brain that can't hold a coherent plan for longer than it takes a coffee to go stale. Operational agility is not necessarily a bad thing, but it's more often than not a completely irrelevant outcome. So what if you can change a system or a process twelve times a day? Who benefits from that and how? As a former product owner in the scrum treadmill I learned that in this role you're not supposed to ignore the method in favor of hammering out desired outcomes. People find you "difficult to work with". But in the end nobody gives a flying fudge about how many story points my team "burns". The real boss only ever wants outcomes. The jerk who bugs you about Jira charts? Ignore, politely if they're friendly.

As for Rust, well, I don't have any skin in this game. I am actually surprised at the amount of pushback against a programming language that -for me- fits in a legitimate niche. So does Perl.

Well, if somebody wants to write the next Great American Compiler, and insists that this is the only way to really solve the problem (that the whole project is meant to solve in the first place), and then takes their sweet time on that first stage, then yeah, that programmer is not being productive, and needs reminders to cooperate with the rest of the team, and to mind the deadlines. In this scenario, it's gonna make sense to just fire the unproductive programmer and look for other solutions that give you results faster than a few years out.

OTOH, just try to force the core FreeBSD dev team to use vibe coding with VB.NET, on a JIRA-compliant schedule, you'll get a ton of pushback for being ridiculous.

And BTW, these are not original ideas that I'm expressing in this post. I've seen other threads in these Forums that follow this bikeshed discussion theme. I remember ralphbsz sharing quite a few ridiculous stories in here, they were an interesting read.

 

[MG]

Maybe do a bit of research about what Rust is, and some of its background/history, rather than engage in uninformed sarcastic bashing?

It's a programming language.
Lang/rust/gkg-descr: Rust is an open-source systems programming language that runs blazingly fast, prevents almost all crashes, and eliminates data races.

They don't like the amd64 instruction set. You can address and change all bytes unconditionally. That's not normal.

The "systems" part is a bit suspicious. You would like that, huh?

 

[blackbird9]

Maybe do a bit of research about what Rust is, and some of its background/history, rather than engage in uninformed sarcastic bashing?

Hahaha, I guess that's fair enough

 

[astyle]

It's a programming language.
Lang/rust/gkg-descr: Rust is an open-source systems programming language that runs blazingly fast, prevents almost all crashes, and eliminates data races.

They don't like the amd64 instruction set. You can address and change all bytes unconditionally. That's not normal.

The "systems" part is a bit suspicious. You would like that, huh?

Every language has its upsides and downsides. You get to decide what you like and what makes you want to look elsewhere for a different programming language that solves your problem with less pain.

Reading about Rust, I'm beginning to actually like what they're trying to do in terms of Code of Conduct. Who wants to work with someone who places themselves to be unaccountable to anyone but themselves? I think that was very well put.

It's safe to assume that Rust is Turing-complete as a programming language. As has been repeated many times before, "There is more than one way to do it", it's possible to program around the quirks of the Rust support for amd64 instruction set.

 

[MG]

Every language has its upsides and downsides. You get to decide what you like and what makes you want to look elsewhere for a different programming language that solves your problem with less pain.

Reading about Rust, I'm beginning to actually like what they're trying to do in terms of Code of Conduct. Who wants to work with someone who places themselves to be unaccountable to anyone but themselves? I think that was very well put.

It's safe to assume that Rust is Turing-complete as a programming language. As has been repeated many times before, "There is more than one way to do it", it's possible to program around the quirks of the Rust support for amd64 instruction set.

It cannot act on a higher lower level than the hardware. Everything Rust can do was already posssible with something else. It seems to be surrounded with a vague argumentative appeal to being the central authority. But computers don't work like that today. The owner is the boss. Not the manufacturer, OS-supplier or programming language provider.
using it alone or in a bussines isn't enough. Others must be forced too. Let's go FUD on all other languages... Didn't this happen too around c#? I remember app-makers that put an oath on it but never made a real hardware-executable.

 

[astyle]

It cannot act on a higher level than the hardware.

really? I thought that every programming language in existence acts on a higher level than the hardware...

It seems to be surrounded with a vague argumentative appeal to being the central authority

Somebody needs to organize the mess. And, it's amazing what can be accomplished if you organize your ass off and put in some effort to enforce the structure.

But computers don't work like that today.

Yeah, they do - the cloud is the central authority these days.

 

[drhowarddrfine]

it was someone at Mozilla

I know that. What language did he write it in? Who checked it for errors? Who checks the compiler writer for errors now?
If Rust is watching the Rust code writers, who or what is watching Rust?

 

[cracauer@]

I know that. What language did he write it in? Who checked it for errors? Who checks the compiler writer for errors now?
If Rust is watching the Rust code writers, who or what is watching Rust?

Rust is an LLVM project, so that language is C++.

 

[drhowarddrfine]

Rust is an LLVM project, so that language is C++.

But...but.....but.......

 

[Crivens]

They don't like the amd64 instruction set.

What a pity... I don't like it also, but for different reasons. Once out cut your teeth on something like the M68K and progressed to three address machines like ppc or mips, x86 feels simply unelegant and looks like some cave painting.

 

[cracauer@]

But...but.....but.......

Of course the Rust compiler is full of C++ bugs.

 

[mer]

I know that. What language did he write it in? Who checked it for errors? Who checks the compiler writer for errors now?
If Rust is watching the Rust code writers, who or what is watching Rust?

I think that is a question for pretty much every compiled language.
Semantically all compilers take input and generate machine code that runs on a CPU. But who/what defines that the machine code is actually correct and how does one determine "pass/fail"?
And yes this is probably not a question unique to Rust.

 

[astyle]

Of course the Rust compiler is full of C++ bugs.

Rust was written in OCaml, not C++... check the Wikipedia link that I provided.

drhowarddrfine : Rust Foundation is the one watching Rust. I'd suggest reading up on it, it will answer a LOT of questions.

 

[mer]

Rust Foundation is the one watching Rust. I'd suggest reading up on it, it will answer a LOT of questions.

Ha kind of like lawyers deciding if other lawyers violated code of ethics.



That's a joke as it relates to Rust/Rust Foundation, but not so much as it relates to lawyers.

But does OCaml go directly to machine code or some intermediate (think of compiled Java going to java bytecode that can get compiled to actual machine code)?

 

[bakul]

Of course the Rust compiler is full of C++ bugs.

The rust compiler is written in rust but AFAIK the backend is still llvm (so c++) & the backend bugs can't be attributed to rust. The original one was in ocaml.

 

[bakul]

I think that is a question for pretty much every compiled language.
Semantically all compilers take input and generate machine code that runs on a CPU. But who/what defines that the machine code is actually correct and how does one determine "pass/fail"?
And yes this is probably not a question unique to Rust.

It is all nominally based on mathematics. Strachey & Scott invented denotational semantics to bridge the gap between programming language and rigorous mathematics but most modern languages are not cleanly defined so their denotational semantics get rather unwieldy. So for example a denotational semantics spec. for C would be much much larger than Scheme's. There are other methods too - such as axiomatic semantics, operational semantics etc. All this more complicated for concurrent programming languages like Go. Modern proof assistant languages like Agda, Coq, Isabelle, Lean etc. are used for verifying and proving algorithms, properties of software and programming languages etc. *In practice* most people won't use these but these are the tools used to try define and prove formal semantics. [A long ago I stumbled upon Scott and Strachey's book on Denotational Semantics at my university library and when I "got" what they were doing, I was amazed and it answered many PL questions for me. If you are interested in this sort of thing I recommend Joseph Stoy's book or something more modern.]