Earlier quoted context omitted.
Crystal _could be_ for game developers; there's large green pastures left almost entirely untouched for a language to disrupt it. You see a few niche languages make inroads, like Haxe, but I expect something could really effect change. The key is to be as fast as possible, as memory light as possible, and able to produce and speak to C ABI.
Nim and Lua are in that pasture. Being fast, memory light, and the C interop are the key features of Lua.
Lilith: x86-64 OS written in Crystal
211–220 of 265 posts
Re: Lilith: x86-64 OS written in Crystal
#212Earlier quoted context omitted.
Nim and Lua are in that pasture. Being fast, memory light, and the C interop are the key features of Lua.
Lua yes, and since the 90s, but Nim? I've not seen that yet. What games use it?
I'm not saying it's widespread, but the language features put it in that field.
Re: Lilith: x86-64 OS written in Crystal
#213Earlier quoted context omitted.
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…
I wonder what a D OS would be like.
Re: Lilith: x86-64 OS written in Crystal
#214Earlier quoted context omitted.
> 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.
Rust is more like 4 than 9; 2015 was the initial stable release, most people couldn’t really use it for things before that.
Re: Lilith: x86-64 OS written in Crystal
#215Earlier quoted context omitted.
> I'm interested why it seems to be getting little attention compared to Go, Rust, & Julia. Rust essentially competes with C and C++ (and maybe D and Nim without their GCs), and the reason it gets hype is because it brings some unique features for that niche. Go brought some unique features as well (goroutines done right), and it is pushed by a major player. In Julia's niche, you only really have Julia and Fortran -…
Crystal _could be_ for game developers; there's large green pastures left almost entirely untouched for a language to disrupt it. You see a few niche languages make inroads, like Haxe, but I expect something could really effect change. The key is to be as fast as possible, as memory light as possible, and able to produce and speak to C ABI.
Re: Lilith: x86-64 OS written in Crystal
#216Neat project, though slightly undermined by the drawing of the half-naked underage girl in the readme
Re: Lilith: x86-64 OS written in Crystal
#217Wow. 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…
Re: Lilith: x86-64 OS written in Crystal
#218Earlier 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…
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.
Re: Lilith: x86-64 OS written in Crystal
#219Earlier 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…
Take for example, the imperial units. I think the vast majority of American engineers would agree about its shortcomings. But it can't go, simply because it's already there.
C is the same. Look at any modern natively compiled language. They will always come with some easy ways to bind to C. Because to not do so would be a stillborn language.
So even in tech, where things evolve extremely rapidly - compute power/$ has improved a million x since the days of C, C still lives, and is the underlying basis of everything. Because conventions.