5 ms·
> > Rust is way more complicated than it should be > People often make this statement, but I don't know exactly what it means. I can't speak for op, but you'r
by geocar 9y ago
> > Rust is way more complicated than it should be
> People often make this statement, but I don't know exactly what it means.
I can't speak for op, but you're right: people often make this statement. I'll try to explain what I might mean:
C is way more complicated than it should be.
The things we want in a language are tools that allow us to tell the computer what to do, but because people are bad at that, language design is taking us in the direction of telling the computer what we mean so it can tell us whether we're talking gibberish or not.
I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. I have a good idea what kind of machine code the compiler is producing, and yes: I often objdump to make sure.
If I need a FSM, I'll use erlang. If I need any kind of data processing, I'll probably use K/Q where I can. I can write some fast stuff in C where I need it. If I just need to bosh some stuff together I have perl. Maybe I want to fantasize about a DSL? It'll probably be a lisp or a forth. If I wanted a strong type system for units I want to get from some model nerds, I'll use OCaml.
I don't see the point in Rust when doing these things takes more code and runs slower, and worse:
> Rust is 2 years into it's stable life. It's young.
I got burned by Python when it was" two years into its stable life" sometime around 1.5 and again around 2.2, and so I hesitate even looking at rust unless in a decade it can still run and compile rust programs written today.
This whole "let's rewrite everything in rust" is good practice. I'm watching you guys do it, and I know afterwards you'll try to beat the performance I'm getting in other languages.
Once you're writing programs that are smaller and faster than me, then we'll probably talk.
> C: I've met more undefined behavior that makes me not agree.
I don't write C like most people, so perhaps I don't have trouble with it like most people. My C programs don't leak memory or crash, and I tend to use a belt+braces approach to security that is very difficult in languages without good multiprocess support.
- Gaelan 9y agoI use butterflies.
- hota_mazi 9y ago> I don't need a type system. I don't need "warnings" about converting floats to chars: I know what I'm doing and why. No, you don't. Regardless of your skills and seniority (I'm guessing pretty junior with this kind of hubris), there will come a time where you will make mistakes that can be caught by a good compiler. You want this compiler at your side, and the more statically typed your language is, the more robust your code will be. > Once you're writing programs that are smaller and faster than me, then we'll probably talk What a strange metric. Assembly language would probably meet these requirements but surely, you would not consider it.
- mining 9y ago> I'm guessing pretty junior with this kind of hubris If you check their profile their site suggests that have ~15 years of experience.
- geocar 9y agoThat's just management experience. I've been programming professionally for almost thirty years at this point. That's admittedly long enough to get some peculiar ideas about programming, but there's a certain kind of person that thinks "statically typing" is a panacea for programming mistakes -- or even that there's a single solution for anything at all...
- hota_mazi 9y agoI wouldn't trust anyone who thinks a solution is a panacea in the software field, but having type annotations demonstrably leads to not just more correct code but also code that can be understood better by its surrounding tooling, thereby enabling automatic refactorings, auto completion, smart browsing, optimizations, etc... Static typing is not perfect but it's better in all respects than dynamic typing.
- geocar 9y ago> I wouldn't trust anyone who thinks a solution is a panacea in the software field ... unless of course that solution is static typing. > Static typing is not perfect but it's better in all respects than dynamic typing. Except performance, of course: A dynamically-typed language is at the top of the STAC-M3 benchmarks for time series data processing. Oh and defect count: Qmail has the lowest defect count of any source-available software in the last twenty years and it's written in C. So I guess static typing is better unless you want correct code that runs quickly, which unfortunately is important to me.
- hota_mazi 9y agoCan you point to these Stac-M3 results and maybe at least mention that language? I wasn't able to find it. Static languages are universally recognized and demonstrated as faster than dynamically typed languages, even if you claim to have found one rare exception. This is not just an opinion, it's scientific and objective fact. But please share with us that code that runs more quickly on a dynamic language than a static language for you, I am genuinely curious (and equally curious to find out if you just made this up).
- userpass 9y ago>I don't need a type system. I'm not sure how that is supposed to work in C. Are you telling me you're doing everything in raw byte arrays? As soon as you use primitive types or structs in C you're using the typesystem. Even if you use byte arrays everywhere aren't you still documenting the datatype somewhere? Or are you telling me you have them all in your head? How do you remember that ptr[0x3f] refers to the name field of the struct? At the very least you'd turn those magic numbers into a constant. (#define CUSTOMER_NAME_FIELD 0x3f) and suddenly you've reinvented structs... Types are statically enforced documentation that is trivial to create. Yet I see people constantly wanting to avoid this small triviality to "be more productive". In your case you should just use assembly and shut up.