Lilith: x86-64 OS written in Crystal • Hacker News Board

Re: Lilith: x86-64 OS written in Crystal

#181

Post by asymmetric » Mon, Dec 23, 2019, 2:30 PM UTC

orthoxerox wrote: post #70

mintplant wrote: post #59

Earlier quoted context omitted.

Didn't Crystal run into a major development roadblock a couple(?) years ago? Something about a fatal design flaw in the type system which led to exponential blowup in larger programs. I haven't been able to surface the relevant GitHub threads again, but whatever it was, I guess they worked past it eventually.

Yew, they tried to do whole-program type inference a la ML. That was a long time ago, modern Crystal has you indicate parameter and return types.

Do you have a link?

Re: Lilith: x86-64 OS written in Crystal

#182

Post by BubRoss » Mon, Dec 23, 2019, 2:40 PM UTC

tstusr20190823 wrote: post #99

BubRoss wrote: post #76

Earlier quoted context omitted.

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.

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

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.

Re: Lilith: x86-64 OS written in Crystal

#183

Post by naasking » Mon, Dec 23, 2019, 2:42 PM UTC

Reelin wrote: post #85

BubRoss wrote: post #76

Earlier quoted context omitted.

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.

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.

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

Re: Lilith: x86-64 OS written in Crystal

#184

Post by dom96 » Mon, Dec 23, 2019, 2:42 PM UTC

PixyMisa wrote: post #144

lmm wrote: post #12

Earlier quoted context omitted.

What's Crystal's unique selling point? It's older than Rust, Kotlin, Swift, Nim, or even OCaml, and doesn't really offer anything they don't. More Ruby-like syntax? Fine, but most people don't particularly like Ruby syntax.

Unique? There are a hell of a lot of computer languages out there. The only unique ones are those that are so bad that no-one ever did that again. The selling point for Crystal is that it has a clean syntax that's easy for Ruby or Python developers to pick up (almost the same as Ruby), but compiles to standalone binaries that run really, really fast. I mostly work in Python because the libraries are a lot more mature…

Have you given Nim a try, as a Python developer it seems like it would be right up your alley.

Re: Lilith: x86-64 OS written in Crystal

#185

Post by BubRoss » Mon, Dec 23, 2019, 2:43 PM UTC

Reelin wrote: post #85

BubRoss wrote: post #76

Earlier quoted context omitted.

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.

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.

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.

Re: Lilith: x86-64 OS written in Crystal

#186

Post by yjftsjthsd-h » Mon, Dec 23, 2019, 2:43 PM UTC

ffwff wrote: post #127

yjftsjthsd-h wrote: post #63

Earlier quoted context omitted.

Sure, but an OS that self-describes as "POSIX-like" would be expected to follow the UNIX approach to things.

POSIX-like, not entirely POSIX! There are basic IO syscalls, and some process management calls, but overall I try to take unix as a guideline rather than trying to reimplement one entirely. I also try to take inspiration from other kernels (like fattr (which is equivalent to GetFileAttributes from WinNT), and spawnv from DOS/WinNT). I guess I should reword it :/

That's fair. And to be clear, reading "POSIX-like" makes me expect it to act like a unix, but that hardly means that you should be bound to follow that exactly:) If you wanted to set expectations a bit, maybe "partially POSIX-inspired, with other influences from $FOO and $BAR" would be clearer?

Re: Lilith: x86-64 OS written in Crystal

#187

Post by samatman » Mon, Dec 23, 2019, 2:44 PM UTC

ffwff wrote: post #130

skocznymroczny wrote: post #112

How does memory management work in Crystal. Is it RC or GC or manual? As a D user, I've been curious about Crystal for a while, but until it gets proper Windows support I won't be playing with it too much.

