<FromGitter>
<stronny> if unspecified the compiler would try to infer the return type
<FromGitter>
<stronny> generic functions have multiple possible argument types
<oprypin>
stronny, that's not entirely accurate
<oprypin>
kiti-nomad, yes, every function is fully generic on its arguments
<FromGitter>
<stronny> well I meant unions as types here
<oprypin>
type annotations only restrict what kind of type you can pass (i.e. they can cause an error if you pass something wrong) but otherwise have no effect at all
<FromGitter>
<vlazar> hm, 20 minutes to generate docs is a lot
<FromGitter>
<stronny> could you elaborate on the distinction? what other effect could a type resriction have?
<oprypin>
well, like saving the work having to infer the types, which it doesn't
<FromGitter>
<stronny> I'm still unclear but okay
<FromGitter>
<dscottboggs_gitlab> in C/C++ terms, all crystal functions are virtual. Even if the type is specified, it's still a template function. That is, there's no difference to the compiler whether a type passed as an argument is only ever T because the programmer never passed anything but T, or whether the programmer specified `arg : T`. The part where type restrictions are verified doesn't affect the part where machine code is
<FromGitter>
... actually generated, it just gives us better error messages basically
<FromGitter>
<stronny> virtual functions are about vtable though, runtime dispatch etc.
<FromGitter>
<stronny> what I get is every `def` is a template
oz has quit [Quit: EOF]
postmodern has joined #crystal-lang
DTZUZU has quit [Ping timeout: 265 seconds]
oz has joined #crystal-lang
DTZUZU has joined #crystal-lang
alexherbo2 has quit [Ping timeout: 268 seconds]
<FromGitter>
<asterite> yeah, every `def` is a template and there are no virtual functions or virtual tables, just multidispatch
<FromGitter>
<dscottboggs_gitlab> oh ok I think I probably misunderstand virtual functions then
<FromGitter>
<asterite> well, from the outside they look like virtual functions... meaning that depending on the type one or the other will be called
<FromGitter>
<asterite> but like stronny says, virtual functions means there's a table at runtime that decides what to invoke, while in crystal that "table" is determined at compile-time (and there's no such table)
<FromGitter>
<stronny> you can have it done yourself! =)
<FromGitter>
<stronny> Hash(String, Proc)
<FromGitter>
<dscottboggs_gitlab> okay... so that leads me to the (I think) obvious question...why do they do it like that??
<FromGitter>
<dscottboggs_gitlab> but crystal does all that at compile time without a vtable so like...why not do it the way crystal does it? Or is it just a bad legacy thing? or does crystal do that?
<FromGitter>
<stronny> Rust also claims they can decide everything compile time, but come on
<FromGitter>
<stronny> suppose you need to read a file and call a corresponding function to process it
<FromGitter>
<stronny> you can't do that without some kind of runtime dispatch
<FromGitter>
<stronny> what you can do is generate a `case` with all the options
<FromGitter>
<stronny> but then you may have an idea: let's do plugins!
<FromGitter>
<dscottboggs_gitlab> hm
<FromGitter>
<stronny> C++ does that their way to avoid recompiling everything, fails at that
<FromGitter>
<stronny> Crystal does that anyway
<FromGitter>
<dscottboggs_gitlab> > to avoid recompiling everything ⏎ ⏎ Ah! there it is
<FromGitter>
<dscottboggs_gitlab> thanks
<FromGitter>
<stronny> read the FQA if you have some time, it's really a cool piece of documentation
<FromGitter>
<stronny> general purpose even, without anything to do with C++ necessery
<FromGitter>
<dscottboggs_gitlab> I don't mind C++ anyway, I will if I ever have the time, thanks :)
<FromGitter>
<stronny> have fun! =)
return0e has joined #crystal-lang
<yxhuvud>
If I've udnerstood correctly there are some tradeoffs for performance, where one way (vtables I think?) is better if there is a high branching factor and the other is better if there is a low branching factor.
<yxhuvud>
I wonder how that tradeoff has changed over time though. Caches doesn't work like they did in the late 80s..
return0__ has quit [Ping timeout: 268 seconds]
<FromGitter>
<dscottboggs_gitlab> Well if rust does the same thing as crystal does (not the thing C++ does) then comparing them at different branching factors would probably help answer that question.
<FromGitter>
<dscottboggs_gitlab> as always the only way to know for sure is to benchmark it 😀
<yxhuvud>
I already have that, for comments and strings. Emacs though ..
<FromGitter>
<dscottboggs_gitlab> yeah i've been using vim less and less lately tbh
<FromGitter>
<dscottboggs_gitlab> vs code is just so good
sagax has joined #crystal-lang
sz0 has quit [Quit: Connection closed for inactivity]
ur5us has joined #crystal-lang
<FromGitter>
<sam0x17> good news guys -- I've been appointed to be the tech lead of a VC-funded search engine startup, and we will be using crystal for the majority of our infrastructure. Post MVP we will probably devote resources to supporting the language, assuming everything goes well
commavir has quit [Ping timeout: 240 seconds]
_ht has quit [Remote host closed the connection]
tdc has quit [Ping timeout: 265 seconds]
<FromGitter>
<toddsundsted> that's great news! can you share the name of the startup?
<FromGitter>
<toddsundsted> i'd also love to know your rationale for making that call
oz has quit [Quit: EOF]
<FromGitter>
<sam0x17> I don't think I'm allowed to give the name just yet but in a few weeks I definitely could
<FromGitter>
<sam0x17> we did an extensive analysis of rust, go, crystal, and nim and found that crystal was the best balance in terms of productivity, community, performance, and in particular performance on our use cases (which involve a lot of external APIs and sometimes scraping)
<FromGitter>
<sam0x17> basically it comes down to "rust is great, but fighting the borrow checker makes things take 3x longer to write"
<FromGitter>
<Blacksmoke16> how will it be used?
<FromGitter>
<sam0x17> API backend -- processing and combining search results, along with some standard CRUD stuff for user preferences, etc
<FromGitter>
<sam0x17> fibers make what we're doing really convenient in crystal
<FromGitter>
<Blacksmoke16> :0 nice, have you looked into frameworks for that yet? 😉
<FromGitter>
<sam0x17> for the most part we are going super lean so our search infrastructure probably will be kemal or even just hand-written HTTP::Server stuff
<FromGitter>
<sam0x17> for other stuff it's always between lucky and amber
<FromGitter>
<Blacksmoke16> boo :p
<FromGitter>
<Blacksmoke16> fair enough
<FromGitter>
<sam0x17> any other newcomers I am not aware of? I've been out of the crystal world for a few months
<FromGitter>
<sam0x17> oh yeah that's right how has that been coming along
oz has joined #crystal-lang
<FromGitter>
<Blacksmoke16> quite well, released new version a little while ago. Is getting pretty slick
<FromGitter>
<sam0x17> yeah I'll definitely consider it for this, we're basically going to have a small number of endpoints the majority of which are very compute intensive and have to do things in multiple fibers
<FromGitter>
<Blacksmoke16> 👍
ur5us has quit [Quit: Leaving]
ur5us has joined #crystal-lang
<FromGitter>
<toddsundsted> super exciting. i look forward to hearing about how it turns out. we're 50% ruby/rails (application) and 50% haskell/servant (microservices). i love haskell, but it's a steep learning curve, and something like crystal would be a great forward path for rails devs
<FromGitter>
<Blacksmoke16> indeed
commavir has joined #crystal-lang
<FromGitter>
<watzon> Is there a way to access private methods in an `self.new`?