91–100 of 180 posts
Earlier quoted context omitted.
An ambiguous syntax is not elegant to program with. Is this a variable reference? Is it a method call? I dunno!
Wait - are we talking C/C++ here? where a function call, a variable declaration, an expression cast all look identical?
Earlier quoted context omitted.
What algorithm are you using? How do you deal with subtyping and paramatricity?
The algorithm isn't very easy to explain in a few words. We don't use any well-known algorithm. It has some bits of the cartesian-product algorithm, but just tiny bits. There's some info here: http://crystal-lang.org/2013/09/23/type-inference-part-1.htm... http://crystal-lang.org/2014/04/27/type-inference-rules.html About subtyping and paramtricity, I'm not sure what's that, but the compiler just keeps track of all t…
Earlier quoted context omitted.
Elixer and Erlang are not faster than go. The ability to respond in microseconds is a latency issue, not a raw speed issue. Erlang and Elixer can do that because of the way the core systems are architected but the underlying VM and language constructs are quite a bit slower than anything that Go has to offer. For maximum throughput out of a given chunk of hardware you'd want Go. Erlang / Elixer and the associated VM…
If we are talking about maximum throughput, then you want C++ and in my tests Java has been better than Go, .NET probably is better than Go as well - because when speaking of maximum throughput RAM becomes the biggest bottleneck. And as soon as you're talking about platforms with a non-optional GC, then we start speaking about the performance and predictability of that GC. Go doesn't bring improvements for managing m…
You can also control the size and number of objects your program creates, which impacts the performance of GC. Sure you can't pick a GC from a stack of GCs, but you do have many things in your hand to control how memory will behave.
I'm looking for something beautiful like Ruby but fast like Go. Do you think Crystal fits this bill? Also, are there packages/libs/gems for Crystal? What are they called? What do I google for? One of the major reasons why I dumped Go is that it's just too verbose and makes me write too much boilerplate code. I want to sort a collection and I have to write the same algorithm every single time for every single type. It…
The community likes to call a library as "shard", so I think we'll eventually end up using that name :-)
You can see a list of shards here: http://crystalshards.herokuapp.com/
For now that just lists GitHub repositories. Right now there's a very basic package manager that fetches repositories from GitHub, but it's too basic. Someone is working on a much better package manager ( https://github.com/ysbaddaden/shards ) that we'll probably incorporate in the future.
I don't understand why Ruby's syntax is seen as so elegant. It's ambiguous and a nightmare to parse. http://programmingisterrible.com/post/42432568185/how-to-par...
Ruby's syntax is very short and concise if you compare it to other languages. To know if "x" is a variable or a method you just need to see if "x" was assigned a value in the method, that's all.
Earlier quoted context omitted.
It's because we spent some time thinking the algorithms and optimizing them, and whenever we make changes to the compiler we make sure the times remain pretty much the same (it's hard because the compiler's size grows so the times inevitably grow, at least for the compiler). And from time to time we profile and optimize further, we like speed. I believe with time Rust can achieve a similar performance, maybe even bet…
> most of the things in Crystal are lazy: if you don't invoke a method there are no type checks to be done for it Does this mean that if a library doesn't have complete test coverage compile-time errors could be discovered only by clients?
typeof(MyClass.new.some_method(1, 2, 3))
That basically says "the above compiles and has some type", so you don't have to test what that method really does, just that it compiles.
I don't think it's a big problem, though. In Ruby it's the same: unless you exercise your code you don't know if it works. Now, think of a classically compiled language like C and C++: if it compiles, does it mean that it works? I doubt you'd release your code without at least a few tests (or a small test-app) to try it.
Earlier quoted context omitted.
I don't see a reasons for null to exist in a new language in 2015.
How do you model a "zero or one" relationship without null? Maybe your answer is "with Optional" (or Option, or Maybe). We just choose to use union types and have "Nil | T" (Nil or T) be the same as "Option(T)" in other languages.
With something that leaves "Nullpointer analysis" obsolete/useless.
Earlier quoted context omitted.
I don't see a reasons for null to exist in a new language in 2015.
How do you model a "zero or one" relationship without null? Maybe your answer is "with Optional" (or Option, or Maybe). We just choose to use union types and have "Nil | T" (Nil or T) be the same as "Option(T)" in other languages.
Earlier quoted context omitted.
Elegant to program with. Not write a parser for.
An ambiguous syntax is not elegant to program with. Is this a variable reference? Is it a method call? I dunno!
Neither. It's a message sent to an object. The object decides how to respond to that message.
Caring about the implementation of the message receiver breaks information hiding. If you have to distinguish between .message and .message(), you already know more than you need to know to interact with that object.
Every language is confusing until you understand the mental model (even if you disagree with the utility of that model). If you come to Ruby thinking in Java/C++/C terms, you'll be unhappy, because the mental model is very different.
For Ruby, the book to read is The Well-Grounded Rubyist, which makes the language quite obvious.
Earlier quoted context omitted.
Indeed it's becoming quite promising (using crystal already for few pet scripts which were too slow even for rubinius). Where it's most lacking at the moment is gc - it uses stop-world off the shelf boehmgc which is ok but not exactly great for memory heavy tasks.
imho, starting a new language with Boehm GC is a very bad design choice. It means, that one just allocates memory, and does not care for managing it. Even worse, it prevent linking any library, e.g. a 2nd thread running Lua+C, that cares for its own memory, because Boehm GC runs over the complete memory, not only the one the language has to manage. You basically need 3 types of memory: First for the objects in your l…
Eventually we can write our own GC or use another one. It's only a matter of time. But right now there are more important things, we think: finishing the language rules, stabilizing things, fixing bugs, completing the standard library and writing documentation.
Nothing is set in stone in a language, things can always evolve and improve.