Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Crystal 1.0 – What to expect

crystal-lang.org

Post reply on HN
Print view View original

341–350 of 351 posts

Re: Crystal 1.0 – What to expect

#341

Post by cbkeller »

forgotpwd16 wrote: post #294
ksec wrote: post #271

Earlier quoted context omitted.

And Julia as well.

Julia if anything is unlike Ruby. The very first Ruby example on the official site showcases its object-oriented nature. Julia instead of objects has multiple dispatch.

On one hand you're absolutely correct in that Julia is dispatch-oriented, and doesn't have ton in common with what is commonly considered OOP today.

However, as far as I understand it there is also an argument to be made that multiple dispatch is at least as close to Alan Kay’s original intent for OO (e.g. [1]) than is the currently-ubiquitous class-based version of OO that leads to things like `RequestProcessorFactoryFactory` s with `RequestProcessorFactoryFactory.getRequestProcessorFactory(Class)` methods.

[1] https://medium.com/javascript-scene/the-forgotten-history-of...

Re: Crystal 1.0 – What to expect

#342

Post by The_rationalist »

ezrast wrote: post #335
The_rationalist wrote: post #307

Earlier quoted context omitted.

Interesting, could you characterize some of what make it more enjoyable?

Kotlin is indeed very Crystal-like, and I enjoy both languages, but I really miss union types in Kotlin, as well as deeper type inference. For example, in Crystal you can write def foo_then_bar(a, b) a.foo b.bar end and it will just work for any two types that implement `foo` and `bar`, respectively. This isn't something I do often - I like the clarity that type-annotated parameters give - but it's a really nice feat…

Thanks for the example, that's interesting.

Note that Kotlin has union types through this compiler plugin: https://github.com/arrow-kt/arrow-meta/issues/570 However it is experimental and shouldn't yet be used in production. Btw sealed classes take care of many uses of union types.

What kind of extra work is needed? I'd say that graal native is transparant for any library that doesn't do weird use of reflection but it's true that many libraries do abuse of reflection.

Re: Crystal 1.0 – What to expect

#343

Post by ezrast »

The_rationalist wrote: post #342
ezrast wrote: post #335

Earlier quoted context omitted.

Kotlin is indeed very Crystal-like, and I enjoy both languages, but I really miss union types in Kotlin, as well as deeper type inference. For example, in Crystal you can write def foo_then_bar(a, b) a.foo b.bar end and it will just work for any two types that implement `foo` and `bar`, respectively. This isn't something I do often - I like the clarity that type-annotated parameters give - but it's a really nice feat…

Thanks for the example, that's interesting. Note that Kotlin has union types through this compiler plugin: https://github.com/arrow-kt/arrow-meta/issues/570 However it is experimental and shouldn't yet be used in production. Btw sealed classes take care of many uses of union types. What kind of extra work is needed? I'd say that graal native is transparant for any library that doesn't do weird use of reflection but i…

Having to install and set up third-party pre- and post-processors is the extra work I mean. I'm sure it's not super difficult, but it's also not very accessible to those like me who aren't already familiar with Java tools. The documentation seems to assume I'm slightly competent with Maven or Gradle, etc.

I did try Kotlin/native hoping it would make it easier to remain in blissful ignorance of the JVM ecosystem, but as of a year or two ago it had significant holes in the standard library (most notably no file abstractions other than thin bindings to libc) and pretty atrocious compile times (something like 10s for hello world, and 30+ for a couple thousand lines of code).

Re: Crystal 1.0 – What to expect

#344

Post by maattdd »

filleduchaos wrote: post #322
maattdd wrote: post #317

Earlier quoted context omitted.

It's possible, just not officially supported nor straightforward. You need to run the GC yourself and all this kind of stuff. https://stackoverflow.com/questions/32916684/can-a-crystal-l... https://gist.github.com/Papierkorb/02d6ba53c28b5035a80bf7695...

It's not officially supported yes but having actually done it multiple times for multiple projects I don't see how it's not straightforward. - You do the linking yourself, so that you can pass the flags to produce the kind of library you want. This is something the Crystal compiler helps with (it spits out the LDFLAGS that you need). - Calling `GC.init` when your library is loaded if you want to use garbage collectio…

You also need to handle the event loop yourself ; otherwise you end up using a language which is sub-Crystal.

Re: Crystal 1.0 – What to expect

