Live data from Hacker News

Lilith: x86-64 OS written in Crystal

github.com

221–230 of 265 posts

Re: Lilith: x86-64 OS written in Crystal

#221
post #209

Earlier quoted context omitted.

i've been a huge fan of elixir ever since i found it a few years ago. The main web framework (phoenix) is doing some really cool stuff right now with live-view, too, and I'm pretty darn excited about it. I've always thought that the best system for a web server would be erlang OTP, because of the design based around uptime and system recovery. It has been proven in production by a few companies now in web dev, and er…

Isn't elixir just syntactic sugar on top of Erlang semantics?

1) Yes.

2) No. It's sugar + opinions.

Elixir gives you a lot of 21st century development tools: Async Tasks, Compilation environment (dev vs prod vs test out of the box), first class documentation and first class test suite. Sure you could implement these in erlang, but in Elixir, it's opinionated and everyone is basically on board with the same set of tools.

Some of these tools are making their way back to erlang, like telemetry, and some aspects of docgen.

There are also some under the hood features, too. I can run async tests where the test is given an id, the database gets a sandbox with that id, I can escape the vm (via chromedriver, eg) passing the id, and when the request hits the http server component, it and all child tasks is aware of the test that it's in, so all of the database calls are routed to the correct sandbox, resulting in concurrent and idempotent end-to-end tests. Again, you could do this from top to bottom in erlang, but elixir has support for this out of the box, and the good anointed and 3rd party libraries (Mox, ecto, hound) use these elixir features.

It's pretty nice to be able to run a full suite of unit and E2E tests in about 10 seconds.

Re: Lilith: x86-64 OS written in Crystal

#222

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

I think it really helps that you can write mostly functional code in Ruby by just chaining higher-order array functions, and you can use Pipes in Elixir to do this almost identically -- when you consider the fact that all the higher-order array functions have identical or very similar names and parameters in the two languages.

My Ruby code is like 95% chained higher-order array functions. My classes almost never have state. I'm basically writing functional code, and it seems like this is a pretty common paradigm in Ruby. I will say this was HEAVILY influenced by learning Elixir.

When not taking external libraries into account, my Elixir code (at least to me) seems almost identical to my Ruby code.

I think Python and Ruby are very close. But I personally think list comprehensions are un-intuitive and you can't easily chain higher-order array functions in Python.

So although I feel the spirit of my Ruby and Python code is identical, in no way do they look and feel identical. In the same way, I think my Elixir and Python are quite different.

Sample size of 1. I know. Just thought I'd share.

Re: Lilith: x86-64 OS written in Crystal

#223

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.

All that stuff is still optional. I don't think there are any cases where removing type annotations from a working Crystal program will change behavior.

Re: Lilith: x86-64 OS written in Crystal

#224

Earlier quoted context omitted.

> C#, Kotlin and Swift are the system API languages of major platforms (MS, Apple, Android). No, the system API of those systems is exposed in C, ObjC and C respectively. You may be thinking about the most common language in those platforms nowadays (and their respective APIs).

It's still C all the way down, even in 2019. Amazing how far crappy, badly thought out, ubiquitous, low entry barrier languages can go. More than 40 years of memory errors, out of bounds errors, broken metaprogramming, undefined behavior, lack of error handling, type safety, abstractions and intelligent design in general, all served under the clunky syntax sauce. And it still powers our world. Worse is better, indeed…

> crappy, badly thought out, ubiquitous, low entry barrier languages

It is easy to criticize designs that are 47 years old in today's context.

I am betting you wouldn't have done a better job half a century ago either.

Re: Lilith: x86-64 OS written in Crystal

#225

Earlier quoted context omitted.

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

I think it really helps that you can write mostly functional code in Ruby by just chaining higher-order array functions, and you can use Pipes in Elixir to do this almost identically -- when you consider the fact that all the higher-order array functions have identical or very similar names and parameters in the two languages. My Ruby code is like 95% chained higher-order array functions. My classes almost never have…

Thanks for sharing! I think though that what you are referring to is not syntax but semantics. On both places you are chaining HO array functions, so the algorithm is pretty much the same, but the syntax you use is different in both places (pipes, dot).

Re: Lilith: x86-64 OS written in Crystal

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

Hey ffwff, amazing work and pace on Lilith so far! I'm honored to have inspired you :)

Re: Lilith: x86-64 OS written in Crystal

#227

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.

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.

You're probably describing this or a related issue: https://github.com/crystal-lang/crystal/pull/6351

I don't think it was ever a major roadblock. The fix isn't pretty but it doesn't come up that often in practice.

Re: Lilith: x86-64 OS written in Crystal

#228

Earlier quoted context omitted.

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; m…

Crystal uses llvm, and should be able to cross-compile to platforms llvm supports, presumably not without some trouble.

Re: Lilith: x86-64 OS written in Crystal

#230
post #76
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…

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.

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

Post reply on HN