3 ms·

Why do you need to build an editor too? Side note, I've written a GC in rust (stop the world, compacting). It's not a cutting edge, concurrent generational GC

by qppo 6y ago

Why do you need to build an editor too? Side note, I've written a GC in rust (stop the world, compacting). It's not a cutting edge, concurrent generational GC but it's not that big of an undertaking. And it performs very well for small problem sets since memory is all slab allocated. Only a few hundred lines in Rust. I do definitely see how writing a tree walking interpreter is non ideal in Rust if you don't have a ton of experience writing Rust. I have a tiny lisp in Rust compared to doing it in dynamic languages it is quite verbose and hard to grok.

pbiggar 6y ago
The premise of Dark is that we can remove a huge amount of accidental complexity by having an integrated toolkit of language, editor, and infrastructure. This allows for three major steps forward: - we're able to deploy (safely!) in 50ms rather than minutes because of it. [1] - we completely host the infra and you don't need to think about it (including DBs and queues, which are nicely integrated into the language) [2] - trace driven development, where we use real values from production and show you them in your editor [2] [1] https://blog.darklang.com/how-dark-deploys-code-in-50ms/ [2] https://darklang.com/launch/demo-video
- qppo 6y ago
  I get the value prop and totally believe in your approach, I'm just confused why you would opt to write an entire editor when the LSP can do whatever you want and integrates into numerous editors.
  - snazz 6y ago
    They can significantly reduce tooling complexity with their own web-based editor. It's also a much more graphical application than a traditional text editor. Take a look at some screenshots from their demo video: https://www.youtube.com/watch?v=orRn2kTtRXQ https://www.youtube.com/watch?v=orRn2kTtRXQ
    - ssokolow 6y ago
      Of course, the hazard is that you then have to deal with offering a value proposition that's still appealing after adjusting for your target userbase having to give up all the plugins and tweaks they configured into their editors. https://blog.harterrt.com/coding_in_textboxes.html https://blog.harterrt.com/coding_in_textboxes.html

by qppo 6y ago

pbiggar 6y ago

The premise of Dark is that we can remove a huge amount of accidental complexity by having an integrated toolkit of language, editor, and infrastructure. This allows for three major steps forward: - we're able to deploy (safely!) in 50ms rather than minutes because of it. [1] - we completely host the infra and you don't need to think about it (including DBs and queues, which are nicely integrated into the language) [2] - trace driven development, where we use real values from production and show you them in your editor [2] [1] https://blog.darklang.com/how-dark-deploys-code-in-50ms/ [2] https://darklang.com/launch/demo-video

qppo 6y ago
I get the value prop and totally believe in your approach, I'm just confused why you would opt to write an entire editor when the LSP can do whatever you want and integrates into numerous editors.
- snazz 6y ago
  They can significantly reduce tooling complexity with their own web-based editor. It's also a much more graphical application than a traditional text editor. Take a look at some screenshots from their demo video: https://www.youtube.com/watch?v=orRn2kTtRXQ https://www.youtube.com/watch?v=orRn2kTtRXQ
  - ssokolow 6y ago
    Of course, the hazard is that you then have to deal with offering a value proposition that's still appealing after adjusting for your target userbase having to give up all the plugins and tweaks they configured into their editors. https://blog.harterrt.com/coding_in_textboxes.html https://blog.harterrt.com/coding_in_textboxes.html