41–50 of 187 posts
I'm excited if they can bring the same simplicity to their additions to languages and frameworks as well.
[1] https://blog.projectpiglet.com/2018/03/refer-friend-using-st...
"Because converting a large, complex set of living codebases from one language to another is a non-trivial task that requires boiling any number of oceans. This approach doesn't have that problem." comes the wiser, if less interesting, response.
Earlier quoted context omitted.
It's a double edged sword - onboard some devs on "advanced" scala code and let me know how the 10x is working for ya. I also feel that sometimes types cause additional congitive load - you have to mentally model the types and what they do. OTOH I'm pretty sure most people can onboard a js project that's well written. I think exploratory, debug-based onboarding can be easier with poorly written static lang codebases t…
When using a dynamic language you need to know what properties are on an object right? So you can work with them, access them, whatever. So just write it down so everyone else knows too. There, that was easy.
Not yet open-sourced, but this is definitely planned. You can try it out there though: https://sorbet.run By the way, a number of RubyKaigi 2018 talks were dealing with type checking (and the other were about improving performance & memory usage).
I had the "pleasure" of creating and integrating a parser for a custom DSL into ACE. I've created the parser in ~3 days; it took another 3 to make it work with ACE. If it was up to me, I'd chose monaco editor (as the guys from mozilla did it with their webassembly editor)
I just was looking for a quick editor for the demo, and ace seemed to work well for this. Thanks for the pointer to manaco, I'll look at that for next time.
Using an editor in the browser won't be the final product. We're planning on integrating into your editor of choice instead.
Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?
Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?
And it's really useful for CLIs and APIs.
Earlier quoted context omitted.
When using a dynamic language you need to know what properties are on an object right? So you can work with them, access them, whatever. So just write it down so everyone else knows too. There, that was easy.
If that’s the case, then why not have the compiler check them as well?
Is Crystal still a thing? I thought it sought to keep Ruby ease but statically for speed and to reduce bugs?
It's definitely a threat though. The Amber Framework is very familiar to people who know Phoenix or Rails.
Personally, coming from Ruby, Crystal has a slightly steeper learning curve. However, I feel that magic spark deep down now that I've spent more time with it and I'm more aware of what inference can do and how to use it for my benefit.
Little safety things that seem irritating at first, but then you put the pieces together and understand them a bit more.
T | Nil is a culprit here. It seems obnoxious, but then you realize, I can just chain methods in a case statement, I don't have to check for nil over and over, just in the topmost part of whatever code it is. It's not how I normally think, and my instinct was wrong based on my initial understanding, but now I'm much more comfortable with it.
As for tooling, Crystal is rather weak. This too will come with time.
This looks really nice... i wish it was just part of the language to be able to write ruby with type information e.g. instead of having a separate more verbose sig method that's called before each method signature... ``` class Foo extend T::Helpers sig( # Both positional and named parameters are referred to by name. # You must declare all parameters (and the return value below). foobar: Integer, widget: String ) .ret…
We'd love that too! We're chatting with the Ruby folks to see if anything like that is feasible. We experimented with lots of other syntaxes (comments, yarddoc, .rbi files, monkey-patching stdlib classes to be callable) and the `sig` syntax seems to be the easiest for folks to use inside Stripe.
After writing sigs for the past few months, I don't dislike it as much as I thought I would. You get the syntax highlighting and autocomplete of your editor, while `sig` and `T` are short enough to not feel like too much boilerplate.
We're very open to other suggestions if you have any for other syntax suggestions. Just email us at sorbet@stripe.com.
Seeing the Ruby devs take compatibility so seriously is such a confidence builder for me, either way. Ruby is such a joy to program in, and for certain projects, Crystal fits the "square enough to go in a square-ish hole" role, but I really miss some of the ease-of-use that Ruby has to offer.
require 'Something'
Something.new.methods.sort
I use that every single day. Crystal can't do that. Yet.
Little things like that make Ruby such a human-friendly language.
Now that we've learned our collective lesson that naive dynamic types are too slow for big projects, I am glad to see Ruby-thinkers begin to explore the type system space and search for something that will benefit all Ruby hackers.
I suspect that if we arrive at the point where Ruby has a gradual or optional type system available, that refactoring some of the old Ruby tools will be very pleasant. If or when that day comes, I know I'll devote a chunk of my own time to try and catch the tools back up, and the rest will follow if only there are hackers who want to hack badly enough.