Out of the box, Crystal does garbage collection through the boehmgc library, however if you pass in some compiler flags you can get application to not use GC. As for my OS, I wasn't gonna port libgc, and since I have prior knowledge of building a GC in rust (very badly!) I decided to make a tri-color concurrent, mostly precise (through compiler patches), garbage collector, in Crystal.

Have you read Mike Pall's proposal for a quad-color collector in LuaJIT?[0] That you took this approach leads me to think you'd find it interesting.

[0]: http://wiki.luajit.org/New-Garbage-Collector

Re: Lilith: x86-64 OS written in Crystal

#188

Post by ffwff » Mon, Dec 23, 2019, 2:50 PM UTC

nlh wrote: post #165

ffwff wrote: post #126

Oh wow someone actually posted this! Thanks a lot for the comments and criticisms guys, really means lot to me. Before I go I'll answer some questions, so ask them away!

I’ll echo what everyone else said - SUPER IMPRESSIVE and awe-inspiring work. Thanks for sharing it with the world. I have one question: While I can read and understand each individual line of code you wrote (go Crystal!) and what each method does, etc., I’m at a total loss for how you knew what and how to build - big picture wise. Can you share a bit about your process for building the mental model of this? How do yo…

You can checkout what I replied to jchw. But tldr, wanted to do DOS => got ambitious => made it multitasking => got more ambitious => added graphics and guis.

Currently it's pretty barren driver-wise, I currently have a FAT16 driver, a keyboard/mouse driver, some basic code to handle core architecture hardware and that's it. I really want to have CDROM support, a network driver (ne2k or e1000), an audio driver (sound blaster?) and an actual file system.

My roadmap is go with the flow. If I want a text editor, I'll focus on building a text editor. If I want to play doom I'll port doom (but I dont so I won't :^)

Re: Lilith: x86-64 OS written in Crystal

#189

Post by squarefoot » Mon, Dec 23, 2019, 2:55 PM UTC

burlesona wrote: post #40

onlyrealcuzzo wrote: post #11

Earlier quoted context omitted.

Maybe it's just because I come from Ruby, but Crystal seems like an amazing language. I'm interested why it seems to be getting little attention compared to Go, Rust, & Julia. It seems in the same league to me. Kotlin and Swift have more obvious reasons for their adoption.

I wouldn't say it's getting "little attention," rather it's relatively new (for a language) and not backed by a major player who can instantly give it a huge spotlight / platform. For being a 5-year old indie language out of South America, I think it's doing quite well, and projects like this are good evidence of why. Ruby is an outstandingly productive language. Copying the expressive syntax and ergonomics of Ruby i…

"Ruby is an outstandingly productive language."

This. I recall ages ago when I had to write a networked tool and had lots of freedom in choosing tools and languages (and time), so I picked this new thing called Ruby just because it looked so easy to understand. That was years before Ruby On Rails was introduced, so the language was pretty much unknown. After some time to grasp the basics I started to be productive; making changes or adding functionality or debugging became really fast, and in the end I recall thinking "if only this thing was nearly fast as C that would be wonderful". I believe that just happened. OK, maybe not 100% identical to Ruby or 100% on par with C speed wise, but just being close to that is a huge achievement. I only wish it was available for small embedded ARM boards like other interesting languages like Nim etc. Last time I checked, Crystal is bootstrapped, ie it requires itself to compile itself, which IMO doesn't help portability to new iron.

Re: Lilith: x86-64 OS written in Crystal

#190

Post by ffwff » Mon, Dec 23, 2019, 2:55 PM UTC

GordonS wrote: post #138

ffwff wrote: post #126

Oh wow someone actually posted this! Thanks a lot for the comments and criticisms guys, really means lot to me. Before I go I'll answer some questions, so ask them away!

I just wanted to say, to build such a fully-featured OS on your own, and in such a short time frame, is an incredible achievement! I very much look forward to reading through the code and learning more about it.

Thanks but the code isn't that clean, there are hacks here and there and it isn't organized as clearly as I wanted to but feel free to look through it.