[jgillich]

I've found that Go is not elegant enough for me and Rust is too difficult to write (I started using Rust in 2015 and after years of trying I eventually realized Rust doesn't make sense for most apps), so I'm all in on Crystal. Despite not having much prior Ruby experience, I absolutely love the language.

[pizza234]

Crystal doesn't have built-in support for parallelism, let alone production-grade support. This is a significant lack for a modern language.

For a language that is around 8 years old, this may be a serious problem, since the surrounding ecosystem has been probably written without parallelism in mind, and it may take a very long time to be updated (if ever).

[npn]

> Crystal doesn't have built-in support for parallelism

They do, but it is hidden inside a compiler flag, if you compile your prject with `Dpreview_mt` then it will come with multi-threaded support. This has been an experimental feature for a few year though, and there is not much improvement since it first got introduced.

Personally I don't use crystal for this kind of feature, and it runs stable enough when I use it for some cpu intensive tasks when I rarely need it.

Crystal really shines when you need something that you usually write a python/ruby script to do, especially for tasks that run for hours. Converting some script from ruby to crystal and run it in production mode typically reduce the time consumed to 1/5 or even 1/10 of the original depends on the job. As someone who have to read gigabytes of text files regularly, Crystal is currently the best one for the task.

The compilation time for released binary is something need much improvement though. And I'm not sure if they can even achieve incremental compilation.

[pizza234]

> hey do, but it is hidden inside a compiler flag, if you compile your prject with `Dpreview_mt` then it will come with multi-threaded support

It depends on the domain. From a production perspective, an flag-gated functionality that has been experimental for two or more years, is not "built-in". Plus, as explained, the ecosystem (I think I've read even the stdlib) doesn't give guarantees about thread safety

For small-scall scripting, then sure, it could be useful - but anything will do. I've evaluated for use at my company, and discarded it, because of the lack of libraries. Sadly, this is a chicken-and-egg situation. I've also evaluated contributing to it, but I won't until multithreading is stable.

[npn]

> I've evaluated for use at my company

Well this might be the problem. In corporate environment you can't afford to be too adventurous.

Personally I solve the "lack of libraries" problem by using more than one language, then connect them via child process call or some persistent storage like database or plain text files.

But it's entirely a different matter when the code need to be used by a lot of people.

[sanxiyn]

I use PyPy for such cases. Is Crystal better than PyPy?

[npn]

I think Crystal is better than Python in term of language design. Unlike Ruby and Python that were way older, crystal is relatively new, so they learned from other languages mistake and try to improve it, result in a more cleaner language.

For the cases mentioned, I think crystal is immensely helpful: - Reading/writing files are easy, usually a single method will give you the result you want. - Working with directories are nice, things like `Dir.mkdir_p`, `Dir.each_child`, `File.exists?`... all existed to make your life easier. - Like ruby, you can invoke shell command easily using backticks - There are some useful libraries to for console app, like `colorize` or `option_parser`. Crystal is a battery included language, so the standard library is filled with useful libraries. - Working with lists and hashmaps is a breeze, since the Enumerable and Iterable modules are filled with useful methods, mostly inspired from ruby land. - Concurrent is built in, so you can trivially write performant IO-bounded tasks like web crawlers.

For a project that made by a handful of people, I just can't praise the dev team enough for making a language this practical.

[zozbot234]

Modern Rust is much more straightforward than it was in 2015. It's effectively two different languages, albeit maintaining backward compatibility (i.e. code written for Rust 1.0 should still compile today, with proper edition settings).

[bscphil]

Suppose I wanted to try learning Rust again; is there a resource for someone with a lot of (hobbyist) programming experience, and experience with low level languages and memory management (e.g. C), but not complicated low-level languages, like C++?

When I tried to work with Rust a few years ago I found it utterly impenetrable. I just had no idea what the borrow checker was doing, did not understand what the error messages meant, and honestly couldn't even understand the documentation or the tutorials on the subject. Understanding what is happening in C or Zig is pretty easy; in Rust it's always been a nightmare for me. I just really don't grok the "lifetime" concept at all, it feels like I'm trying to learn academic computer science instead of a programming language.

Rust feels to me like a powerful, expressive language for professional programmers at the top of their game. That's a complement for any language. But it comes at the cost of mind-numbing complexity for anyone who's not an expert.

[zozbot234]

> Suppose I wanted to try learning Rust again; is there a resource for someone with a lot of (hobbyist) programming experience, and experience with low level languages and memory management (e.g. C), but not complicated low-level languages, like C++?

The official Rust book is targeted at novices with some programming experience. There's also Rustlings https://github.com/rust-lang/rustlings for a more practical approach.

> When I tried to work with Rust a few years ago I found it utterly impenetrable. I just had no idea what the borrow checker was doing, did not understand what the error messages meant, and honestly couldn't even understand the documentation or the tutorials on the subject

The compiler diagnostics have improved a lot over time. It's quite possible that some of the examples you have in mind return better error messages.

> in Rust it's always been a nightmare for me. I just really don't grok the "lifetime" concept at all, it feels like I'm trying to learn academic computer science instead of a programming language.

Academic computer science calls lifetimes "regions", which is perhaps a clearer term. It's a fairly clean extension of the notion of scope that you'd also find in languages like C or Zig. It's really not that complex, even though the Rust community sometimes finds it difficult to convey the right intuitions.

[bscphil]

Fair enough, I do need to have a look at the book again, although that was one of the sources I found impossible to understand a few years back. I think there's a temptation to talk about lifetimes in extremely abstract terms under the assumption that the reader already understands and appreciates the abstraction. I, however, was never able to build up an intuition for it, and so tutorials that didn't explain what was happening in detail sailed over my head.

[lijogdfljk]

I second zozbot234's statement about it being far better than it was in those days.

The language team has done a great job rounding rough edges, and this next roadmap is slated for even more polishing. They heavily prioritize dev experience which is why i think people like myself (a GC'd language person historically) use and love Rust so much.