#345

Post by aryehof »

sjwright wrote: post #192
pansa2 wrote: post #117

Earlier quoted context omitted.

> I’ve never declared a variable and not simultaneously thought “this is going to be a float, always a float, never not a float.” Never written generic/template code? Making that much easier is one of the main benefits of dynamic typing.

It's possible—nay likely—that I don't understand the true value of generics. It's something that I've looked into on occasion and it never seemed all that useful to me. Most examples I've come across in the past were C++ and seemed like formalised workarounds for deficiencies in the C++ type system rather than being actually useful. I'm sure I've failed to grok them—or based on the code I write I'm not the target aud…

The classic use case for generics is when creating Abstract Data Types. Implementing stacks, queues, dynamic arrays etc of differing Types is made relatively simple using generics.

Re: Crystal 1.0 – What to expect

#346

Post by pantulis »

atleta wrote: post #315
pantulis wrote: post #256

Earlier quoted context omitted.

Also, this observation: in terms of developer time, compiled languages (a la Crystal, Go, Rust...) the disadvantage of compile time should be offset by much faster local test runs and even CI builds.

You'll usually just run a few tests if you are working on a specific feature and only run more of them when you think you are done. So most of the time there will be too little difference to make up for the increased compilation time. Also, you are comparing compiled languages to interpreted ones, but the GP talked about differences between compilation time (i.e. compiled languages). And others are also comparing it…

You are totally right.

Re: Crystal 1.0 – What to expect

#347

Post by exikyut »

exikyut wrote: post #312
unixhero wrote: post #237

Earlier quoted context omitted.

Why is that important given Moores law and fast developer workstations? Everyone seems so preoccupied with compile speed for Crystal.

Well, I have ADHD. I've found the most effective approach (on top of treatment) that helps me retain focus is reexec-on-save, a la `while :; do tput clear; $thing; inotifywait -q -e moved_to .; done`. I usually have a dozen of those in old shell histories (^R FTW). (Ha, my laptop actually has exactly 12, and my other machine has 23 - although ignoredups is off...) $thing might be `bash ./script.sh` (because my text e…

For the sake of pedantic completeness: sigh, not "68,000 PDFs/sec" (that would be nice lol), more like "68,000 PDFs in 34 seconds". At the bit near "1600MHz RAM".

Re: Crystal 1.0 – What to expect

#348

Post by filleduchaos »

maattdd wrote: post #344
filleduchaos wrote: post #322

Earlier quoted context omitted.

It's not officially supported yes but having actually done it multiple times for multiple projects I don't see how it's not straightforward. - You do the linking yourself, so that you can pass the flags to produce the kind of library you want. This is something the Crystal compiler helps with (it spits out the LDFLAGS that you need). - Calling `GC.init` when your library is loaded if you want to use garbage collectio…

You also need to handle the event loop yourself ; otherwise you end up using a language which is sub-Crystal.

What do you mean by "handle the event loop yourself"?

Again, have you ever actually tried to do this or are you just speculating?

Re: Crystal 1.0 – What to expect

#349

Post by mega-tux »

the_duke wrote: post #212
socialdemocrat wrote: post #171

Earlier quoted context omitted.

Does languages don’t belong together. Java and C# sure. They use sophisticated garbage collectors and target intermediate code. Nim, Crystal and Swift all compile to native code and is designed for that. Swift is not a GC language in the normal sense since it uses automatic reference counting. That is fully deterministic and with low latency. There is no stop the world to collect garbage like with Java and C#. Swift…

You can group languages in different ways. VM vs native is one way, but you can also go by the level of abstraction they provide, which very much puts them in the same category. Also, this debate comes up every time, but ARC is widely classified as a form of garbage collection, just not a tracing one. It is transparent and automatic to the user. (Well, apart from cycles)

Nim is also working on ARC https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

Re: Crystal 1.0 – What to expect

#350

Post by mathgladiator »

yxhuvud wrote: post #91
mathgladiator wrote: post #63

Earlier quoted context omitted.

Wow, this is a great compilation! While I'm not using Crystal, this is a great "marketing plan" for any new language.

Däng, that posted the list, is a moderator. It is probably pretty safe to say he is posting the list for the sake of curious readers rather than for marketing purposes.

Yes, and I should have been more clear. For anyone making their own programming language, the list from Dang is... amazing.
Post reply on HN