It depends on the viewpoint of what is programming. If you treat programming as a mathematical problem, then you want to attack it the Rust's way. If you want to treat programming a practical problem, then Go's approach makes a lot of sense. For practical problems, the right answer is not known and it is not even certain that there is a right answer, so it is not about correctness; it is more about attitude and philosophy. Go is pretty clear on its philosophy.
permalinkembedsaveeditdisable inbox repliesdeletereply
[–]CanIComeToYourParty 1 point 35 minutes ago
If you don't treat programming as a mathematical problem, I wouldn't want to work with you on any codebase that's any more complex than 10KLOC.
permalinkembedsaveparentreportgive goldreplied
[–]hzhou321 1 point 5 minutes ago
That is an (admirable) attitude, but I doubt you do (treat programming as a mathematical problem). There is a direct relationship between a program (any program) and a mathematical proof. To understand what a 10KLOC program is proving is a no easy task -- but that is the intrinsic mathematical problem of programming.
On the other hand, I don't care about what the program is mathematically proving -- well, unless, you really can do the math. But I care about solving real problems. Practical problems are difficult to mathematically define -- I know that because that is what I do. I am a physicist. It is very difficult and I doubt you understand its difficulty. Defining mathematical problem is way more difficult (and important) than solving it.
In another comment, I stated that there should be two stages of programming, with different goals. The purpose of prototyping stage is to explore. In this stage, safety is less important than try and see. Because safety is less important, the code size is controlled by omitting most of the safety checks. It's a prototype, crashing is OK. For the production stage, the purpose is to service a narrow function. Safety is emphasized because we do not assume consumer's knowledge. However, feature and premises are strictly defined (often overly narrowly). Because the limit of features, the code size is also controlled. So in both stages, 10KLOC may not be desirable anyway. By the way, sometimes, often actually, it is OK to sell prototypes, as long as crashing is accepted. Purpose matters.
Just like we will 3d print a prototype but not for a product, we should not use the same language/approach for prototyping and production. Currently, we do. That is problematic.
permalinksaveparenteditdisable inbox repliesdeletereply
[–]PM_ME_UR_OBSIDIAN 0 points 3 hours ago
For practical problems, the right answer is not known and it is not even certain that there is a right answer, so it is not about correctness; it is more about attitude and philosophy.
You don't want your programs to correctly implement their spec?
Functional/mathematical tools are often extremely useful for real-world programming. Think of generics, for example.
Even the awe-inspiring monad is finding mainstream, real-world use as C# async or JavaScript promises.
Rust is better equipped than Go for lots of problems, but to use this equipment you have to learn it.
permalinkembedsaveparentreportgive goldreply
[–]hzhou321 2 points an hour ago*
You have to understand what I was saying first. In the case that we have rigorously set up premises, then there will be one and only one logical correct answer, and that is what math help us to find. However, in practice, we never can completely set up premises because we do not have or understand the complete complexity. When the premises (logically called axioms, physically called laws, practically called contexts) are ambiguous, there is no final verdict of correctness.
Math is an approximation/simplification of reality. When (and often) the mathematical simplification is too simple (often due from convenience -- there is not much use of math model if you can not easily solve it), the mathematical correctness is not the same as practical correctness.
You gave an example of spec. But why we have spec in the first place? We have spec as a solution or design for practical problems. Is it more important to maintain spec correctness, or more important to constantly check against practical needs? Can spec itself be incorrect?
Math genius (think of Rain Man) does not guarantee practical superiority. But I am not saying being good at math is useless.
Programming is very practical. I have a vision of what I want computers to do. I often do not understand the premises of my vision and I often do not see the path to my vision. I often start with a mere direction. I start advance toward my vision anyway even sometimes the path I am prodding is dangerous or reaches deadend. However, as I try and error, my vision becomes clearer and eventually, I may arrive at a more rigorous goal which may be very different from the vision I had in the beginning. That is what reality practicality looks like.
Now if I have to put up a mathematical model of my vision and I am only allowed to lay down a path that correctly matches the mathematical model, not only I wouldn't be able to make much progress when our idea is ambiguous, but also our vision will be narrowed by whatever model we laid down. How would you see the benefit of a machete if you already marked that any open blade is incorrect?
Rust extends some common sense rules -- in particular, conflicts in ownership assumptions -- into universal rigid laws. People being cut too often by common sense mistakes welcomes that, I can sympathize with that. Go on the other hand, merely advises common sense and provides convenience to try and error, emphasizing constant error checking for example. That is a very different direction from Rust. I actually do not completely concur with Go. I would differentiate programming into roughly two stages -- an exploring stage and a final product stage. For the early stage, it is more important for us try and get as broad feedback as we can. Even you can't fly, fly anyway, or you won't understand what it takes to fly. In the product stage, we trim our vision into a product that has very limited features and interfaces so we can utilize the mathematical rigor. If the product is not supposed to fly, there will be no way for you to try. Currently, we are swaying in the middle. Programming is difficult at the early stage as the underlying language constantly refuse to let you fly even that is your intention. Programming is difficult at the late stage as we have our products with all features ever conceived and they are wrapped in layers with leaky interfaces -- and the underlying language is too simple to help us maintain the mathematical rigor.