At the stage that crystal is currently I have to say I am a happy camper. I would like to see multithreading fully supported but I think most important than that is to get compile time down I think this is the most painful part yet reasonable given that not many optimization has been made there
I also worth of noting that Crystal is the only language that has LLVM API support as part of Standard Library 
6 Likes
I didn’t realize that. And now that you say that it almost makes me think about all these little pet projects of new languages showing up being written in crystal. I wonder if that is the thing. Crystal being so easy to write, and so performant that writing your own custom language from scratch becomes a lot easier. 
3 Likes
Something I was thinking of along these lines as a great example is with the Lucky Framework.
When we look at pull requests, and feature requests to the project, one of the primary goals we look for is “Does this create a great error experience?”. What I mean is, if a user runs in to an issue with this feature, or update, will they be provided with a really nice way to figure out how to solve that. We’ve added tags to all of our repos that say “improve error experience”. The reason why is because one of Lucky’s main goals is catching bugs in development. We try to take type-safety to the next level as much as we can.
We do say Lucky is fast, but that’s just a byproduct of being written in Crystal. We don’t claim to be the fastest web framework, or being a “rails-like” web framework because those aren’t our primary goals. This doesn’t mean we won’t strive to be faster, or anything like that. This just means that our first priority is always type-safety and giving the user a nice development experience, with great error messages and having the app be as rock solid as possible.
Think about the projects you work on in Crystal. There’s probably other shards out there that accomplish the same goal, but why would someone choose yours vs theirs? What was your motivation behind doing a different version when something already existed?
5 Likes
I think developer happiness is the first aim. Ruby made me unhappy with its speed LOL.
It also fixes quite a few warts in Ruby (phew).
It also uses fibers like go so maybe it’s leaning toward web back end as the target? But realistically it could go anywhere, really… :)
Interesting. Can you elaborate on the issues with Ruby and how Crystal fixed them? Smell like an awesome blog post to me 
/ used to be integer divide “sometimes” and float divide “sometimes”, Object#in?, takes less RAM, duplication of method names. Can’t remember others off the top of my head [compile time checks, nil deferences are less common, named tuples make it so you can’t mess up a tuple-type dereference.]
There are some things it doesn’t do (and some that are slowly getting fixed) but in general I’m happy
2 Likes
I’m coming from Go since ~2014 and have been working with Kubernetes and related technologies a lot for the past while as well. I’ve only been using the language “in anger” for 2 weeks though, so probably take this as a newbie perspective.
Coming from Go, I’m seeing that Crystal is fundamentally different for a few reasons:
- language features
- community
- tooling
- standard library
Go isn’t worse by any means, but holistically speaking, the thing that makes Crystal unique is that it’s designed for humans but runs well on machines. That makes it a pretty good fit for microservices. If you’re one development team that has to move between, say, a node server in JS and a Java/Go server for doing some heavy duty data processing, it frankly sucks to context switch so much.
I’m certainly not saying that Crystal should replace any of those languages, but I do think that Crystal’s versatility and power could make it a good choice for writing microservices. I might, in the future, be able to make a case for using Crystal to write a web frontend service and to write a database frontend service at the same time. For the former, Crystal’s friendliness would come in handy and for the latter, its accessibility to power would really shine.
8 Likes
An other difference is:
- In Crystal evertything is an object and Go is not a pure object oriented programming language.
1 Like
@kees - Go is not object oriented language at all. It just have interfaces that can play a role as a contracts of what needs to be implemented and adhered to but this is not OOP in my opinion. C has structs and pointers to the functions that can be stored in the structs but no one is saying that C is object oriented language ;)
@ComputerMage, yes, I agree, this was the reason not to continue with Go on my search for the “perfect” language.
“Fast as C, slick as Ruby”
The niche and principle is: a ruby like syntax (beautiful in and of itself) and great performance. Crystal fulfills this.
This was the thing that drew me to Crystal. Having a solid type system with a better approach to handling Nil, and keeping pointers under the covers, so it’s a lot easier to build something rock solid without null or pointer explosions.
6 Likes
I’m way late to the discussion, but I wanted to throw out some food for thought. I’ve been reading a lot about the recent studies that found that 70% of vulnerabilities in both Microsoft’s products and Google’s Chrome browser are caused by memory unsafe languages. That got me thinking about the small stuff, the world of IoT. I mean, there are these resource-constrained devices out there running C/C++ on what is basically bare metal and they are presumably susceptible to a whole class of memory-based exploits. These devices are increasingly controlling important things around the home and even starting to show up in the medical space. I think as IoT grows, Crystal could really carve out a niche as both an introductory and power user language for small systems programming. It would be neat to have an ecosystem like node on those devices with hot-reloading/shards. You write code in an editor on your tower, push it to the device with hot-reloading. Shards are there for easily pulling in other high performance Crystal libraries. We could then sort out and tout our core principles: the performance of Crystal, the approach ability of the type system for newcomers, and the security bonuses of using a memory-safe language. I think this works around Rust because we’d specifically be targeting small systems programming.
Sources:
Microsoft: 70 percent of all security bugs are memory safety issues
Chrome: 70% of all security bugs are memory safety issues
Vulnerable C/C++ code usage in IoT software systems
A device-centric approach to a safer internet of things
3 Likes
Yes! Thank you for actually understanding what I was going for here. A lot of the replies got way off track. Just the concept that “What is the niche space Crystal is trying to go after”. It would be awesome to see Crystal be that language that’s like “If you just want solid memory management and security, you come to Crystal”. Unfortunately, I think there’s still a lot of work to be done in that space before we could even consider it “memory stable”:
Refs:
- Invalid memory access (signal 11) during specs
- Invalid memory access on Alpine
- https://github.com/crystal-lang/crystal/issues?q=is%3Aissue+is%3Aopen+Invalid+memory+access
- https://github.com/crystal-lang/crystal/pull/9360#issuecomment-634311588
There’s a lot of posts related around memory issues. Then the next level of the issue is that LLVM would also need to be memory solid, and so would the boehm GC along with all of the other extensions (libc, libxml, libevent, etc…)
If you have any expertise in this space, it would be great to have some more eyes on this.
1 Like