151–160 of 351 posts
I think any new programming language should have a "why?" section on their page. I mean obviously this language is serving a need, but what is it? In any case, congrats! I like the features and would like to give it a try some day. I'm still curious about the motivations of this particular language though. Anyone more familiar care to elaborate a bit? Edit: Ok, looks like there is a "why" section on github!
Earlier quoted context omitted.
The "downside" you forgot to mention a lot of important things: - tooling is abyssmal ( IDE etc ... ) - no mutli threading - no real support, I'm not even sure if there is one paid guy anymnore on the project - it's still immature - they break the API all the time
> - tooling is abyssmal ( IDE etc ... ) As others have mentioned this is a side effect of how young it is. > - no real support, I'm not even sure if there is one paid guy anymnore on the project If paid support is all that counts then most languages would fall into that. > - it's still immature Tautological. Nothing can become mature without first being immature. > - they break the API all the time Isn't that what a…
Do you make the same argument when someone serves you raw chicken?
Earlier quoted context omitted.
They "why" is basically having a language with the aesthetics and usability of Ruby, but fully statically typed with global type inference, and impressive performance. The downside being a relatively slow compiler. It's the necessary trade-off for the type inference.
The "downside" you forgot to mention a lot of important things: - tooling is abyssmal ( IDE etc ... ) - no mutli threading - no real support, I'm not even sure if there is one paid guy anymnore on the project - it's still immature - they break the API all the time
- no multi threading: Crystal has lightweight green threads for lightweight concurrency. However, Crystal does have experimental native multi-threading guarded by a compiler flag. The ultimate goal is to have multiple native threads each running multiple green threads for maximum concurrency. Currently, with just green threads, Crystal is competitive with Go or Rust wrt throughput. You can checkout benchmarks on crystal-lang.org or search Google for "Go vs Crystal benchmark" blog posts.
- no real support: Manas Tech is the corporate sponsor for Crystal (https://manas.tech/projects/crystal/) and employs many of the core developers; the project also accepts donations on Open Collective. There is a crystal-lang IRC channel, Gitter, Discord, Discourse forum, sub-reddit, and even a "Matrix" channel where developers frequently ask and answer questions.
- still immature: a 1.0.0 version is a significant milestone for any project. Companies are already running Crystal in production, which was discussed during the Raw Crystal 2020 virtual-conference (videos on YouTube).
- API breakage: Crystal 1.0.0 was released to stabilize the API (SemVer)
Earlier quoted context omitted.
It has a Nil type, not a Nil Value. So a function might return an Int or a Nil, but if you then try to, say, invoke a function expecting an Int on a Nil, it predictably blows up. An Int cannot be Nil itself.
To expand on that, Crystal's Nil goes hand-in-hand with its union types. So, if you want to allow a function's argument to be either an integer or nil, then the parameter type is "Int | Nil". It's not entirely unlike how algebraic data types with a "None" case work in the ML family of languages.
It feels like Crystal it took all the best things from the languages I love, and put them together into one, beautiful language: - Elegance of Ruby - Statically type checked + global type inference - No Nulls - Go-like concurrency - Easy C ffi - High performance I really hope the Crystal succeeds and the language goes mainstream - this release is a huge step forward towards that. Congrats to the Crystal team for reac…
Fast compilation times are one of the best things from the languages I love. I’d really love to see OCaml get true parallelism, green threads, and a decent HTTP server story. Then, I don’t think I’d look anywhere else.
Earlier quoted context omitted.
I think you mean 1 out of 4? Swift is the only one on that list that really feels tied to any particular platform. C# has been extremely portable for years now thanks to .NET Core. Even SQL Server runs on Linux these days, if you really just enjoy spending money. Java has always had a strong focus on portability, of course. Nim... I don't know much about. Doesn't it compile to C? I don't think it intentionally has an…
C# is tied to .net, and the cross-platform story on that framework is...complicated Java is tied to JVM Swift is tied to MacOS. Of course, with the exception of JVM, they are all nominally "cross-platform" in the OS sense of the word. But I haven't seen any substantial Linux/Mac .Net codebases yet, same with Swift on Windows
Crystal is a beautiful language, however compiling times is something that put off most people who try it. How comes and they don't allow you to optionally provide types in your function/class signatures so you can help the compiler and speed up the whole process ? I mean global type inference is nice, but giving the option to specify types and speeding up the compiling time would be even more nice.
Rust also has a very slow compiler but I also see ex-rubyists using it?
Huh - what's the last language that got mainstream adoption without backing from a large company? It almost seems impossible these days. Ruby?
Crystal is a beautiful language, however compiling times is something that put off most people who try it. How comes and they don't allow you to optionally provide types in your function/class signatures so you can help the compiler and speed up the whole process ? I mean global type inference is nice, but giving the option to specify types and speeding up the compiling time would be even more nice.
> How comes and they don't allow you to optionally provide types in your function/class signatures Perhaps you mean something else, but this is from the book Programming Crystal: > Returning Values > A method returns the value of its last expression, so there’s no need to explicitly return that or declare its type. However, if you want to document or directly control that return type, you can explicitly specify the t…
I would like Crystal compiler to take into account such definitions and speed up somehow. I know I am talking without experience, I just feel that coming from Ruby to Rust, declaring types on function definitions is not that much of a hassle.
As for other Ruby alternatives, I moved from Ruby to Elixir a few years ago. Immutable data and OTP more than make up for the language's lack of static typing in my mind. There is also Gleam, which I'm watching for now.
One of these days I'll dig into Rust, which fills a similar niche that Crystal would.