Lilith: x86-64 OS written in Crystal

Re:Lilith: x86-64 OS written in Crystal by Reelin on Monday December 23, 2019 @02:52AM (#21862121)

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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by kstenerud on Monday December 23, 2019 @03:54AM (#21862313)

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

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by ay on Monday December 23, 2019 @08:21AM (#21863414)

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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by Reelin on Monday December 23, 2019 @04:14AM (#21862388)

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?

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by BubRoss on Monday December 23, 2019 @09:43AM (#21863854)

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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by meesles on Monday December 23, 2019 @07:18AM (#21863162)

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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by ChrisSD on Monday December 23, 2019 @01:15PM (#21865658)

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-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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by Reelin on Monday December 23, 2019 @06:27PM (#21868441)

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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by Reelin on Monday December 23, 2019 @06:12PM (#21868345)

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".

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by naasking on Monday December 23, 2019 @09:42AM (#21863848)

> 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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by Reelin on Monday December 23, 2019 @06:13PM (#21868348)

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.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by naasking on Tuesday December 24, 2019 @10:57AM (#21872820)

Yeah, I still disagree. There's considerable value in being sure that you'll see the same code structure everywhere.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by sullyj3 on Monday December 23, 2019 @03:50AM (#21862305)

Presumably they're following python's example here.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by Reelin on Monday December 23, 2019 @04:01AM (#21862335)

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.)

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by sullyj3 on Tuesday December 24, 2019 @10:17AM (#21872552)

I must've misremembered, possibly what's disallowed is mixing tabs and spaces.

[ Parent | on HN ]

Re:Lilith: x86-64 OS written in Crystal by PedroBatista on Monday December 23, 2019 @05:26AM (#21862707)

Well, good for them wanting to die on that hill.

They will remain dead..

[ Parent | on HN ]