Live data from Hacker News

Lilith: x86-64 OS written in Crystal

github.com

231–240 of 265 posts

Re: Lilith: x86-64 OS written in Crystal

#231
post #123

Earlier quoted context omitted.

Bullshit, I played DeusEx a few months later just fine.

Playing a specific game or 100 on it != a translation layer from one OS to another is ready or generally usable. Games have minimal dependencies re OS APIs wise. Office apps and other programs make far more extensive use of OS facilities... So hardly "bullshit".

> Games have minimal dependencies re OS APIs wise.

Sure, if you exclude "let's use every little quirk and undocumented feature in the graphics and audio and input stacks we can find because gotta go fast sanic noises".

Both games and office software (ab)use OS APIs; the difference is the specific subset of those APIs said programs (ab)use.

So yeah, you're right that it ain't "bullshit", but don't write off games as somehow "easy" compared to office programs; a substantial amount of effort has been poured into reimplementing Windows' multimedia stack in Wine and continues to be poured even now.

Re: Lilith: x86-64 OS written in Crystal

#232
post #166
post #6

Wow. Preemptive multitasking, graphical window management, POSIX-like, in a programming language that to my knowledge it hasn't yet been done in... and in just several months of work. There's no smoke and mirrors as far as I can tell. I dug back to the initial commit: https://github.com/ffwff/lilith/commit/c9fa1053dc6a22d630ee6... - and it's just bootstrapping to VGA. Very well done, and inspiring. Makes me want to t…

Sorry for the late reply (being rate limited) Thanks! Originally it only started as an experiment to see how far I could go making an OS in a high-level (higher than C at least) language, I was only planning to build a monotasking DOS system. Around this time, Andreas Kling started to show us his SerenityOS, which was one of the factors propelling me to reach this point. So shout outs to AK! Yeah! It's pretty fun to…

Sorry that your account was being rate-limited. It's software filters that do that, based on past activity by trolls. Unfortunately it also sometimes prevents project creators from showing up to discuss their work. I hate that!

We've marked your account legit so this won't happen again.

Re: Lilith: x86-64 OS written in Crystal

#233
post #58

Earlier quoted context omitted.

It's missing many things that make it a viable language: - libraries - community - support The language itself is not even finish or properly tested.

I can only see 1,209 repos after using Crystal for close to a year, some are no longer maintained. https://github.com/topics/crystal There are lacking of stories around the cloud computing or any large businesses has success with Crystal. They need more of those to gain support if they don’t want to remain in “uncharted territory” which mentioned in their interview.

https://crystalshards.xyz/ is the de facto aggregator of various libs for the language.

Re: Lilith: x86-64 OS written in Crystal

#234
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…

> but compiles to standalone binaries that run really, really fast.

In a world with Go, Rust, D, C++ and C, this part requires comparison with these other languages.

Faster than Ruby and faster than Python doesn't cut it.

Re: Lilith: x86-64 OS written in Crystal

#235

Earlier quoted context omitted.

> C bindings, strongly-typed, a great concurrency model, very fast, and Ruby-like syntax. Ruby’s syntax is a great fit for Ruby’s semantics but—and Ruby is my personal favorite language—I don't see much point for it divorced from that. It's the one thing I like least about Elixir. OTOH, Crystal looks like it may be close enough to Ruby semantics that Rubyish syntax is a plus rather than a misdirection and distraction…

In what way is Elixir's syntax like Ruby's? It has "end" on blocks and string interpolation with "#{whatever}", but everything else is different. It's about as close to Ruby as Ruby is to Python (which is to say, not much).

Having done lots of development in both Ruby and Elixir (both professionally and on my free time), I'd say the only substantial differences boil down to the following:

- Elixir has |> instead of method chaining

- Elixir uses "do [...] end" consistently for blocks (as opposed to Ruby omitting the "do" in front of function/module/class/etc. bodies)

- Elixir supports Erlang-style tuples on a syntax level while Ruby (AFAICT) does not

- Elixir supports Erlang-style pattern matching / destructuring while Ruby (last I checked) does not

- Elixir's a fair bit stricter about differentiating zero-argument function calls from variables (i.e. if it's ambiguous it'll complain)

That is to say, Elixir's syntax descends directly from Erlang and Ruby, just as Ruby's syntax descends directly from Eiffel and Perl, and it shows rather strongly. That should be unsurprising, given that Elixir is the creation of a (former?) Rails maintainer.

Re: Lilith: x86-64 OS written in Crystal

#236
post #190

Earlier quoted context omitted.

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.

> the code isn't that clean

It's cleaner than a solid 90% of the code I've read over the years :)

Re: Lilith: x86-64 OS written in Crystal

#237

Just this morning I was pondering the same thing in Elixir. I wonder if Elixir and Crystal compete for ruby developers to pick up

¿Por qué no los dos? While I haven't tried it yet, Crystal seems like a viable candidate for writing NIFs/ports for Elixir apps.

Re: Lilith: x86-64 OS written in Crystal

#238
post #143
post #85

Earlier quoted context omitted.

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.

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 w…

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

Re: Lilith: x86-64 OS written in Crystal

#239
post #85

Earlier quoted context omitted.

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.

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.

Re: Lilith: x86-64 OS written in Crystal

#240
post #135
post #66

Earlier quoted context omitted.

Perfectly fine as per European standards.

And probably by asian standards too. Basically anyone non-american is ok with this i think (knowing the author is probably also underaged). I hope US scare of anything barely related to nudity won't be the new norm.

Hell, I'm American and I don't really see a problem with it either. Wallpapers are meant to be seen, and most importantly are a reflection of what the chooser of said wallpaper likes to see; if people like looking at half-naked anime characters every time they use their personal computers, who am I to judge?

Emphasis on personal computer, of course; if this was in a workplace or otherwise-professional setting, then yeah, I'd be concerned, too. That's obviously not the case here, though (unless you're really building your business on top of some high school kid's pet OS project, in which case - no offense to said high school kid - you're completely and irrefutably bonkers).

If you don't like it, fork it and replace all the wallpapers with puppies or Jesus or Insane Clown Posse or whatever floats your boat. I won't judge your taste in desktop backgrounds.

Post reply on HN