5 ms·

Lots of the crop of new languages with cleaner designs have huge problems with windows. V doesn't work on windows and zig's compiler fails if you use carriage

Lots of the crop of new languages with cleaner designs have huge problems with windows. V doesn't work on windows and zig's compiler fails if you use carriage return newlines. They even built in an error message for it instead of just making the parser work. It's kind of ridiculous how these languages shoot themselves in the foot.

Reelin 7y ago
I think Zig is probably just being opinionated there; many of the new languages seem to be overly so. Last I checked, both the Zig and Nim compilers refused (on principle, not for any technical reason) to compile code containing tabs (among other things). I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high.
- sullyj3 7y ago
  Presumably they're following python's example here.
  - Reelin 7y ago
    Python works just fine with tabs, but the language-endorsed style guide (PEP 8) recommends against them. (However, the usual plugin for Vim requires adding "let g:python_recommended_style = 0" to work correctly.)
    - sullyj3 7y ago
      I must've misremembered, possibly what's disallowed is mixing tabs and spaces.
- kstenerud 7y ago
  Go is also annoying with its anal retentive source rules. I finally got so frustrated that I modified the compiler: https://github.com/kstenerud/go https://github.com/kstenerud/go
  - Reelin 7y ago
    It really is a sad state of affairs when disabling the linter requires patching the compiler. I wonder if any of the LLVM-based Go compilers will adopt a saner policy?
  - ay 7y ago
    Thank you for this. The passive-aggressive style of erroring on unused variable while staying absolutely silent when I accidentally print the &int variable with %d format, always seemed like an inconsistency to me.
- PedroBatista 7y ago
  Well, good for them wanting to die on that hill. They will remain dead..
- meesles 7y ago
  What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved' style. 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.
  - ChrisSD 7y ago
    Rust has grappled with the issue of how far to push styling rules. E.g. from 2016: https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227561639 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.
    - Reelin 7y ago
      To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.
  - Reelin 7y ago
    It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations. 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".
- naasking 7y ago
  > I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high. Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.
  - Reelin 7y ago
    Across a specific project, team, or org, sure. That's what style guides, formatters, linters, and pre-commit hooks are for. The core language is the wrong level of abstraction for this stuff.
    - naasking 7y ago
      Yeah, I still disagree. There's considerable value in being sure that you'll see the same code structure everywhere.
- BubRoss 7y ago
  Making a compiler break with pretty much any file saved from a windows text editor is a very bold opinion, I can't say it would be my choice if I wanted to grow my user base.
saagarjha 7y ago
V has other, bigger issues :/
- kaikki 7y ago
  What are some? I wrote a small ascii snake game with it and found it generally OK.
  - saagarjha 7y ago
    It’s been somewhat overhyped by the author.
    - nedp 7y ago
      Can you give us examples where Alex "overhyped" the language? So far most of the promises he made have been fulfilled / currently work-in-progress.
  - todotask 7y ago
    I wrote a benchmark for V too and it’s fast but there are other issues internally and externally. 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.
tstusr20190823 7y ago
V have first-class Windows support, what is your problem?
- BubRoss 7y ago
  My problem is that it doesn't actually work on windows. Get the latest build, run it with no arguments, get a large error instead of the REPL.
  - tstusr20190823 7y ago
    What is "latest build"? V does not release any stable build and you can get "large error" on any platform right now when trying random "latest build" without any effort to investigate the issue.
    - BubRoss 7y ago
      The landing page has big links for executables for Mac, Linux and Windows - the windows build is completely broken.
pjmlp 7y ago
Indeed, and if they do it via cygwin, MinGW, or even WSL, that is no way to win the hearts of Windows developers.
yellowapple 7y ago
"zig fmt" ostensibly cleans up carriage returns and tabs, for what it's worth. 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).

Reelin 7y ago

I think Zig is probably just being opinionated there; many of the new languages seem to be overly so. Last I checked, both the Zig and Nim compilers refused (on principle, not for any technical reason) to compile code containing tabs (among other things). I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high.

sullyj3 7y ago
Presumably they're following python's example here.
- Reelin 7y ago
  Python works just fine with tabs, but the language-endorsed style guide (PEP 8) recommends against them. (However, the usual plugin for Vim requires adding "let g:python_recommended_style = 0" to work correctly.)
  - sullyj3 7y ago
    I must've misremembered, possibly what's disallowed is mixing tabs and spaces.
kstenerud 7y ago
Go is also annoying with its anal retentive source rules. I finally got so frustrated that I modified the compiler: https://github.com/kstenerud/go https://github.com/kstenerud/go
- Reelin 7y ago
  It really is a sad state of affairs when disabling the linter requires patching the compiler. I wonder if any of the LLVM-based Go compilers will adopt a saner policy?
- ay 7y ago
  Thank you for this. The passive-aggressive style of erroring on unused variable while staying absolutely silent when I accidentally print the &int variable with %d format, always seemed like an inconsistency to me.
PedroBatista 7y ago
Well, good for them wanting to die on that hill. They will remain dead..
meesles 7y ago
What about Go? It seems like their approach is that if they define the style guide and build it into tooling, your code style (for Go) can only be the 'approved' style. 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.
- ChrisSD 7y ago
  Rust has grappled with the issue of how far to push styling rules. E.g. from 2016: https://github.com/rust-lang/rfcs/pull/1607#issuecomment-227561639 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.
  - Reelin 7y ago
    To summarize the linked post (which I completely agree with), just provide officially recommended sane defaults and then get out of the user's way. In my view, that's how nearly all software ought to be written.
- Reelin 7y ago
  It's a fundamentally flawed approach in my opinion; viewing the users of a language as a single unified user base is a mistake. Various projects and groups will inevitably have vastly different use cases, and thus needs and considerations. 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".
naasking 7y ago
> I don't (usually) want my compiler to do linting, and I certainly don't want language authors to dictate my code style from on high. Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.
- Reelin 7y ago
  Across a specific project, team, or org, sure. That's what style guides, formatters, linters, and pre-commit hooks are for. The core language is the wrong level of abstraction for this stuff.
  - naasking 7y ago
    Yeah, I still disagree. There's considerable value in being sure that you'll see the same code structure everywhere.
BubRoss 7y ago
Making a compiler break with pretty much any file saved from a windows text editor is a very bold opinion, I can't say it would be my choice if I wanted to grow my user base.

saagarjha 7y ago

V has other, bigger issues :/

kaikki 7y ago
What are some? I wrote a small ascii snake game with it and found it generally OK.
- saagarjha 7y ago
  It’s been somewhat overhyped by the author.
  - nedp 7y ago
    Can you give us examples where Alex "overhyped" the language? So far most of the promises he made have been fulfilled / currently work-in-progress.
- todotask 7y ago
  I wrote a benchmark for V too and it’s fast but there are other issues internally and externally. 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.

tstusr20190823 7y ago

V have first-class Windows support, what is your problem?

BubRoss 7y ago
My problem is that it doesn't actually work on windows. Get the latest build, run it with no arguments, get a large error instead of the REPL.
- tstusr20190823 7y ago
  What is "latest build"? V does not release any stable build and you can get "large error" on any platform right now when trying random "latest build" without any effort to investigate the issue.
  - BubRoss 7y ago
    The landing page has big links for executables for Mac, Linux and Windows - the windows build is completely broken.

pjmlp 7y ago

Indeed, and if they do it via cygwin, MinGW, or even WSL, that is no way to win the hearts of Windows developers.

yellowapple 7y ago

"zig fmt" ostensibly cleans up carriage returns and tabs, for what it's worth. 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).