<FromGitter>
<636f7374> I might make VPN (IPSec) and TUNTAP, but I should use Rust, TUNTAP part can be tricky in Crystal.
<FromGitter>
<636f7374> Writing in Rust may be more reliable and stable, then I want to try Rust (m-labs / smoltcp: a smol tcp / ip stack).
<FromGitter>
<636f7374> smoltcp is a standalone, event-driven TCP/IP stack that is designed for bare-metal, real-time systems. Its design goals are simplicity and robustness. Its design anti-goals include complicated compile-time computations, such as macro or type tricks, even at cost of performance degradation. β β smoltcp does not need heap allocation at all, is extensively documented, and compiles on stable Rust 1.28 and
<FromGitter>
<confact> @straight-shoota I saw that you are one of the collaborators to the crystal libgit2 repo. Do you know a way to do something similar to `git log` with path filter, like `-- path`?
<FromGitter>
<bajro17> crystal cant compete with GO
<FromGitter>
<waghanza> at least for inspiration (`crystal` take inspiration from `go`)
<FromGitter>
<bajro17> I think its impossible
<FromGitter>
<waghanza> why ?
<FromGitter>
<bajro17> because google make it
<FromGitter>
<bajro17> if crystal have same amount of users and developers like go
<FromGitter>
<waghanza> I speak only on technical ideas, not popularity
<FromGitter>
<bajro17> I think crystal in short time will be even better then this
<FromGitter>
<bajro17> I was trying to promote crystal
<FromGitter>
<bajro17> make some tutorials on yt
<FromGitter>
<bajro17> but I finish with 14 subscribers :D
<FromGitter>
<bajro17> And I do it 2 years ago ahahhaha
woodruffw has quit [Ping timeout: 265 seconds]
woodruffw has joined #crystal-lang
<FromGitter>
<watzon> Crystal is actually faster than Go in many benchmarks. I think it competes just fine for the most part.
<FromGitter>
<watzon> A lot of Crystal was actually based on Go, like the concurrency model
<FromGitter>
<ImAHopelessDev_gitlab> Hello
<FromGitter>
<ImAHopelessDev_gitlab> i've been using the sh*t out of enums lately
<FromGitter>
<ImAHopelessDev_gitlab> in godot, and in crystal
<FromGitter>
<waghanza> @watzon probably, my figures does not say that, but their not goodly computed (I'm working on that)
<FromGitter>
<watzon> There is already a large benchmarking repo that takes both Go and Crystal into account. https://github.com/kostya/benchmarks
<FromGitter>
<watzon> @ImAHopelessDev_gitlab enums are very helpful
<FromGitter>
<ImAHopelessDev_gitlab> @watzon yeah they are. i used to just try to remember integers and map them to their functionality in my head. but it got quite hard to remember
<FromGitter>
<ImAHopelessDev_gitlab> over time, now, having a string representation of it makes it very easy
<FromGitter>
<watzon> Wait until you learn about symbol autocasting
<FromGitter>
<watzon> Assuming you don't know about it already
<FromGitter>
<ImAHopelessDev_gitlab> never heard of it, but i probably i've seen it in the wild before?
<FromGitter>
<watzon> Maybe. Basically it just allows you to use an enum as a parameter to a function, but rather than the enduser having to actually use the full enum itself, they can use a symbol
<FromGitter>
<ImAHopelessDev_gitlab> is it like syntax sugar on top of enums?
<FromGitter>
<watzon> Yeah basically just some syntactic sugar
<FromGitter>
<watzon> Really helpful for larger enums
<FromGitter>
<ImAHopelessDev_gitlab> ohh
<FromGitter>
<ImAHopelessDev_gitlab> i've seen that in some code blacksmoke showed me long time ago. and i got triggered because the lowercase symbol, and how we can't do :Bar
<FromGitter>
<ImAHopelessDev_gitlab> or.. maybe that's in the case when thing, can't remember
<FromGitter>
<watzon> That's just the way symbols are meant to be written. They should always be snake case.
<FromGitter>
<watzon> So the enum `FooBarBaz` would be `:foo_bar_baz`
<FromGitter>
<ImAHopelessDev_gitlab> yeah that really triggers me
<FromGitter>
<watzon> :shrug:
<FromGitter>
<watzon> Just the way the language is meant to work. Stylistically you should never really have uppercase symbols.
<FromGitter>
<ImAHopelessDev_gitlab> i capitalize all my enum values too... lol don't know if that's normal but i liek it
<FromGitter>
<watzon> Well enum values are constants, so they should be capitalized
<FromGitter>
<watzon> Technically symbols are constants of a sort as well, but... They're also kind of strings so :shrug:
<FromGitter>
<ImAHopelessDev_gitlab> every letter for me
<FromGitter>
<watzon> I think the convention is to do UpperCamelCase, but it's really up to you. The UPPER_SNAKE_CASE is more of a C convention.
<FromGitter>
<ImAHopelessDev_gitlab> Yeah, that's the term, UPPER SNAKE CASE
<FromGitter>
<ImAHopelessDev_gitlab> My fav ;D
<FromGitter>
<Blacksmoke16> i remember seeing something that did like `UPPER_SNAKE_CASE` for constant, `UpperSnakeCase` for types, and `Uppser_Snake_Case` for enum members
<FromGitter>
<Blacksmoke16> so you can tell what "type" of const it is by just looking at it
<FromGitter>
<watzon> Hmm that's not bad
<FromGitter>
<Blacksmoke16> but meh
<FromGitter>
<watzon> I don't like using a bunch of different styles if I can avoid it. Mostly I'll do UPPER_SNAKE_CASE for constants and UpperCamelCase for types and enums.
<FromGitter>
<Blacksmoke16> thats what i end up doing as well
<FromGitter>
<ImAHopelessDev_gitlab> that's what i do
<FromGitter>
<watzon> @Blacksmoke16 any idea how to take a type `T` and figure out if it's a subclass of something else? For instance, `Number`/
<FromGitter>
<kinxer> It really is wonderful how readable macros can be in Crystal. Metaprogramming is always going to be somewhat arcane, but Crystal still manages to avoid it being too bad.
<FromGitter>
<watzon> As long as they're not nested. Nested macros can get a bit messy.
* FromGitter
* ImAHopelessDev_gitlab Girng has exited the chat
<FromGitter>
<dburnsii> I would expect that `if` statement to evaluate to true only if the socket is not nil, but I get a compile time error on the `gets`, saying `(compile-time type is (UNIXSocket | Nil))`
<FromGitter>
<kinxer> Does the error still happen if you don't have the `spawn` block?
<FromGitter>
<636f7374> Why put accept in initialize (construct).
<FromGitter>
<dburnsii> It doesn't, but I'll need to spawn a fiber for the application I'm writing. This is just a stripped down version of what I've written
<FromGitter>
<dburnsii> I get if the spawn has it's own context and doesn't know if `client` is or is not nil, but the following code has the same problem:
<FromGitter>
<dburnsii> So @636f7374 I think that solves my problem, save for the `server.process` call. So I guess my question is, why does `if !client.nil?` not set the type of `client` in the branch, but `next unless` does?
<FromGitter>
<dburnsii> Thanks for helping me so quickly by the way guys
<FromGitter>
<wontruefree> @636f7374 Awesome !! I might migrate my project to use this instead
<FromGitter>
<636f7374> why does if !client.nil? not set the type of client in the branch, but next unless does? If you use fiber, it will have this problem (nil).
<FromGitter>
<636f7374> So you need to use `unless`.
<FromGitter>
<636f7374> @wontruefree :)
<FromGitter>
<dburnsii> So I notice that `client` is created and initialized within the `spawn` in the code you wrote. So my assumption is that I won't have this issue as long as I use a variable created within the spawn. Interesting how that works, but I can work with that. Thanks again.