Anyone trying to ”bust this myth” are to me suspect of either selling snake oil or just trying to defend their own mediocrity.
If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.
A problem for Zig is the combination of unsigned overflow UB, implicit widening and always performing operations on the type size of the operands.
For example, let’s say you have `a = b + c` with b/c being i8 and a i32. This calculation is first performed as an 8 bit add, then extended to 32 bits. This is true for both Rust and Zig, but Rust requires an explicit cast to widen the result of `b + c`, making it obvious that an extension happens and that `b + c` is not performed in 32 bits. In Zig there is no such indication- you need to look up the definition of b and c. Other problems occur as well, that both C and Rust avoid in their own ways. Hopefully Zig can improve this situation.
And there are languages that try to keep to C and add some minor safety improvements, eg my language C3 (subarrays/slices, contracts, all UB has runtime checks in debug builds and more)
- Some GNU extensions are already there, let me know what else you need.
- ?: and statement expressions (slightly extended) are available in C3 today.
- Type syntax is simplified in C3 more in line with other languages, e.g. java style array declarations.
- What does "full LLVM features" mean?
- What do you mean by "Non-Unicode"?
- You'll likely be able to include files (and more), but token macros are out I'm afraid. I've tried to cover all uses, but I know it's not quite complete :(
- All the stuff with offset, alignment etc will of course be available.
- Macros can act like compile time functions, but direct manipulation of the AST is not there to make the macros easier and safer to use. There is stil a lot of things one can do with using conditional compilation etc, but no manual construction of AST nodes. It's about trying to keep the language fairly uniform even though you add a very powerful macro system. I'm sorry.
- What do you mean by "reduced runtime requirements"? The ability to run it freestanding? If so, yes then this is a goal.
- No setjmp/longjmp, instead it has a system with implicit "Result" style returns. But it has a unique flavour. A brief overview can be found here: http://www.c3-lang.org/errorhandling/
- Sadly I had to give up on goto. To replace it: labelled blocks and labelled for/do/while/if, switch-jumps with "next", error handling using "failable" Result types and defer. The reason for removing goto was due to the amount of compiler complexity needed to support unstructured jumps. I didn't remove it willingly.
- Plan is to be able to at least build a robust ref counting lib in the standard library, supported by subtyping and defer this could be at least as easy as in ObjC before automatic refcounting. Temporary allocators (like Odin) will solve most of the temporary allocs (like when you work with strings etc). I'd need some time to explain how that works in detail, but memory management can be made much easier without even having GC or refcounting.
- The build system is part of the compiler.
- Package registry: still on the fence with that one. We'll see.
- The compiler is not built as a responsive compiler. Working on the compiler I don't feel that the workflow of a compiler is the same as is needed for an IDE. The most important thing is not that the compiler is responsive, but that the language amends itself to be compiled in isolation in a modular way. This is a property of the language, and it's been designed with IDE friendliness in mind.
- Adding more DWARF support is on the todo and obviously a requirement for a serious language
- LLVM prevents anything based on LLVM to be really slow to compile. It takes something like 99% of all compile time, even on debug builds with no optimizations. To have really fast debug builds a custom backend is needed for each platform. That will happen eventually.
1. Implementing pre/post condition checks are optional for a conforming compiler. Putting the checks in special docs comments underscores that the checks are optional. The more C way would perhaps be to use pragma.
2. Putting checks either between comments and function signature, function signature and body, or at the start of the signature body visually divides function signature from code that’s actually run.
3. Since these are hard requirements on calling functions the information needs to be in the documentation anyway. This ensures that docs and contracts are always in sync.
But yes, I think your opposition to this is a valid one. It is not ideal, rather it is the best trade off I could find. Given the above.
If anything the problem is usually understated, as a big problem in larger teams become people who actually add negative net productivity to a team. Also, not to be forgotten (and also covered in books like Waltzing with bears) are people who act as multipliers to the whole team by making the team “gel”.