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 into a fast, statically typed, compiled language with excellent C bindings is a very compelling idea.
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; making changes or adding functionality or debugging became really fast, and in the end I recall thinking "if only this thing was nearly fast as C that would be wonderful". I believe that just happened. OK, maybe not 100% identical to Ruby or 100% on par with C speed wise, but just being close to that is a huge achievement. I only wish it was available for small embedded ARM boards like other interesting languages like Nim etc. Last time I checked, Crystal is bootstrapped, ie it requires itself to compile itself, which IMO doesn't help portability to new iron.
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 erlang has been used for years by telecom companies for their own infrastructure.
elixir, imo, is awesome because of the ruby-like syntax, but I would probably be using erlang for my personal projects regardless because of what I mentioned earlier.
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.
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 found a single thread talking about Crystal where someone doesn’t chime in and complain about this)
I have a feeling once it reaches 1.0 and those issues are addressed it’ll get a bit more attention. It deserves it!
WSL support maybe?
Wine in 2001 was not 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".
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.
But also, having DX7/8 being almost 100% compatible back in the day was a huge step on stability vs Windows 98, even if the RAM and CPU usage were higher. DX run fast, so did Max Payne.
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 when precious time is wasted on styling issues when there is no technical reason for either side. Granted it can be tough if you use three different languages with three different sets of rules.
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.
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".
Enforced code style consistency has considerable advantages. "Linting" probably shouldn't be a thing.
They will remain dead..
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).
Have anyone know who is Alex?
He going to build compiler in AST, but as long as it’s useful for your works. It’s too early to tell whether it’s reliable for businesses, I’m more likely to trust Go as we know it’s battle tested.
It will definitely take more years to stabilise and promoting, other languages would have been mature and established.
I don't find it surprising to see this question in a discussion involving a language related to Ruby. It's a bit sad it still comes up, but there is overwhelming demand for better Windows support of this and any other good or promising software running on Linux or macOS.
Historically, Python has had reasonable Windows support. It got to a point where it was OK and stopped improving. In recent years there has been more attention and improvements. This investment has meant that the language is reasonably viable for a lot of tasks on Windows. This doesn't mean that there hasn't been an influx of folks at points with little knowledge or care for Windows, but lots of packages work reasonably well.
Ruby is a different story. Rails was the big growth driver and there was a narrow focus. The pattern emerged of dev on macOS and deployment on Linux. I personally credit the tropes about only seeing Macs at dev conferences in a big way to Rails. The result is that it's infeasible to use Windows directly and you are best to go with a VM, or now WSL 2.0. It didn't have to be this way when a big chunk of developers are Windows. Rails could have taken an even bigger chunk of the market if Ruby had better Windows support.
Strategically, Crystal and other languages that want real adoption and the things that go with that (more recognition, more libraries, more real world use, more contributors, etc.) need to work out a good plan for Windows support.
Meanwhile Python and Golang work great on Windows with no extra effort. It's like night and day.
Windows support means less friction for people who wants to try it out.
Is this some kind of variation on Works for Me(tm)?
This has been hurting RoR adoption for long, although at this point it probably no longer matters.
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 - sure there are many other languages used in that niche, but there are very very few languages exclusively designed for that niche.
C#, Kotlin and Swift are the system API languages of major platforms (MS, Apple, Android). Javascript is the language for the web.
What's Crystal for?
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).
This is incorrect. Microsoft doesn't have a C compiler, only a C++ compiler, so the lower level language on Windows is C++. Yet for application development, the application language is C#.
On Apple, the lowest level language is ObjC, and the application language is Swift. And on Android, its C + Kotlin.
Doing application development on, e.g., Android, using the C NDK, is pretty much unsupported, since the NDK is mostly undocumented, and changes often. The only stable API for application development is Java, or Kotlin.
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.
The key is to be as fast as possible, as memory light as possible, and able to produce and speak to C ABI.
I'm not saying it's widespread, but the language features put it in that field.
Why Erlang processes are not right?
I'm reading up on it and liking what I'm seeing so far. This could be a great Golang (which I detest) replacement for me when I need to write a small, native program. Also, the Ruby-esque syntax is a win. I've always thought Ruby was a nicer language than Python. Too bad Ruby never grew much of a dev community outside of Rails.
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.
That's it. That's why it fails to gain the traction it deserves.
And wanting to be part of Google team helped many community contributions. Easy to compare with how much community contributions were made to Inferno and Limbo.
[0]: https://www.reddit.com/r/golang/comments/b6h8qq/is_anyone_ac...
I havent had issues with Go on Windows or any OS, is there something broken about Go in Windows?
Asked my friends to try it out and they love it too. Hopefully we can grow a bigger ecosystem for Crystal to make it a main stream programming language one day.
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.
But, yeah, besides the syntax familiarity for Ruby programmers it doesn't seem offer much that the others do.
The "even OCaml" is what threw me. Still not quite sure if they meant older or younger from it.
> But, yeah, besides the syntax familiarity for Ruby programmers it doesn't seem offer much that the others do.
A familiar syntax is a huge benefit in a lot of contexts. There's plenty of Ruby-only shops around the world. Making a faster and statically-typed language accessible to them is a decent niche.
Crystal isn't quite Ruby. It has type guarantees that Ruby doesn't, which makes it easier to maintain. The async and parallel stories are also immensely better in Crystal than Ruby.
The "Nil is a compile-time error" is also a feature I highly appreciate.
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?
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.
I just want to know if it is more than that or not.
I'm not a fan of Ruby and would prefer Nim or Rust if it were about syntax.
I ask myself if I miss any huge speciality of Crystal if I dismiss it just because of its syntax.
[0] https://crystal-lang.org/2014/06/19/crystal-0.1.0-released.h...
The main point was comparative age of languages. Like OCaml which is more than two decades old compared to Crystal which is young.
If you / most people don’t particularly like the Ruby-like syntax, then Crystal might not appeal to you. But I can assure you to those of us who like the syntax, the language is wonderful and super fun to work with.
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.
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.
- 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.
My point is that all this is normal, and all the languages I list have offered it for longer than Crystal.
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.
Nim - the most comparable, I guess it's syntax preference at that point
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.
Personally, I am learning it now, and I think rather than it being a stepping stone between OOP and FP, it might as well be its own separate and hybrid paragdim; I find purer FP languages like Haskell much more intuitive than the mix of modules, objects, types and classes of OCaml.
Though do not get me wrong, OCaml is an amazing language. It just stands rather by itself.
Pardon my terrible english.
[0] https://kotlinlang.org/docs/reference/native-overview.html
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 I use Crystal when I need to produce a standalone binary.
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.
What do these mean?
foo = ENV["FOO"]? || 10
I've noticed the slogan was change to "A language for humans and computers", what it really mean? Related to machine learning?
My impression that other than it was design to be as friendly as Ruby and fast as C. It's a lot helpful to have an FAQ if the Crystal team could provides.
As I see it, Go gets 70% of the attention, Rust 25% and Julia 5%. Crystal which doesn't have major backing (no Google, no Mozilla, and Julia has some MIT hackers behind it IIRC, plus the whole "data science" angle which is fashionable today), gets even less.
Kotlin and Swift have more obvious reasons for their adoption.