My mind tells me, that if we want secure, memory safe and fast software without segfaults on our secure and open Librem 5 mobile platform, the only way ahead is using Rust programming language.
I don’t think it’s ideal - because there have to be enough people who can read or read and write the language.
Also, this topic is an obvious religious war.
Right, there’s no “one right” language because different languages have different strengths and weaknesses. C++ is great for GUI design and Fortran is great for linear algebra, but not vice versa.
Ooh ooh, could you please also make those python examples available to nullege too please ?
Thank you and thank you in advance
Heh. There’s actually an excellent linear algebra system for C++11 now, but yeah, most existing linear algebra stuff is in fortran.
Given the state of the L5 hardware and software, I’m actually gonna say Clang C++2a is gonna be the best programming language, at least for now, by virtue of being the most power efficient for most programs. It’s not the most accessible, but the low battery size and low compute efficiency means a language+runtime with the highest efficiency has a lot of merit.
How do I do that? Is there a quick guide, or do I have to contact the people behind it?
Sorry for the delay, I was training someone at work today…so…y’know, no goofing off with personal electronics
Anyhow, I think you just email them at nullege[at]gmail[dot]com, tell them you’d like to be one of the projects they index, and where the code is.
The thing that makes nullege so awesome is that it’s where I go (after stubbornly trying everything I can think of to do something for like three days) to see examples of how I should have done something (well, something similar) the right way; I think a lot of other people use it like that too
I’ll look into it. If it doesn’t have to be the project owner/maintainer that submits the project then I’m happy for someone else to submit it. (Hint hint)
Well, I just tried to request as “just some lady” so hopefully they’ll index it
Rust is certainly worth studying, as are the offshoot languages Carp (a borrow-checked lisp) and V (a borrow-checked go). Much like studying lisp, learning how borrow-checking works and why it matters will make you a better programmer in any language. Similarly to how Python makes it harder (but not impossible) to write ugly code, Rust makes it harder (but not impossible) to screw up data ownership. Once you have that insight, Rust itself isn’t that fun or useful to use, and you can apply that insight in other languages (avoid object leaks in GCed languages, avoid whole swaths of errors in modern C++).
I wouldn’t recommend Rust for anything serious though, in large part due to its terrible package system. Normalizing downloading packages automagically not from your distro and running code from them is incredibly bad practice (and not one unique to Rust).
While that’s true, that’s also not the whole story. Rust makes it painfully obvious where the possible mistakes are (
RefCell::borrow()). This isn’t something that carries over to other languages, even if you have the insight.
My chief insight from using Rust was that I am a terrible programmer and I have been doing everything wrong for years.
I have a conversation like this every time I try to compile anything in Rust:
Aww shucks, I’ve been doing that for years. Is that really unsafe?
Grumble, grumble… anal retentive compiler! …grumble, grumble… Someone has a stick up their ass!
Fine, I’ll do it your way! I think you’re stupid, but I’m sick of seeing you complaining. Now shut up and stop getting in the way.
Why the hell is THAT unsafe? Jesus, you are the most cantankerous compiler I’ve ever met! I don’t give a rat’s ass if you think THAT is dangerous. It looks fine to me, now go jump in a lake and stop bothering me!
OK, I give up! I’ll do it your way, even if it is stupid and takes me twice as long to write.
Now SHUTUP and compile damnit!
Sorta. Sure, like with ugly Python code, a human actually looking at it can pretty quickly spot when there’s a problem. But the over reliance on tools can easily lead to the assumption that if there’s no errors or warning, and grep for “borrow|unsafe” finds nothing, then the code is fine.
For example, here’s a terrible HelloWorld program in rust. A human glancing at it, even one with little to know programming experience, will quickly realize something is wrong.
rustc happily compiles it (after all, there’s no unsafeness to it).
The problem is that, while the ownership is consistent (which is what
rustc really enforces), it is not right. This is an exaggerated example, but I hope it illustrates the point.
rustc prevents you from mistakenly assuming a section of code owns something it doesn’t, and ensures the safe(ish) cleanup of resources when the owning namespace drops out of scope. It doesn’t help you figure out what should own something, except that by forcing you to think in terms of ownership you can usually figure it out yourself.
Once you are thinking in terms of ownership, the same lessons apply to basically all other languages (even garbage collected ones).
This is the core insight in modern C++, that any resource (including, but not only, memory) should be owned in exactly one place and should be automatically freed when the owning block drops out of scope. It’s actually quite easy to implement, the only real difference is in C++ you can mix unsafe code in without an easy-to-grep-for token marking it as such.
Drawing on the Python analogy again, just because Python makes it difficult to write ugly code, doesn’t mean python code is neater/prettier than other languages, it’s mostly useful for learning good habits in the first place.
and then it’s time to use perl.
I feel that this is the main misunderstanding most people have. Rust’s goal is not to make all code fine, but it’s to make errors of a particular class obvious. That’s nothing new: we rely on tools in C to make sure that we rely on a variable that has been allocated (as opposed to assembly), or to check that the pointer has a compatible type (as opposed to without
When looking at things this way, it becomes obvious which errors get eliminated by what.
i prefere a mix of c and cpp
most of you guys dont like blobs, but i am a professional blob creator
I am the lead (haha the only one in our small <10 people team) software developer for industrial applications. Our customers are mostly getting a .dll from us.
For compatibility i am always just implementing c interface to the outside world and using c++17 for the core functionality. Qt for GUI when needed. As an BBOS warrior (still rocking a BBQ10) i think Qt C++ is very powerful in terms of performance. If you compare the cpu capability of a q10 with the librem5 and the smoothness of the UI of BBOS with PureOS, they are getting a really good user experiance for there ticks
I like to say that the reason I trust computers more than people, is that when a computer yells at me, at least I know I deserve it
Pfft… that’s all assuming the person who programmed the computer doesn’t deserve it!