It’s not a question of tools, it’s about the ability and willingness to study and practice secure coding. What’s happening is that developers think that “secure” languages will do their job for them, and they don’t need to learn good security practices.
Bad languages or good languages depend on the developer. Bad languages are bad.
The Ada language is focused on security and has defined standards. It is stable and used in critical sectors. If you were to use a language focused on security in Haiku, it would be Ada:
My study of secure coding tells me that Rust does, in fact, completely eliminates entire classes of bugs because they are checked at compile time. If you are a good programmer, what are the reason you would decide to not use such a tool?
It’s like saying good nuclear reactor operators don’t need to shut off the doors to the reactor chamber before powering it up, because their reactor just don’t explode. If you think that, you are not a good reactor operator. The safety is part of the job, you know you will make mistakes, however rare, and you should use all the available tools at your disposal to reduce the impact of such mistakes.
With Rust, you can reduce from a crash at runtime to an error at compile time. It will be easier to debug, and it will happen in tour development environment where it will do no damage. And the runtime cost is low and acceptable (or possibly even negative according to some studies).
You can decide that you have reasons to not use these tools, and they may be valid reasons. But deciding “good programmers like me don’t need this” is being over confident on yourself and your team.
I guess am in some danger of falling in that hole, with Rust. Maybe it’s just because my way of learning these languages causes too much pain while banging into Rust’s various prohibitions, but I found it beyond cumbersome. Rust wants to enjoy the C lifestyle of no runtime overhead, with the safety of higher level languages, and that gets pretty tight. I got it to the point where I could run some Haiku API, but just couldn’t stand working with it.
Haven’t tried Swift, but a casual look at the description makes it look a lot more tolerable. I used Python for a long time and rarely found any reason to worry about circular references vs. reference counting, so if their solution with weak references etc. doesn’t look very handy, it’s not likely I’d have to deal with it much anyway. Managed memory is part of how you get to use tuples etc. as return values, and the language becomes more expressive of the programmer’s intention. Just that one thing, the reliable distinction between return values on the left, and input parameters on the right, is a huge step forward.
It’s not a question of tools, it’s about the ability and willingness to study and practice secure coding.
The Ada language is focused on security and has defined standards. It is stable and used in critical sectors. If you were to use a language focused on security in Haiku, it would be Ada
Note that Ada is used in this area exactly because it choose tools over “secure coding”. Not only it has a much stronger type system than languages in C tradition, there are also tools like SPARK that allow you to prove your code correct.
It is not very good at dealing with pointers though, since it requires ideas that were not available in 80s.
The Rust language is good for small programs written in Rust. When the software becomes more complex and needs to be mixed with C/C++, you start to have headaches, bloated executables, things not implemented due to problems in the Rust language, lack of standards.
The Nim language doesn’t have Rust’s problems. Rust is a poorly finished product, sold as a solution for everything, when there are languages with better solutions and fewer problems.
I remember this case study, dev effort in using rust and language not allowing to create secure code:
“sold”? It is free to use if it fits your needs. Sure, it is relatively new and there is, as with anything new, a bit of a hype cycle. That is how we usually discover the limitations of something, and where it is appropriate or not to use it.
That does not make it bad, and, in the case of Rust, it happens that the places where it can be used are where C used to be the main language. Which is not an accident, that’s exactly what the language was designed for. But it also found a few more places where it works well, I have seen people migrate from Python to Rust for some projects, for example. They get more type safety and a performance boost, so, why woudl they not?
Yes, if you deal with legacy code or a team already experienced with another language, it is not as clear cut. There may be reasons to not migrate yet. But I would guess that in a few years, C will have a position similar to the one of FORTRAN today: only a few very specific case, and not a thing you would consider for new projects anymore. It’s about time the world gets past this badly designed and unsafe language. It will not disappear, but a lot of places where it was used will now have better tools at their disposition.
As it is a language with years of development and improvement, it has documentation and ways to solve problems, such as pointers.
“Pointers in Ada are implemented through a more abstract, machine-independent facility known as “access types.” Values of these types have a default initial value that designates no object, and can designate both dynamically allocated objects as well as declared objects (i.e., those that are on a notional stack). Values designating allocated objects are created via the reserved word “new” as in some other languages. Values designating declared objects are created via the attribute ‘Access, applied to the declared object itself. No other means of creating values exists, absent an explicitly unchecked conversion, so the facility is safer than those that allow arbitrary creation of pointer values, say via addresses. The only way to deallocate is via an explicitly unchecked facility. Thus an access value is always meaningful, absent explicit use of an unchecked facility.”
Understand the term “sold” in the sense of advertising, like a TV or YouTube commercial, which offers a product that solves all problems.
The C language has problems, it’s a fact, the problem is that they offer another, more problematic language and still have a toxic community that doesn’t help.
We need standardized, well-documented languages and a healthy community around them, that recognizes the advantages and disadvantages of the language, and is willing to truly help, not a religious sect.
I was going to give it a look, but git seems to have got stuck in a loop for the last hour and a half so I guess that’s going to take another try. I’m hoping that the installed disk requirement will be a good deal less than the 16+Gb apparently required to build.
Far as I can tell, there are two big approaches to safety. Not just in programming; this is a deep philosophical rift:
Some people try for safety by installing handrails, smoothing down edges, emplacing signs and educating people to stay safe.
Others slap prison bars on everything, lock people up in cages and handcuff them for good measure, then blame them for problems anyway.
The “git gud” mentality that expects you to just not make mistakes is absurd and dangerous. But so is trying to constrain people instead of helping them do what’s right. Because I guarantee you can’t possibly predict all the ways something can go wrong, and you can’t always be there to take over from those you’ve rendered powerless in the name of “safety”.
I’ve seen this play out in Python, which like Swift gives you features that help (like the ability to return any and all values on the left hand of the assignment, that I mentioned above.) And it gives you a lot of room to “hack.”
If I could nominate a single distinctive outcome from programming in good programming languages, it would be that you can easily redesign your program. It’s universal that we find after a while that not everything was anticipated. Maybe you never thought that a USB input device would send in two separate reports that each have important configuration data, and your design is predicated on getting it all in one report. Two choices: redesign, or hack.
What tied it for me with Python was a big package designed by a well known Python expert, that was hacked. Things like constructing identifier names at runtime. Making it hard to debug, and of course, hard to redesign, and it’s simply not possible for people who think they’re smart to resist the urge to tinker with meta programming and so forth to the eventual end of a program that is perhaps undergoing constant ferment at a low level but has calcified in its basic design. Python is hard to redesign because of its freedom - because you’re free to use any object in any expression context, for example, the language can’t guarantee that it’s correct, and it can’t advise you if a revised version is any more or less correct. You just have to run it and find out.
I’m for “prison bars”, if that means static typing. It looks to me like Swift has some ability to do type inference, which makes it less of a nuisance, and the protocol system to make it reasonably flexible. I don’t think a compiler can reason about code without static typing, and I don’t think you have the means to easily redesign your code without the compiler’s ability to check it.
Handrails are made of bars. You can’t walk through them.
Because I guarantee you can’t possibly predict all the ways something can go wrong, and you can’t always be there to take over from those you’ve rendered powerless in the name of “safety”.
But a type system does not set constrains by itself. Instead it allows the user explicitly state the constraints: this is what type annotations are for. And there are always escape hatches, you can jump over the handrails if you wish so.
Can I ask, should there be an install script or something of that nature? I seem to have built 4 hours worth of Swift per the git instructions and a logged report that haiku-x86_64-swift-install was part of that, but no swift anywhere.
… but the build/ directory had a directory full of various executables, and apparently one may just put that somewhere and invoke swiftc etc. This works, and I’m able to compile simple code. The package manager isn’t part of this, so I guess one builds that separately, if that’s reasonably possible on Haiku, and then it should be possible to add a StringProcessing module that the compiler is looking for.
I have written iOS apps in Swift, since it came out pretty much. You can tell that Chris Lattner came from C++ and wanted a more modern version of it.
It has a nice type system, makes certain types of bugs impossible, has lots of features, and a great standard library. Lots of features can also be a downside of course as it allows for obtuse code and a steeper learning curve. Compile times are slow and the debugger isn’t fun either. Tool support like static analyzer and such are also meh. Startup time of Swift iOS apps is also worse than ones written in Objective-C. Swift is also not afraid to break existing code when introducing a new version. C++ emphasizes backwards compatibility otoh.
Interoperability with C++ is a pain. Using Objective-C with C++, so called Objective-C ++, on the other hand is straightforward and fast. If I need to interact with a C++ library, I do it in Objective-C and then call the Objective-C code from Swift. After all Swift was designed from the beginning to closely interact with Objective-C and existing libraries. To this day Swift and Objective-C are used side by side on Apple’s platforms. Objective-C itself was designed to make it easy to call C.
Google has introduced Kotlin as a succesor to Java for similar reasons.
In general it’s great to keep an eye out for more modern succesor languages. C++ certainly has some warts and ideosyncracies. There are succesor languages to C++, that focus on interoperability. The first that comes to mind is Carbon.
Haiku certainly could use a long term strategy regarding programming languages. It could explore a succesor language that works really well with the existing system and libraries. Carbon has far more potential here than Swift ever will.
So I don’t think Swift is a good fit for Haiku. It’s a great fit for Apple platforms only. Apple’s interests in developing Swift further and Haiku’s interests don’t align.
I agree if we consider this as an alternative to C++ for developing Haiku itself but for third party apps it is worth to experiment and see how far it can go.
The same applies for applications. Interfacing between Swift and C++ is painful and limited. Are you hoping for ported applications from macOS?
I think that enabling developers to write Haiku apps using the native APIs from other popular languages could be very useful. Choosing a popular language makes sense as well. Qt for Python is a good example for something like this.
That said, things that bring more interest, users, and developers to Haiku is good for Haiku.
