Rust "makes programming fun again".

bvdw78 said:
I am actually surprised at the amount of pushback against a programming language that -for me- fits in a legitimate niche. So does Perl.
Click to expand...
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.

bakul said:
assert.h is for checking of assertions at runtime. Too late!
Click to expand...
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.
 
kpedersen said:
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.
Click to expand...

I meant as a replacement for the type & attribute system. At runtime panic()ing is usually the worst choice for a service.
 
bvdw78 said:
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.
Click to expand...
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.
 
astyle said:
Maybe do a bit of research about what Rust is, and some of its background/history, rather than engage in uninformed sarcastic bashing?
Click to expand...
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?
 
MG said:
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?
Click to expand...
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.
 
astyle said:
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.
Click to expand...
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.
 
MG said:
It cannot act on a higher level than the hardware.
Click to expand...
really? I thought that every programming language in existence acts on a higher level than the hardware...
🤔

MG said:
It seems to be surrounded with a vague argumentative appeal to being the central authority
Click to expand...
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.

MG said:
But computers don't work like that today.
Click to expand...
Yeah, they do - the cloud is the central authority these days.
 
drhowarddrfine said:
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?
Click to expand...
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 said:
Rust Foundation is the one watching Rust. I'd suggest reading up on it, it will answer a LOT of questions.
Click to expand...
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)?
 
mer said:
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.
Click to expand...
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.]
 
Keep in mind that the whole IR to machine language translation in LLVM is C++ - regardless of what the specific language frontend is built in.

Just the number of bugs lurking in there should be staggering.
 
cracauer@ said:
Keep in mind that the whole IR to machine language translation in LLVM is C++ - regardless of what the specific language frontend is built in.

Just the number of bugs lurking in there should be staggering.
Click to expand...
So Rust to C++ then LLVM compiles/links?
Kind of like original C++ that was roughly "C-preprocessor on C++ to C then compile C"?
 
You must log in or register to reply here.
Back
Top