<FromGitter>
<jots_twitter> on `Crystal 0.20.0 [b0cc6f7] (2016-11-22)` if I do `crystal init app blah` the shard.yml file says `crystal: 0.19.4` anything to worry about?
akwiatkowski has quit [Ping timeout: 264 seconds]
<FromGitter>
<raydf> nop
<FromGitter>
<raydf> you'll keep compiling the lib or app with the current crystal installed version
<FromGitter>
<cjgajard> @samueleaton #1294 explains whats happening there. `[MyClient.new, MyClient.new] of MyProtocol::MyInterface` makes it work (because when you are using an array literal it get infered to be the "smallest" type it can, so you need to force it to use a bigger type)
soveran has quit [Remote host closed the connection]
<RX14>
hi
<FromGitter>
<andreaTP> @RX14 I finally read the article you link thanks a lot, but that does mean that every time you compile a program even the whol stdlib is compiled
<RX14>
yep
<RX14>
but it's super fast anyway
<FromGitter>
<andreaTP> so the question become how to redistribute libraries? via sources?
<RX14>
yes
<FromGitter>
<andreaTP> uhmm thanks for the explanation!
<RX14>
@andreaTP crystal will eventually have incremental compilation to help compile times
<RX14>
the compiler itself is a very big crystal program, and it only takes ~15 seconds to do type analysis for
<RX14>
then another ~15 seconds to emit native code and link
<FromGitter>
<molovo> @Nulldata it doesn’t work with class variables. You’ll need to assign it to a local variable, and then compare against that. Quick rough example base on your code: ⏎ ⏎ ``` code paste, see link``` [https://gitter.im/crystal-lang/crystal?at=585a646e61e516c1578e8ec3]
<Nulldata>
Ah, thanks. Is there any plans on actually making it work with instance variables?
<RX14>
no, it's a feature
<RX14>
that it doesn't work
<RX14>
another thread could change the value of an instance variable inbetween the type check and you using it
<RX14>
so the only way to be sure that the type is correct is to make a local copy of it
<FromGitter>
<molovo> @RX14 Ah, that’s quite a bit nicer to write. I always thought the `.nil?` call had to be explicit. Good to know
<Nulldata>
Oh yeah, I'm too used to the thread safety model of Rust. Makes sense
<RX14>
you don't need .nil? unless you can get a falsey value which isn't nil
<RX14>
i.e. false
<Nulldata>
too*
<RX14>
if it can be false or nil you need .nil? to disambiguate
<RX14>
otherwise you can reply on nil's falsiness
<FromGitter>
<molovo> @RX14 makes total sense
<RX14>
rely*
akwiatkowski has quit [Ping timeout: 264 seconds]
<Nulldata>
I'm kinda ideologically opposed to other values than booleans being treated as truthy and falsey, so I try to keep my conditions explicit :P
<Nulldata>
But thanks for the tip anyway :)
bjz_ has quit [Max SendQ exceeded]
bjz has joined #crystal-lang
<FromGitter>
<molovo> Actually, in that instance I think you'd need to be explicit, since `lowest_time_left` could be `0`
<splitty_>
RX14, I've taken a look at that kernel. It's very basic and my kernel already has more features, so I can't really use it as a reference :)
<RX14>
ok
user9998_ has joined #crystal-lang
user9998 has quit [Ping timeout: 245 seconds]
<FromGitter>
<asterite> splitty: you might need to re-implement some methods from static array... well, just copy-paste them into your program. Right now the std isn't though much to be used without the rest of the std (like, StaticArray includes Enumerbale and Iterable, like RX14 mentioned)
user9998_ has quit [Read error: Connection reset by peer]
user9998 has joined #crystal-lang
<FromGitter>
<asterite> Method never have "magic", StaticArray#[]= just uses pointer and assignments. The only methods that have "magic" (well, hardcoded to LLVM instructions to a bunch of instructions) are in primitives.cr
<splitty_>
FromGitter, yeah I'll see if I can copy/paste some methods from StaticArray
akwiatkowski has quit [Read error: Connection reset by peer]
akwiatkowski has joined #crystal-lang
Raimondi has joined #crystal-lang
<FromGitter>
<molovo> @firejox that looks like it could be useful. Any chance you could publish it as a library?
soveran has quit [Remote host closed the connection]
<Yxhuvud>
firejox: Hmm, there was a really good in depth article on the building blocks behind async on HN a week or so ago, written by one of the implementors, but I can
<Yxhuvud>
't find it again :(
<FromGitter>
<firejox> @molovo yeah, I would do it in the future.
<FromGitter>
<andreaTP> Is there any effort on the actor model? 32k fibers looks limiting IMO
<RX14>
yeah it is quite limiting
<FromGitter>
<andreaTP> I mean scheduling executions on top of a thread pool is quite common I.e. in Akka for Scala
<RX14>
hopefully we can find away around the limit
<RX14>
number of fibers hasnt been really been optimized at all
<FromGitter>
<andreaTP> And actors are object themselves :-)
<FromGitter>
<andreaTP> Fibers in Crystal looks like coroutines at a first glance, is that true?
<RX14>
yes
<RX14>
they're cooperatively scheduled coroutines
<RX14>
which works very well for io-based workloads
<FromGitter>
<andreaTP> I believe, but not for concurrency and distribution
<RX14>
what do you mean? coroutines enable concurrency in crystal
<RX14>
maybe you mean parallelism
<FromGitter>
<andreaTP> @RX14 do you know any library implementing actor model here around?
<RX14>
not aware of one
<RX14>
i've thought of doing it
<RX14>
but I would use 1 fiber per actor anyway
<RX14>
and let crystal schedule fibers onto a threadpool when that's implemented
<FromGitter>
<andreaTP> I mean transparent execution of concurrent tasks like "method calls" in another programming language
<FromGitter>
<raydf> Do you have a real scenario with 100,000 http connections per second for 1 server?
<RX14>
benchmarking
<RX14>
is a pretty real-world scenario
<FromGitter>
<andreaTP> It sounds like I've found a project to let me go in depth in Crystal :-)
<FromGitter>
<andreaTP> I do not care HTTP connections themselves
<FromGitter>
<raydf> In my experience you'll have the database bottlenecking the app before the http server
<Papierkorb>
raydf, 100k requests/sec is reasonable to expect, if you're only sending off static data, the only limit should be the max file handle count
<FromGitter>
<raydf> maybe for stats analyzing or something similar
<FromGitter>
<andreaTP> the problem is to properly manage concurrency at any level
<FromGitter>
<andreaTP> What about distribution?
<Papierkorb>
to what?
<RX14>
@raydf the spawns per second * fiber running length is what matters for hitting the fiber limit
<FromGitter>
<andreaTP> Of fibers on a network
<Papierkorb>
huh?
<FromGitter>
<andreaTP> I mean Actors here :-)
soveran has joined #crystal-lang
soveran has quit [Changing host]
soveran has joined #crystal-lang
<FromGitter>
<andreaTP> Transparent communication between fibers let you spawn on the same machine if possible or on the network In a cluster otherwise
<FromGitter>
<andreaTP> And the primitives needed to do that are pretty limited
<Papierkorb>
Um, before even thinking if we want that complexity monster in the stdlib (wtf?), real threading would be nice..
<crystal-gh>
[crystal] asterite closed pull request #3749: Allow Time::Span to be divided by Time::Span (master...feature/timespan-divide) https://git.io/v1p0f
<crystal-gh>
[crystal] asterite pushed 1 new commit to master: https://git.io/v1p0t
<crystal-gh>
crystal/master 5ca344e Sijawusz Pur Rahnama: Add :nodoc: to Class#crystal_instance_type_id
<FromGitter>
<andreaTP> But I like this discussion please go on, it looks like Crystal is mainly intended to handle server code for web app and this is what it is optimized on
<FromGitter>
<raydf> Do golang have any example of this kind of performance with go corrutines?
<Papierkorb>
andreaTP, I'm not using Crystal for webapp stuff at all
<Papierkorb>
And the language is neither "optimized for it"
<FromGitter>
<andreaTP> I started programming in scala because of native actors implementation it is not a monster pretty simple and powerful IMO
<Papierkorb>
Like the SNES emulator, operating system kernel and torrent stuff is. Shits fast, yo
<RX14>
1 million per minute?
<RX14>
its not really that fast
<FromGitter>
<andreaTP> @Papierkorob so it seems that concurrency is managed at a low level respect the rest of the lang that is really high do not you think so?
<RX14>
especially as go is multithreaded
<FromGitter>
<raydf> They solved it using a work job scheduler with channels
<FromGitter>
<raydf> that's why i'm asking about the simple usage of spawn
<Papierkorb>
andreaTP, mh? What's bad about fibers? when there's a thread pool, programs will be multi-threaded by default, you just spawn something you want to do concurrently. And they're not as expensive as Threads, way less so
<FromGitter>
<andreaTP> Akka uses a Thread pool under and so does Erlang
<FromGitter>
<andreaTP> I mean Actors normally have 300 KB of memory footprint fibers here is 8 MB
<Papierkorb>
300Kib?!
<Papierkorb>
Fibers are 4KiB each
<FromGitter>
<andreaTP> This is simply different
<FromGitter>
<andreaTP> What is 8 MB about so? Sorry maybe I miss it
<RX14>
well the amount of memory a crystal fiber uses is dominated by it's stack size
<Papierkorb>
Many people today who're confusing virtual memory with memory usage. Looks like the docs should mention that.
<RX14>
crystal fibers have a maximum stack size of 8MiB
<RX14>
but at the beginning they will only be 1 page
<FromGitter>
<andreaTP> Aaaaaaa
<RX14>
i.e 4KiB
<RX14>
so creating a crystal fiber involves instantiating a singla class
<FromGitter>
<andreaTP> I really think this should be mentioned in the docs :-)
<RX14>
then creating (or checking out from the pool) a stack
<RX14>
well
<RX14>
fibers are sort of low level
<Papierkorb>
andreaTP, knowing about virtual memory is "common knowledge" to some.
<RX14>
you're not meant to know how they work
<FromGitter>
<andreaTP> Now everything looks much more reasonable
<RX14>
just "use spawn"
<RX14>
the best advice is basically use spawn and channels
<RX14>
and then
<RX14>
optimize later
<FromGitter>
<andreaTP> I know about virtual memory but docs talk about memory itself and doesn't mention that 8mb is the bound
<Papierkorb>
*scrolls through actor docs* doesn't look much different to the spawn/channel combo
<FromGitter>
<andreaTP> It is not indeed
<FromGitter>
<raydf> Actors can be distributed by network i believe?
<FromGitter>
<raydf> at least in akka
<RX14>
yeah thats basically the difference
<FromGitter>
<andreaTP> To a complete implementation probably just managing mailboxes isn't kind of standard yet
<RX14>
they're a bit more restricted in how they're created I think
<FromGitter>
<andreaTP> Even in Erlang
soveran has quit [Remote host closed the connection]
<RX14>
so that they can be placed around a cluster
<FromGitter>
<andreaTP> The abstraction will take care about distribution
<Papierkorb>
What magic do they do to know if it's actually worth sending the actor off to some other machine?
<FromGitter>
<andreaTP> It is usually explicit, Akka cluster is an extension to the base system that hides this to the user
<FromGitter>
<andreaTP> But the basic ideas are simply three spawn new actors (usually intended like you do with object creation I mean without care about 'how many')
<FromGitter>
<andreaTP> Pass messages to other actors
<FromGitter>
<andreaTP> And let actors change their behavior
<FromGitter>
<andreaTP> That could be covered with what already is in the language I think
<RX14>
well actors are objects in akka aren't they?
<RX14>
whereas in crystal they're basically arbitrary code with a start and end point
<FromGitter>
<andreaTP> Hard to answer :-) properly I mean
<RX14>
you can't send a message to a fiber in crystal
<FromGitter>
<andreaTP> Actor is the original object oriented model
<RX14>
you could use a channel to send a message and recieve it in the fiber
<FromGitter>
<andreaTP> CSP can handle communication and fill queues right?
<RX14>
communication in CSP is basically channels
<RX14>
you have unbuffered and buffered channels
<RX14>
and you can send objects down channels
akwiatkowski has quit [Ping timeout: 264 seconds]
<FromGitter>
<andreaTP> Right so you can use channels to fill mailboxes and fibers to schedule execution of concurrent behaviors of actors
<RX14>
i'm not quite sure what mailboxes are
<FromGitter>
<andreaTP> Queues
<RX14>
oh yeah that would be like a buffered queue
bjz has joined #crystal-lang
<FromGitter>
<andreaTP> Yup
<RX14>
in erlang is there one mailbox per actor? can they be created by themselves?
<FromGitter>
<andreaTP> Yes one mailbox per actor
<RX14>
interesting
<RX14>
erlang sounds more restrictive compared to CSP
<RX14>
however that's probably what allows it to do all it's cluster fanciness
<FromGitter>
<andreaTP> No distinction between mailbox and actor itself since it is a "property" of the actor
<RX14>
interesting
<FromGitter>
<andreaTP> What really differs is that you do not have concurrently access to memory
<FromGitter>
<andreaTP> That is kind of limiting in some sense
<FromGitter>
<andreaTP> But result in much more reliable and easy to develop/debug software
<FromGitter>
<andreaTP> And this is why Elixir is going so far :-)
<FromGitter>
<andreaTP> Anyhow I really hope to find time to be around and poke about implementing Actors in Crystal
<RX14>
yeah
<RX14>
sometimes restrictions make for better software
<RX14>
however crystal is a lot more general purpuse than erlang I think
<RX14>
you wouldn't really make a desktop application in erlang
<RX14>
although erlang's usecase is pretty common to be fair
<FromGitter>
<andreaTP> I will say they have different runtime :-)
pawnbox has quit [Remote host closed the connection]
<FromGitter>
<andreaTP> Beam is great for distribution
<FromGitter>
<andreaTP> And LLVM is great for generating assembly
<FromGitter>
<drosehn> fwiw: I also use crystal for *non*-web development. I don't do any web development at all (not in any language).
<FromGitter>
<andreaTP> So, if I could ask, what is the main purpose why Crystal have been created for?
<FromGitter>
<drosehn> I have a chat server written in LambdaMOO, but that's been around for 20 years or so. I'd like to rewrite that (because almost no one knows the language), but if I did I'd probably try to do it in erlang or elixir.
<FromGitter>
<andreaTP> Or at least the most common use case out there
<FromGitter>
<drosehn> "faster ruby". :smile:
<RX14>
well I wouldn't say that crystal was made specifically for a use case
<FromGitter>
<andreaTP> No please
<RX14>
but most of the current people who come over from ruby are web developers
<RX14>
i would say that web devs are currently the largest portion of crystal's userbase
<FromGitter>
<sdogruyol> that also what happened to Go
<FromGitter>
<sdogruyol> started as a systems language wannabe
<RX14>
however it's a lot more balanced for the actual crystal contributors I think
<RX14>
yeah I don't think go is a particularly good web language myself
<FromGitter>
<drosehn> A faster language is obviously better for deploying web apps, but that doesn't mean it's limited to web apps. I do notice that many crystal programmers are doing web apps, but there's nothing about crystal which makes it a problem for the projects that I want to use it for.
<FromGitter>
<andreaTP> I do not think that changing code syntax is a problem nowadays....
<FromGitter>
<sdogruyol> imho Crystal is suitable for more stuff
<FromGitter>
<sdogruyol> needs more love though :P
<FromGitter>
<andreaTP> :-)
<FromGitter>
<sdogruyol> @andreaTP it's not the syntax but the best practices, knowledge e.g
<FromGitter>
<sdogruyol> @andreaTP well it takes time to get productive. For me (as a Rubyist) Crystal is productive from day 0
<FromGitter>
<sdogruyol> isn't that a big win? (or just me)
<FromGitter>
<andreaTP> To be honest I really REALLY liked Crystal because it looks like a reasonable language with good foundation choices
<FromGitter>
<andreaTP> I come from a really different background and dynamic typing of Ruby always looks unsound
<FromGitter>
<sdogruyol> @andreaTP yeah, it's really well thought from the ground up. Have you ever tried to read the Crystal compiler and std (it's also written in Crystal, IMHO it's awesome)
<FromGitter>
<andreaTP> It's less than 48 hours that I'm involved :-)
<FromGitter>
<andreaTP> I will :-)
<FromGitter>
<sdogruyol> you'll feel at home :P
<RX14>
I do prefer static typing to dynamic typing...
<FromGitter>
<sdogruyol> i tried and failed every time i wanted to read C Ruby source :/
<RX14>
every time I use dynamic languages i sort of feel dirty unless my specs are 4 times longer than themethod
<FromGitter>
<sdogruyol> yet i really like reading Crystal source
<RX14>
whereas in crystal I have a lot of confidence if the code just compiles
<FromGitter>
<andreaTP> Probably documentation could be a bit better I'm learning faster from blog posts than from getting started to be honest
<RX14>
docs are good for the language itself
<RX14>
but the stdlib docs could use a lot of work
<RX14>
the basic classes are documented really well but you do end up reading source sometimes
<FromGitter>
<andreaTP> Structural types are not mentioned....
<FromGitter>
<andreaTP> This IS a problem IMO
<RX14>
but structural types don't exist
<RX14>
any structual typing in crystal is simply a byproduct of the type system and type inference as a whole
bjz has joined #crystal-lang
<FromGitter>
<andreaTP> They are in practice
<FromGitter>
<sdogruyol> @andreaTP can you give an example?
<FromGitter>
<andreaTP> Ugh not from the phone right now @RX14 yesterday link me a blog post that explains the concept well
<FromGitter>
<andreaTP> Sorry @sdogruyol
<FromGitter>
<andreaTP> And moreover please add static typing to bullet points :-)
bjz has quit [Client Quit]
<RX14>
it's on the front page of crystal-lang.org ...
<FromGitter>
<andreaTP> I miss Ecoop talk on Crystal 2 years ago because of that :-)
<FromGitter>
<andreaTP> Ugh yes , my bad @RX14
<FromGitter>
<andreaTP> Anyhow really pleasant to speak here around with you thanks!
<FromGitter>
<andreaTP> Could I ask right now how is the situation of Crystal itself development? How many people involved, if any payed for etc. etc.
<RX14>
it's essentially @asterite's project
<RX14>
well
<RX14>
originally
<RX14>
and his employer manastech funds crystal development a bit I think
<FromGitter>
<drosehn> note the link to bountysource on crystal's home page https://crystal-lang.org
soveran has quit [Remote host closed the connection]
Philpax has joined #crystal-lang
akwiatkowski has joined #crystal-lang
dhk has quit [Quit: Leaving]
Philpax has quit [Ping timeout: 248 seconds]
soveran has joined #crystal-lang
soveran has quit [Ping timeout: 256 seconds]
mgarciaisaia has quit [Quit: Leaving.]
<crystal-gh>
[crystal] ysbaddaden opened pull request #3750: Sockets refactor: allow any family/type/protocol association (master...std-sockets-refactor) https://github.com/crystal-lang/crystal/pull/3750