<TheGillies>
Is there a way to see if a socket is closed like an event or something?
<TheGillies>
Right now I'm about to poll socket every few seconds to check
<TheGillies>
but that seems like the wrong way
Kug3lis is now known as Kug3lis_off
<bmcginty>
TheGillies: Let me go glance at something re. your socket question. Don't want to give you wrong advice.
<bmcginty>
TheGillies: set a read_timeout on a socket, and if you don't get data back from the other party, You'll get an io::timeout on that socket...
<bmcginty>
TheGillies: Also, if your socket closes and you're reading from it, you sshould get an IO::Error...
<TheGillies>
two caveats... one is that I'm not expecting data to be always coming from socket so a timeout doesn't really work. two is that I'm using a #gets which doesn't error when socket does
<TheGillies>
dies*
<TheGillies>
Anyone know if I can use `case foo; when foo is_a? Thing` It's not complaining about my syntax but it's also not working heh
<TheGillies>
er `when is_a? Thing`
sp4rrow has joined #crystal-lang
<TheGillies>
oh woah kinda hacky but I did `case true; when thing.is_a? Thing`
<TheGillies>
oh
<TheGillies>
nevermind I don't need a is_a? I can just put class
Raimondii has joined #crystal-lang
Raimondi has quit [Ping timeout: 268 seconds]
Raimondii is now known as Raimondi
sp4rrow has quit [Quit: The Internet needs a break and I need a cookie]
<TheGillies>
Is there a way to include a module on a class that's already defined?
<TheGillies>
oh maybe extend
<TheGillies>
oh no that just makes class methods
<FromGitter>
<bigtunacan> Reading through the Crystal docs still as I'm getting used to things
<FromGitter>
<bigtunacan> I was a bit surprised by how extend/include work
<FromGitter>
<bigtunacan> Is there no way to create a module that I can mixin where it will have a mix of class and instance methods?
<TheGillies>
im a newb but i think if you include it's all instance and if you extend it's all class
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
snsei_ has joined #crystal-lang
snsei has quit [Read error: Connection reset by peer]
<TheGillies>
Anyone know where `def` is defined?
<FromGitter>
<bigtunacan> Yeah; that's one I'm saying
<FromGitter>
<bigtunacan> It's a bit odd that I can't mix both into the same module
_whitelogger has joined #crystal-lang
Kug3lis_off is now known as Kug3lis
Kug3lis is now known as Kug3lis_off
snsei_ has quit [Remote host closed the connection]
<FromGitter>
<bew> TheGillies, def is not a method, it's a keyword, that treks the compiler that there is a crystal method definition following
wontruefree has quit [Quit: Is gone... Just plain old gone]
wontruefree has joined #crystal-lang
<TheGillies>
How do I get a string from confile file and then instantiate class from that like "Foo" from config to Foo.new
<TheGillies>
config file*
Kug3lis_off is now known as Kug3lis
<Papierkorb>
TheGillies: You can't instantiate classes from a conf file like in Ruby, but you can implement a YourClass.from_yaml (or from_json) using `YAML.mapping`
<FromGitter>
<akzhan> You may keep and use hash with string to class mapping.
<TheGillies>
Ah from_mapping of course
<TheGillies>
I use it with json forgot it works with yaml
olbat has joined #crystal-lang
<oprypin>
TheGillies, did you see my answer about closed socket?
snsei has quit [Remote host closed the connection]
snsei has joined #crystal-lang
<TheGillies>
oprypin: nope
* TheGillies
tries to find in backlog
<TheGillies>
looks like mapping expects a hash, is there a way to make it accept an array? like no "parent" key
mark_66 has quit [Remote host closed the connection]
olbat has quit [Ping timeout: 268 seconds]
olbat has joined #crystal-lang
<TheGillies>
oprypin: Ah I see about socket, thanks
LastWhisper____ has joined #crystal-lang
<TheGillies>
Just me or does yaml parser parse true as a string and not bool?
<Papierkorb>
How are you parsing?
<TheGillies>
>> require "yaml"; p YAML.parse("test: true")
<Papierkorb>
TheGillies: Bool is not in YAML::Type. It's parsed for you when using mapping
<oprypin>
basically seems like crystal doesnt support this
<TheGillies>
ah
zipR4ND has quit [Ping timeout: 260 seconds]
wontruefree has quit [Quit: Is gone... Just plain old gone]
xaxisx has quit [Quit: Leaving]
sz0 has quit [Quit: Connection closed for inactivity]
<FromGitter>
<bararchy> Is there a way to profile Crystal code ?
crystal-lang034 has quit [Ping timeout: 260 seconds]
<RX14>
with any profiler that works for C
<RX14>
callgrind, linux perk
<RX14>
callgrind, linux perf*
<RX14>
i've used both
<RX14>
instruments works on mac
<FromGitter>
<bararchy> Cool, thanks RX14, I guess debug compile is a must ?
<RX14>
well --debug is the default now
<RX14>
so
<RX14>
well has been for a while
<RX14>
so yes
<RX14>
but you don't need a flag for it
greengriminal has quit [Quit: Leaving]
wontruefree has joined #crystal-lang
wontruefree has quit [Client Quit]
Kug3lis is now known as Kug3lis_off
wontruefree has joined #crystal-lang
sz0 has joined #crystal-lang
hako has joined #crystal-lang
Kug3lis_off is now known as Kug3lis
<FromGitter>
<bararchy> 1) 56% my_prog my_prog [.] *Fiber::switch_stacks<Pointer(Pointer(Void)), Pointer(Pointer(Void))>:Nil ⏎ RX14, I'm playing with perf, seeing this, does that means 10% of the time my program run it did this thing ?
<FromGitter>
<jwaldrip> I know I have mentioned this before but I am sitting at a table with a bunch of senior Devs and they have concerns about crystal in not being more strict. I.e. Don't compile if you have unused vars. Same for unused methods. This is hard to do with a global require.... if you had the concept of imports and exports you could better know what should or should not be used.
hako has quit [Ping timeout: 240 seconds]
<FromGitter>
<jwaldrip> These are go Devs.
wontruefree has quit [Quit: Is gone... Just plain old gone]
wontruefree has joined #crystal-lang
wontruefree has quit [Client Quit]
<FromGitter>
<drujensen> @jwaldrip sounds like good feedback. I recall you mentioning this at the code camp as well
<FromGitter>
<jwaldrip> I think code quality is important. If a language can enforce quality then it's doing a great thing.
<FromGitter>
<drujensen> :+1:
<FromGitter>
<bigtunacan> I agree that code quality is important, but I have yet to see a single language that enforces it.
<FromGitter>
<jwaldrip> Don't allow for code to suck. Rather tell people to be better.
<FromGitter>
<jwaldrip> What about go?
<FromGitter>
<bigtunacan> That certainly includes Go
<FromGitter>
<fridgerator> thats a pretty big change tot he language
<FromGitter>
<jwaldrip> Go does a better job than most
<FromGitter>
<drujensen> so one thing i dislike about the imports in js is you tend to put everything in one file
<FromGitter>
<bigtunacan> I think code quality is more a process and team driven issue.
<FromGitter>
<bigtunacan> Things like mentoring junior devs on best practices, establishing best practices and enforcing them.
<FromGitter>
<drujensen> where require forces you to break things down per file
<FromGitter>
<bigtunacan> Performing code reviews and refactoring sub par code.
<FromGitter>
<bigtunacan> I don't think Go does better than many others.
<FromGitter>
<bigtunacan> You can get part way there with static code analysis and linters in most any language
<FromGitter>
<bigtunacan> But that's not enough.
<FromGitter>
<jwaldrip> Linters are a choice. I say enforce.
<FromGitter>
<bigtunacan> How much code duplication is occurring? Is the team making poor/wrong choices of design patterns to use?
<FromGitter>
<drujensen> @bigtunacan I think languages do play a big part in code quality. Goto in basic comes to mind
<FromGitter>
<bigtunacan> There are many things the language can't fix.
<FromGitter>
<drujensen> true
<FromGitter>
<drujensen> there are some it can and should though
<FromGitter>
<bigtunacan> I agree that languages try to fix some of these things; and some are better than others in these respects, but there is an old adage.
<FromGitter>
<bigtunacan> Good programmers can write good code in the worst programming language and bad programmers can write bad code in the best programming language.
<FromGitter>
<drujensen> so are you suggesting crystal should not try to improve?
<FromGitter>
<bigtunacan> No, not at all.
<FromGitter>
<drujensen> and @jwaldrip request is invalid?
<FromGitter>
<bigtunacan> We should all be trying to improve :)
<FromGitter>
<drujensen> :-)
<RX14>
i don't think i've ever had a bug in crystal that would have been helped by the "additional strictness" that @jwaldrip talked about
<FromGitter>
<bigtunacan> In the respect of languages that are doing well in preventing you from shooting your foot off I honestly think Rust and Elm are probably the best examples today.
<RX14>
because typically you have 2 phases, assigningand then using variables
<RX14>
if you typo the variable name when you're using it you get an error
<Papierkorb>
The import/export stuff from JS is awful
<RX14>
because it's undefined
<RX14>
if you typo when assigning it you either get the same or the wrong type
<FromGitter>
<bigtunacan> But strictness tends to come with a tradeoff of less meta.
<FromGitter>
<drujensen> @RX14 I think I agree
<RX14>
the type system goes a long way
<RX14>
it's not perfect
<RX14>
but i don't want it to be perfect
<FromGitter>
<asterite> I actually like the idea of giving a warning/error for unused variables. I had a working implementation but it wasn't complete
<RX14>
i want a linter for this
<RX14>
but i do not want a go-style error
<FromGitter>
<bigtunacan> And when wielded carefully meta programming is a powerful tool.
<FromGitter>
<asterite> On the other hand, unused methods is plain impossible to do in Crystal
<RX14>
unused methods is stupid imho
<FromGitter>
<bigtunacan> On the other hand; as Uncle Bob says, "Monkey patches pave the road to hell."
<FromGitter>
<drujensen> yeah, a warning. IDE’s are the best place to provide this info
<FromGitter>
<asterite> so I think it's a valuable tool
<FromGitter>
<drujensen> VS will show you who is calling your method and how many times its being reference
<RX14>
as methods you call (and you can't typo them or you get a compile error), but variables are long-lived through a method
<RX14>
@asterite yes but please make it a tool
<RX14>
not a compiler feature
<RX14>
like go does
<FromGitter>
<asterite> It's better if it's enforced, nobody wants to have silly mistakes in their code
<RX14>
enforced by travis sure
<RX14>
enforced by the compiler no
<FromGitter>
<asterite> I like how it's done in Elixir: it's a warning, but you can treat warnings as errors
<RX14>
i often just want to comment out blocks of code
<RX14>
@asterite i thought you wanted no warnings
<FromGitter>
<asterite> I changed my mind, I like how it's done in Elixir
<FromGitter>
<asterite> In Elixir you always see the warnings, there's no way to supress them
<FromGitter>
<asterite> but it lets you work (unlike Go)
<FromGitter>
<bigtunacan> I agree with the Elixir approach
<FromGitter>
<asterite> so eventually you get sick of the warnings and remove them
<FromGitter>
<drujensen> I think warnings is a great idea
<RX14>
i disagree
<Papierkorb>
As long one can tell the compiler to show warnings, ignore them, or treat them as errors, totally fine by me
<RX14>
for your old reasons
<FromGitter>
<asterite> (or force them in travis)
<FromGitter>
<bigtunacan> Warn for undefined methods, but still compile.
<FromGitter>
<drujensen> and if you want strict, you can enable that
<RX14>
lots of warnings eventually you just ignore them
<FromGitter>
<bigtunacan> Then have an option to enforce.
<RX14>
warning fatigue
<FromGitter>
<drujensen> or you can disable warnings
<FromGitter>
<drujensen> lol
<FromGitter>
<bigtunacan> On the one hand I may want to define methods as I'm building, but they could be boilerplate that I'm not ready to use.
<FromGitter>
<bigtunacan> That should not cause a compiler error.
<Papierkorb>
^
<RX14>
@asterite please don't add warnings I agreed with your original reasoning: you just end up ignoring them
<FromGitter>
<bigtunacan> But the flipside is people go around cleaning things up and they forget to delete methods that are no longer in use.
<FromGitter>
<molovo> I've worked on so many PHP apps where error reporting is disabled entirely by a previous developer because of having too many. It's just an excuse to write shitty code
<RX14>
code should either compile and be safe or not compile and be unsafe
<FromGitter>
<bigtunacan> Static compilation should warn me to help me keep my codebase as clean as possible.
<RX14>
no middle warning ground
<FromGitter>
<asterite> Here's a quote from José Valim: ```Honestly, releasing/deploying code with warnings is not an option in my book. The reason we emit warnings instead of errors is because there is no reason to make your compilation fail right out of the box, better to collect the warnings and show them for all files, instead of have the frustrating process of fixing one error just for another one to show up. That's also why we
<FromGitter>
... don't plan to provide options for disabling warnings: they should be fixed, even if they don't error out upfront.```
<RX14>
at least before 1.0
<FromGitter>
<asterite> I agree 100% with him
<Papierkorb>
An IDE/Editor should/could warn about stuff like that, and that's a good thing. I want to be able however to be able to ignore those for some time, like while trying things
<Papierkorb>
asterite, I agree too. Warnings are errors for deployment.
<FromGitter>
<molovo> I think the best bet would be no warnings, but allow *individual* errors to be ignored with a flag in the code. It allows you to work when you need to, but stops you shipping with dodgy code
<FromGitter>
<asterite> In any case, don't worry, I won't be implementing any of that any time soon (maybe someone else from the team will, I don't know)
<RX14>
i really hope we ship 1.0 with no warnings
<Papierkorb>
molovo, IMHO such devs are lacking self-discipline, enforcing rules doesn't fix that much more important issue
<RX14>
devs lack self-discipline which is why the compiler should be strict
<RX14>
which is why crystal has typically had no warnings, they're either errors or fine
<RX14>
how about this: the formatter just removes unused (local) variables
<RX14>
and you notice it when reviewing your diff
<Papierkorb>
it doesn't help there though. then instead such devs would just hack something that doesn't throw errors, but is still awful code
<RX14>
actually that would be terrible for me because my editor automatically formats on save
<Papierkorb>
*still write
<FromGitter>
<molovo> @Papierkorb I totally agree. But good devs often inherit bad code. If the language enforced good code, it would solve a lot of frustration for responsible devs. `crystal build —release` already does optimisations, I see no reason why the `—release` flag couldn’t enforce strict error handling, so that when building without it you can still work without a multitude of errors
<RX14>
ohhh thats a good call
<RX14>
i'd accept that
<RX14>
no warning for unused vars without release
<Papierkorb>
molovo, "good code" is quite often subjective and highly context dependent. I'm perfectly happy however with that --release idea
<RX14>
error with release
<FromGitter>
<molovo> It would also be handy in IDE’s. They could compile silently in the background with `—release` so the errors appear in the editor and you’re aware of them, but it won’t block an actual compile so you can run the code
<Papierkorb>
They don't have to, they could just run the code parser, as some already do (through plugins) for other things
<FromGitter>
<molovo> @Papierkorb yeah that would be a better idea
<Papierkorb>
I really like rubocop's integration. Also Project-wide rubocop configuration, and everyone has the same standard. You can have more strict rules for important projects, and lesser ones for beginners.
<RX14>
i'd like crystal to not have rubocop for as long as possible
<RX14>
find as many ways to solve problems without
<RX14>
and only fall back on a linter when we hit something with no other solutions
<FromGitter>
<drujensen> Papierkorb, totally agree with highly context dependent. sometimes you need to just try something in playground and other times you are building highly used code that needs to be rock solid
<RX14>
like this unused vars
<RX14>
i think the release/debug split idea is great
<RX14>
and avoids the need for a seperate linter with is one more thing for a dev to do
<Papierkorb>
rubocop is just a static code analyzer, the compiler already has tools for that too
<FromGitter>
<molovo> Does rubocop work out of the box with Crystal?
<Papierkorb>
it can't and probably never will
<Papierkorb>
What rubocop is lacking, and I'd love to be able to, is being able to create new rules for shards. Even if just to avoid common beginner mistakes.
<Papierkorb>
E.g., rubocop has a bunch of extra rules for Rails projects. I think it's a great feature to not only lint language behaviour, but also shard usage.
<FromGitter>
<bigtunacan> @Papierkorb those types of devs will always find a way to hack crap in. Best to not work with them 😋
<RX14>
should make it hard though
<RX14>
allows them not not have excuses when they shop up on your issue tracker
<Papierkorb>
bigtunacan, if other options were exhausted, I sadly have to agree :|
<FromGitter>
<molovo> Unfortunately I work in an office full of them at the moment
<Papierkorb>
but for some reasonable, and not draconian, rules, a ignorable warning turning to errors on --release sounds like a good idea
<Papierkorb>
Though I wouldn't like it to be overdone.
<RX14>
i'd prefer no warning turning into an error
<FromGitter>
<drujensen> @RX14 I would want to know there were going to be errors when I —release
<RX14>
why not just use --release to find out
<FromGitter>
<molovo> Yeah, I’m with @drujensen. On a large project suddenly getting hit with a wall of errors after lots of development would be frustrating
<FromGitter>
<drujensen> then I would just use —release all the time, lol
<RX14>
the problem i have is you comment out a bunch of code and then try to test and bam a wall of warnings
<RX14>
no thanks
<Papierkorb>
I'd also like configurability. Coding is a form of art, and everyone goes at it differently.
<Papierkorb>
drujensen, a --werror would be reasonable to have
<RX14>
i'd say 1 line
sp4rrow has joined #crystal-lang
<RX14>
"there are unused variables in the code"
<RX14>
or something like that
<RX14>
but only 1 line
<RX14>
which becomes errors on --release
<FromGitter>
<molovo> The issue with that, is that it doesn’t point you at the unused variables to be able to fix them. It’s fine saying compile with `—release` to see them, but that could take a long time for a large project
<FromGitter>
<drujensen> @RX14 yeah, it doesn’t have to be every instance
<FromGitter>
<drujensen> @molovo true
<RX14>
but it won't take long
<RX14>
because it'll fail
<RX14>
you'll see there's things
<RX14>
add release
<RX14>
and it'll fail and tell you
<RX14>
i guess 1 line per unused var would be ok
<RX14>
because you're not likely to have many unused vars
<RX14>
as I typuically only comment 1 or 2 blocks of code out when debugging
<FromGitter>
<molovo> Yeah, that would work. Just “unused var at file.cr, line n"
<FromGitter>
<drujensen> hopefully
<RX14>
but i basically don't want a wall of warnings to distract me when i'm trying to debug
<FromGitter>
<drujensen> agree, i could see that being frustrating
<Papierkorb>
I mean, even if you're having 100 unused vars (which is a ton in any case imho), 100 lines of text on the terminal isn't that much. one line per warning sounds fine.
<RX14>
it is a lot
<RX14>
100 lines would take up most ov my *vertical* monitor
<Papierkorb>
when you --release and only then see that monster, you did something wrong beforehand
<RX14>
yup
<RX14>
well
<RX14>
yeah 1 line per unused var as a warning sounds ok
<RX14>
i'd live with it
<RX14>
obviously turning into 1 line per error in --release
<Papierkorb>
As long you can disable warnings in debug, e.g., when running specs
<RX14>
thats too much configurability
<RX14>
in my opinion
<RX14>
i really don't like the idea of being able to turn off warnings
<RX14>
or turn off errors
<Papierkorb>
configurability is king
<RX14>
it's really not
<RX14>
if you get it right it doesn't have to be configurable
<Papierkorb>
get it right for whom?
<RX14>
everyone hopefully
<Papierkorb>
The compiler is almost as important to the dev as is their shell. What if you couldn't configure your shell?
crystal-lang260 has joined #crystal-lang
<RX14>
we currently have no compiler flags which affect whether code compiles or not directly
<RX14>
Papierkorb, as long as my shell did everything I wanted i'd LOVE that
<Papierkorb>
Wow
<Papierkorb>
I would move on to the next without thinking twice
<RX14>
why wouldn't you want something to work out of the box
<RX14>
with no config
<RX14>
because there's no config NEEDED
<Papierkorb>
that'd be fine, but not being able to configure? I'm about to invest years of my life into that tool, something will feel off down the line
<RX14>
configuration is a neccesary evil
<RX14>
but it's still evil
<Papierkorb>
The huge amount of totally different config distributions just for zsh shows that everyone expects different things
<Papierkorb>
Right now, the compiler doesn't have a ton of flags, as there really is not much to change.
<Papierkorb>
It however doesn't have none
<RX14>
no there's a lot to change
<RX14>
there's a lot about the compiler that could have been configurable
<RX14>
but we have almost none
<RX14>
and thats because of good design
<Papierkorb>
I'm talking about reasonable configurability, not "disable specific optimizations gcc-style" level configurability
<Papierkorb>
--debug, --no-debug and --release are configuration options. they're perfectly useful and important to have
<RX14>
i wouldn't call the configuration
<Papierkorb>
it changes the end result in a significant manner
<Papierkorb>
if for nothing else, --release programs tend to run much faster.
<RX14>
but everyone uses debug and release
<RX14>
it's something done per build
<FromGitter>
<molovo> That is one thing Crystal does very well. When I first started the fact that there was very little configurability meant it was one less thing to think about. I just wrote code and compiled, and it worked. Or if it didn’t, the compiler errors helped me learn the language
<RX14>
it's situational
<RX14>
config to me is something that you set for a project and very very rarely changes
<RX14>
debug and release are modes
<RX14>
they're both useful at the same time
<Papierkorb>
configuration can change often or never again
<Papierkorb>
you could have `crystal build --release` in a Makefile. Won't change again in the next 10 years.
<RX14>
there's a distinction in there somewhere
Kug3lis is now known as Kug3lis_off
<RX14>
but they're not what I mean
<RX14>
when i say "compiler config"
<RX14>
i talk about disabling and enabling warnings and opts and shit gcc style
<RX14>
warnings themselves are pretty bad to me
<Papierkorb>
I just to be able to make warnings to go away when writing specs
<RX14>
why?
<RX14>
why do they need to go away?
<Papierkorb>
they're completely worthles while I'm refactoring. I'm in that moment just running the specs to make sure I didn't break anything yet. Will clean up later.
<Papierkorb>
I mean I have to right? --release will be quite unhappy if you wouldn't.
<RX14>
thats why i didn't want them
<RX14>
they're worthless in debug
<RX14>
they're wrothless while refactoring
<RX14>
which i why i wanted them only in release
<RX14>
adding too many flags is too much to think about
<Papierkorb>
in normal debug, when you're testing brand new code, they can be helpful.
<RX14>
every time i need to configure warnings on and warnings off is another thing for me to think about
<RX14>
for me to change my watch command
<RX14>
when i shouldn't have to think about it
<RX14>
i should either get warnings or not
<Papierkorb>
you made that choice when you ran watch to have warnings or not
<Papierkorb>
why would you suddenly change your mind?
<RX14>
because as you said
<FromGitter>
<molovo> Well, we already have a debug mode. How about `—debug` shows nothing, standard build shows warnings, and `—release` throws errors
<RX14>
i want warnings when writing new code
<RX14>
not when refactoring
<RX14>
thats 2 cases that i will see over the course of 1 hour even
<Papierkorb>
molovo, that'd work for me
<RX14>
so i'd have to change
<RX14>
better to leave warnings on
<RX14>
and ignore them
<FromGitter>
<bararchy> why can't we have warnings, but have --no-warn or something to supress them ?
<Papierkorb>
molovo, would actually make --debug useful again
<RX14>
--debug is just the opposite of --no-debug
<RX14>
which is useful
<RX14>
flags need opposites for overriding aliases and default flags added by scripts
<RX14>
as long as the latter flag wins it's cool
<Papierkorb>
bararchy, I'd also be fine with that. I'm pretty much fine with any solution which lets me to make the compiler behave
Kug3lis_off is now known as Kug3lis
<Papierkorb>
*allows me to
<Papierkorb>
jeez
<RX14>
well i'm of the opinion that the programmer doesn't always know best
<RX14>
offering the easy way out of disabling warnings is a bad idea
<Papierkorb>
yes, which is why having sane defaults is absolutely necessary. But the moment a tool thinks it knows better, I'll remind the machine that it serves me, and will make it behave
<RX14>
i want a tool to know better than me
<RX14>
because it means I don't need to learn the domain knowledge of the tool
<FromGitter>
<molovo> Yeah, but they are just warnings. As long as you can’t disable errors I wouldn’t have a problem with hiding them, it’s not something everyone would want
<Papierkorb>
Not wanting to know is not a good thing, in the best case one will only miss out on useful stuff, in the worst case, stuff blows up
<Papierkorb>
though if stuff blows up, you could argue that the default configuration wasn't sane
balduin has quit [Ping timeout: 240 seconds]
<Aytan72>
Anyone use Crystal with Amazon Redshift?
<Papierkorb>
There's a discussion/issue in the shards wanted repo on Amazon stuff
<Aytan72>
Oh great, I'll check it out
<Aytan72>
We're porting some Ruby code to Crystal for the performance gains
<FromGitter>
<molovo> I started a framework for building MUDs in Crystal. I might get back to it one day. It was a bit shit though
<Papierkorb>
MUD... that's a term I haven't heard a long time
<Papierkorb>
nice one
<RX14>
never head of MUDs before
<TheGillies>
They were the rage in the early days of the internet
werthen[m] has joined #crystal-lang
<TheGillies>
essentially DnD as a telnet daemon
<Papierkorb>
multi user dungeon. "telnet dnd".
<FromGitter>
<molovo> There’s still a few going strong
<TheGillies>
and new ones being built :P
<RX14>
lol i guess i'm too young...
<Papierkorb>
I think building a MUD is a excellent project for someone who wants to try out architecturing a MMORPG-esque game
<TheGillies>
muds are nice because you don't have to worry about your graphics not aging well
<TheGillies>
just realized player corpses move around when you move after you die
<Papierkorb>
And if you have friends who are not taken aback by their interface, they're fun. tbh, I never playd a MUD, just some browser games years ago which used mainly text instead of graphics. Was fun though, the RP'ing was quite strong. Probably the case for MUDs too?
<TheGillies>
accidental zombie feature
<Papierkorb>
not a bug, it's a feature
balduin has joined #crystal-lang
<FromGitter>
<molovo> Yeah, some of the roleplay-intensive MUDs are really really intense. I stopped playing a few months ago, it can get way too addictive
<TheGillies>
I learned how to program on a mud
<TheGillies>
that's why i became a programmer so I could hack on muds
<TheGillies>
some muds have an embedded c-like language where you can program from within mud based editor
<TheGillies>
or just ftp your files
sz0 has quit [Quit: Connection closed for inactivity]
<Papierkorb>
but yeah, offering a easy to use modding/coding feature in a game is a fun and rewarding entrypoint for newbie devs. would love if more games would have a feature like that
balduin has quit [Ping timeout: 260 seconds]
bjz has joined #crystal-lang
<FromGitter>
<sdogruyol> what a great conversation :100:
balduin has joined #crystal-lang
Kug3lis is now known as Kug3lis_off
crystal-lang260 has quit [Ping timeout: 260 seconds]