FORTRAN/77 or COBOL/85?
All you need is a compiler…
FORTRAN/77 or COBOL/85?
All you need is a compiler…
GCC provides both a compiler and a runtime library for both Fortran and Cobol.
If you’re going that ancient, the obvious ideal programming language is IDEAL.
That would be great. Please before trying to present complex examples just pick the most basic ones to present in py, vala and C. I prefer C but would like to see how it compares to others.
I’d like to offer nim as a potential due to it’s ability to compile to c or cpp while having a very python-like syntax.
Nim is interesting, like Genie, though it’s more effective right now to write examples in Python due to its larger developer base. Feel free to submit examples in Nim or Genie and I’ll try to get them merged and integrated into the developer documentation.
I feel that Rust’s package management is one of the strongest aspects of their build system. BTW, the “packages” are actually the source code that gets downloaded and built locally. You, of course, have full control over what gets included in your app and nothing is “automagical” about it. If you want to use a certain package but have concerns about it then you are free to examine the source code.
Yes, you can examine the source code of included packages, which tells you at that moment it’s clean. Unless you plan to do that every time you build something, it’s not good. Of course, you can pin a particular version, and not benefit from future updates from upstream… Or you can check over the source code every time, for every project, as an extra step before compiling… Or you can hope that none of the packages you use have a security issue… Or you can pick a language that actually has shared libraries, install common things once, from your distro provider, and not worry about it.
[dependencies]
some_library = { path = "path/to/some_library" }
Also, there’s nothing inherently safe about libraries from your distribution. Like all open source software, they rely on the community to police and report security issues. Just like security issues for crates.io are reported to the Rust maintainers.
@lperkins2 I agree with your sentiment, but to be honest: that also excludes python to a degree. It is increasingly installed and updated in venvs and through pip rather than relying on the distro’s packages.
Aye, I’ve railed against venv
and pip
in the past too. Useful tools for development, not so good for deployment. I honestly don’t expect to win in the end. Convenience trumps security. We can’t get people to not just use the same password everywhere, people are going to use download-from-the-internet tools for deployment.
The only language which was harder to me to learn than Rust was Haskell and Python (but python was harder simply because it was my first language).
Regarding productivity though, I’ve never been as productive in a language as I’ve been in Rust. Yes, it takes longer to get a prototype working, but as the language is so restrictive it’s rarely a huge difference from prototype code to actual release quality code in my opinion. To me it is not hard to code something that works, to write something that is clean and bug free is the hard part and Rust forces me to do that by design.
In my python projects old code much more often changes because of this, in my Rust code things rarely change unless I need to extend it with some new functionality.
So my point is, if you want to prototype I agree that Python or Go is better languages. But if you intend to actually release it I believe that Rust is actually more productive in the long run because of the guarantees the compiler gives you.
You’ll be pleased that apart from details on what it means to “have” shared libraries, that language is Rust.
See https://source.puri.sm/Librem5/squeekboard/blob/master/debian/cargo/config for an example of using Debian’s packages.
That is a cool trick. What do you have to place in the /usr/share/cargo/registry directory to make that work?
I’ve seen this comment several times from Rust users. Since I’ve never written anything serious in Rust, I guess I’ve never gotten to the point where all the extra work that Rust requires was worth it to me.
Nothing explicitly, just
apt install librust-clap
for example, and any other dependencies you need. They still need to be declared in Cargo.
When it comes to prototyping, comparing Python (personal projects) to Rust (squeekboard, personal projects), I find that Python’s ability to do whatever you like is a bad thing if you don’t have a fairly good concept of what you want the outcome to be like, it’s in danger of becoming spaghetti before the idea is understood. Rust also does, but because the compiler will bug you until you clean it up (and tell you where), it incentivizes stopping and thinking about what you actually want to achieve.
So now, for choosing between Python and Rust for prototyping, I rely on things like library support, how far the project is intended to go, and how I’m going to use it.
Nim is yet in an early stage, but it’s a language with many interesting concepts and ideas, furthermore Nim has great support for metaprogrammability.
Genie is just Vala with some pythonish sintax but like Vala is just a traditional C-like language with many of all unsolved problems of this kind of languages.
Honestly I can’t see any strong point on why Gnome still concentrates efforts with Vala (and even so, there is an huge lack of docs) instead of provide greater support for new-generation language like Nim, Rust, Julia, Crystal and so on.
The lines of code to hello world program in different languages
JavaScript: 9
Scheme with G-golf: 11 *
Scheme Guile GL: 12 *
Python: 12 *
C: 14 *
Vala: 14
Perl: 17
Rust: 17
But I really don’t like Javascript