Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lilith: x86-64 OS written in Crystal

github.com

Post reply on HN
Print view View original

101–110 of 265 posts

Re: Lilith: x86-64 OS written in Crystal

#101

Post by rishav_sharan »

tomrod wrote: post #25
nlh wrote: post #17

Earlier quoted context omitted.

I found Crystal about a year ago and absolutely fell in love with it. It just “clicks” for me. My sense from reading most peanut-gallery commentary that the biggest reasons it hasn’t taken off more (yet) are: 1. Real multi-threading (it’s now in alpha - but previously just had single-threaded concurrency - and sorry I might be getting that terminology wrong). 2. Windows support (I personally don’t care but I haven’t…

> Windows support WSL support maybe?

Wsl is good for webdev. Not something that you will use in production. And certainly not for other usecases like gamedev

Re: Lilith: x86-64 OS written in Crystal

#102

Post by kaikki »

saagarjha wrote: post #92
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 has other, bigger issues :/

What are some? I wrote a small ascii snake game with it and found it generally OK.

Re: Lilith: x86-64 OS written in Crystal

#103

Post by rishav_sharan »

shakna wrote: post #15
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.

> It's older than Rust, Kotlin, Swift, Nim, or even OCaml, and doesn't really offer anything they don't. Crystal is only five years old. Nim is 11, Rust is 9, Kotlin is 8, OCaml is 23 and Swift is 5. Basically, Crystal is tied with Swift as the youngest. What it offers right now is a simple porting process for those with Ruby codebases.

I am subscribed to the windows support github issue since 2013, so Crystal is definitely older than 5 years. I think its around 7 years old

Re: Lilith: x86-64 OS written in Crystal

#104

Post by pjmlp »

ksrm wrote: post #98
pjmlp wrote: post #60

Lovely, very inspiring to see "not yet another UNIX clone in C", in a language like Crystal. Wishes of a successful long term project. I will be adding it to my OS list.

Is your OS list public?

Yep, and easy to find with some Google-fu, however there you go.

http://www.progtools.org/article_new.php?name=safe_systems&s...

Re: Lilith: x86-64 OS written in Crystal

#105

Post by rvz »

lmm wrote: post #46
nine_k wrote: post #44

Earlier quoted context omitted.

Okay, port your existing Ruby code to a compiled language, giving it multiple times the speed? Maybe three is a slight business opportunity here. Also, give your developers a more productive language that can go where Ruby can't (like OS development), which is 90% instantly recognizable — may also be worth something?

Is it really so hard to port Ruby code to any of the languages I mentioned? Even with Crystal you will still have to make changes to your code, is having to use a slightly different syntax such a big difference? If you've got Ruby code and you haven't already ported it, how badly do you need the speed?

Well it seems most developers here would rather use Ruby + several memory-optimised VM clusters to make their services go faster and destroy their balance sheet than to use a faster language that is efficient in memory and is also blazing fast.

A rewrite in (other fast language) from Ruby sounds ridiculous as soon as you include writing a extra FFI wrapper around this you have to maintain so that would be out of the picture and that sounds a lot harder than a semi 1:1 port of the source code.

The trouble is Ruby itself is starting to become a sunken cost as a language but is survived because of Rails, thus also explains the countless memory issues that happen when developers use it. So for a stopgap to something sort of better, I would rather port to Crystal or Elixir so I can run on those low-cost VMs and save cash.

Re: Lilith: x86-64 OS written in Crystal

#106

Post by sullyj3 »

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.

Presumably they're following python's example here.

Re: Lilith: x86-64 OS written in Crystal

#108

Post by kstenerud »

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.

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

Re: Lilith: x86-64 OS written in Crystal

#109

Post by ernst_klim »

viraptor wrote: post #79
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.

Kotlin - it's on JVM which is a good thing for some and a bad thing for others. It's easier to distribute standalone crystal binary for example. Swift - crystal throws exceptions, swift explodes... Ocaml - the functional approach is not for everyone. Rust - I like rust a lot. But sometimes I want to write something quick and I'm happy to sacrifice some memory and speed to not have to deal with the ownership issues. N…

> Ocaml - the functional approach is not for everyone.

OCaml is pretty general purpose though, it has loops, objects, mutable state. libguestfs [1] and some other codebases (the compiler itself, btw) are written in a pretty imperative OCaml.

[1] https://github.com/libguestfs/libguestfs

Re: Lilith: x86-64 OS written in Crystal

#110

Post by Reelin »

sullyj3 wrote: post #106
Reelin wrote: 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.

Presumably they're following python's example here.

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.)
Post reply on HN