They will remain dead..
Or, put another way: People only have code styles because languages leave ambiguity. By removing that ambiguity you force your user-base to be consistent therefore increasing communication and productivity.
I tend to agree. It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side. Granted it can be tough if you use three different languages with three different sets of rules.
https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227...
I think it's worth reading more of that thread for some pros and cons of being very strict with styling rules. Note that being too strict can lead to code being less readable in specific edge cases. This may or may not be considered a fair trade off.
For example, I liberally mix C, C++, D, and occasionally other languages within a single code base on my personal projects. For sanity, I choose to observe my own consistent style across all languages when doing so. This obviously doesn't match common practice for any of the languages in question, but thankfully none of them attempt to impose the opinions of their designers on me.
I view languages being concerned with code formatting as a form of scope creep. A language should facilitate good code and communication by thoughtfully designing the syntax and providing useful constructs to the programmer. That's already an incredibly difficult problem - trying to tackle additional interpersonal or organizational issues is far too much, can't possibly accommodate everyone, and is bound to have unexpected negative consequences.
Put another way, core infrastructure should nearly always be as unopinionated as possible. Stick to as narrow a design goal as is reasonably possible and execute on it as well as possible. For a language, that means faithfully translating whatever I throw at it into machine code unless there is a legitimate technical barrier in the way of doing so.
> It really grinds my gears when precious time is wasted on styling issues when there is no technical reason for either side.
If this is happening it's indicative of an organizational or managerial problem. Any given project should have a clearly defined (and consistently enforced) code style, ranging from "use gofmt" to "follow PEP 8" to "adhere to our internal style guide".
Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.
Granted, I agree that it's silly that Zig's compiler can't just "do what I mean" and just accept that there will be tabs and carriage returns.
However, I'd say programming languages in general always seem to have trouble with Windows at first, in particular because Windows is pretty alien to those more accustomed to Unix-like environments (which, I reckon, is where most people making new programming languages are actually making said programming languages).
Crystal still doesn't have full Windows support, either, on that note (you can cross-compile a "Hello World" program, but there's a lot of pretty critical stuff missing).
Have anyone know who is Alex?
He going to build compiler in AST, but as long as it’s useful for your works. It’s too early to tell whether it’s reliable for businesses, I’m more likely to trust Go as we know it’s battle tested.
It will definitely take more years to stabilise and promoting, other languages would have been mature and established.