4 ms·

Yeah, sadly it is. With e.g. Elixir I can literally get into a REPL and prototype my solution in minutes, right there on the spot, and then just copy a few line

Yeah, sadly it is. With e.g. Elixir I can literally get into a REPL and prototype my solution in minutes, right there on the spot, and then just copy a few lines from it and have the solution be 90% done (minus tests, of course). With Go and Rust I have to make a dedicated function somewhere and then have it be called after starting the program. Ain't exactly rocket science but the difference in time to do it and the convenience is still very stark. I love working with Rust for the stability and speed it gives me but the value proposition and daily coding flow are VERY different compared to a dynamic language. With Elixir I am mostly just brain-dumping and stuff happens extremely quickly and fluidly, with Rust I kind of sigh and accept that the next 10 minutes I'll just be writing and writing. Might even zone out and make a dumb mistake because I have to spend more keystrokes and more time to do something I'll do in a minute in Elixir. Maybe it's time to look for snippets support in my editor. Or start asking ChatGPT for them.

dhbradshaw 4y ago
Try using a test -- can stick anywhere and just run code there (push of a button with analyzer in vscode). Almost like embedding a repl into a module for experimentation.
- pdimitar 4y ago
  Haven't tried but definitely will, thank you!
serverholic 4y ago
See this is what I’m scared about in my current job. We have some people who want to use dynamically typed languages and some who want to use static. I don’t think being able to brain dump code is a good thing and it leads to an unmanageable mess when you have a large codebase. Types are essential as far as I’m concerned, but I constantly have to get into arguments with the dynamic type fans because their “flow” Is being restricted.
- pdimitar 4y ago
  Be a bit more charitable. :) Brain-dumping is simply a way to iterate and figure out what works and what doesn't, quickly. After I do it I take the requisite time to emulate exhaustive pattern matching, and add tests that cover the functionality well. My problem with Rust, and I love the language a lot, is exactly this: I want to quickly find what would work. After that I'm very happy to take the proper time to go things rigorously.
  - serverholic 4y ago
    Yes and then someone comes along and makes a change that breaks something seemingly unrelated and it’s less likely to be caught because there is no type system. And please don’t say tests solve that because they don’t. They help but they don’t solve it.
    - pdimitar 4y ago
      You won't catch me arguing with that. I work both with dynamic and static languages and usually I'll pick the static ones. Dynamic languages are very valuable when you can afford to iterate and gradually find out the golden path. For the better or the worse, many businesses are of that type. That being said, I just ended an Elixir contract and absolutely want to code Go or Rust for money again.
  - tele_ski 4y ago
    I do appreciate that you write tests. I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests. I tend to think more than write code, so usually my first go is reasonably close to what I need. But there are always edge cases you just never think about. I'd rather have a strong debugger than a repl imo
    - pdimitar 4y ago
      > I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests You are unfortunately very correct (at least in my 21 years of experience as well). I too feel annoyance when I know that I made a piece of code work well but (a) every now and then I am truly wrong and (b) various pieces of the system in the code interact in sometimes unexpected ways, unveiling inputs to your code that you haven't foreseen. So even though it often takes a heavy and annoyed sigh out of me, I still roll up my sleeves and add the tests because I've shot myself in the foot too many times, and ignoring past experience is just being a stupido. As for debugger/REPL, they are not orthogonal; you can have both. I'd more contrast debugger with tests themselves -- both are ways to go step by step through a process that you know is faulty somewhere. REPL to me is just a way to more quickly sketch a v1.0 of a piece of code, nothing else.
kupfer 4y ago
Is it just about a REPL? There is the evcxr hack, though I'm not sure how far you can take it.
- pdimitar 4y ago
  Nah, not specifically about the REPL itself, I just need a way to quickly sketch and run a piece of code is all. I know big IDEs support this but I prefer keeping everything in the terminal -- I'll have to go check if Emacs or NeoVim offer something along those lines.
  - kupfer 4y ago
    Maybe take a look at evcxr, it runs in a terminal and is REPL like. When I'm dabbling in rust, I use it e.g. to quickly try out library functions and how to work with the result. But I'm just getting started.
    - pdimitar 4y ago
      Thank you, I will.
okeuro49 4y ago
It sounds like Java and IntelliJ's debug "Evaluate expression" feature.
- pdimitar 4y ago
  Yeah but... I want to stick to the CLI. Or in GUI Emacs. I'll have to check how does NeoVim fare with these things.
selfmodruntime 4y ago
I love the idea of Elixir, but I just can't get into it because of its weird choice of sigils. |> for pipes and <- for assignments, seriously? I seriously dislike programming languages which choose two character sigils for basic operations. I also heavily dislike |x| in Rust.
- pantulis 4y ago
  Not to get on the merits of Rust or Elixir, but while you are absolutely entitled to your preferences I should suggest that perhaps you may miss out something important by ditching languages based purely on the format of sigils.
- goatlover 4y ago
  It's like whitespace in Python, parens in Lisp, begin/ends in Ruby, or 1-based arrays in Julia. You get used to it and eventually it feels natural when using that language.
- pdimitar 4y ago
  Not going to judge you. When you feel a bit more generous and adventurous, I recommend you give it another go. Syntax is easy enough. Like all programming languages, you'll get used to it in a weekend and won't even notice it afterwards. Elixir is absurdly productive: very terse code, very self-explanatory stdlib API, transparent concurrency / parallelism, and in-OS-process high availability and mostly-self-healing hierarchy of green threads and supervisors observing them. People on HN and Reddit really love to roll their eyes at stuff that's getting popular, and likely will avoid the technology out of a misplaced spite, just because a lot of people are talking about it. It's a weird phenomena. (Not saying you're doing it, I just kinda got carried away here.)
- iudqnolq 4y ago
  Minor clarification: Elixir uses = for assigment. There's a special construct called "with" that's basically fallible pipes, and that's probably where you saw <- with {:ok, id} <- get_id(), {:ok, val} <- get_val(id) do show_success(val) else {:error, e} -> # We reach this if either get_id or get_val fails show_error(e) end
elcritch 4y ago
The Rust tendency toward “golfing” is why I don’t like it. It’s not even lifetimes, but the way traits are setup. And the lack of unified function call syntax. Sometimes it’s a function, sometimes a method — that distracts a lot from the problem at hand IMHO.
- steveklabnik 4y ago
  You can call any method as a function, if you'd like. foo.bar(baz) becomes bar(foo, baz) Though you may also need to add in some &s and/or *s, because method call syntax autoref/derefs, and function call syntax does not.
sitkack 4y ago
While not Elixir good, the evcxr python notebook plugin gets you 50% of the way there. https://depth-first.com/articles/2020/09/21/interactive-rust-in-a-repl-and-jupyter-notebook-with-evcxr/ https://depth-first.com/articles/2020/09/21/interactive-rust... https://github.com/google/evcxr https://github.com/google/evcxr The other option is to use the playground, https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d87aebdc6efff6396ad923a2ed371fb6 https://play.rust-lang.org/?version=stable&mode=debug&editio...

dhbradshaw 4y ago

Try using a test -- can stick anywhere and just run code there (push of a button with analyzer in vscode). Almost like embedding a repl into a module for experimentation.

pdimitar 4y ago
Haven't tried but definitely will, thank you!

serverholic 4y ago

See this is what I’m scared about in my current job. We have some people who want to use dynamically typed languages and some who want to use static. I don’t think being able to brain dump code is a good thing and it leads to an unmanageable mess when you have a large codebase. Types are essential as far as I’m concerned, but I constantly have to get into arguments with the dynamic type fans because their “flow” Is being restricted.

pdimitar 4y ago
Be a bit more charitable. :) Brain-dumping is simply a way to iterate and figure out what works and what doesn't, quickly. After I do it I take the requisite time to emulate exhaustive pattern matching, and add tests that cover the functionality well. My problem with Rust, and I love the language a lot, is exactly this: I want to quickly find what would work. After that I'm very happy to take the proper time to go things rigorously.
- serverholic 4y ago
  Yes and then someone comes along and makes a change that breaks something seemingly unrelated and it’s less likely to be caught because there is no type system. And please don’t say tests solve that because they don’t. They help but they don’t solve it.
  - pdimitar 4y ago
    You won't catch me arguing with that. I work both with dynamic and static languages and usually I'll pick the static ones. Dynamic languages are very valuable when you can afford to iterate and gradually find out the golden path. For the better or the worse, many businesses are of that type. That being said, I just ended an Elixir contract and absolutely want to code Go or Rust for money again.
- tele_ski 4y ago
  I do appreciate that you write tests. I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests. I tend to think more than write code, so usually my first go is reasonably close to what I need. But there are always edge cases you just never think about. I'd rather have a strong debugger than a repl imo
  - pdimitar 4y ago
    > I find it's like pulling teeth with most devs to get them to write anything but the most basic of tests You are unfortunately very correct (at least in my 21 years of experience as well). I too feel annoyance when I know that I made a piece of code work well but (a) every now and then I am truly wrong and (b) various pieces of the system in the code interact in sometimes unexpected ways, unveiling inputs to your code that you haven't foreseen. So even though it often takes a heavy and annoyed sigh out of me, I still roll up my sleeves and add the tests because I've shot myself in the foot too many times, and ignoring past experience is just being a stupido. As for debugger/REPL, they are not orthogonal; you can have both. I'd more contrast debugger with tests themselves -- both are ways to go step by step through a process that you know is faulty somewhere. REPL to me is just a way to more quickly sketch a v1.0 of a piece of code, nothing else.

kupfer 4y ago

Is it just about a REPL? There is the evcxr hack, though I'm not sure how far you can take it.

pdimitar 4y ago
Nah, not specifically about the REPL itself, I just need a way to quickly sketch and run a piece of code is all. I know big IDEs support this but I prefer keeping everything in the terminal -- I'll have to go check if Emacs or NeoVim offer something along those lines.
- kupfer 4y ago
  Maybe take a look at evcxr, it runs in a terminal and is REPL like. When I'm dabbling in rust, I use it e.g. to quickly try out library functions and how to work with the result. But I'm just getting started.
  - pdimitar 4y ago
    Thank you, I will.

okeuro49 4y ago

It sounds like Java and IntelliJ's debug "Evaluate expression" feature.

pdimitar 4y ago
Yeah but... I want to stick to the CLI. Or in GUI Emacs. I'll have to check how does NeoVim fare with these things.

selfmodruntime 4y ago

I love the idea of Elixir, but I just can't get into it because of its weird choice of sigils. |> for pipes and <- for assignments, seriously? I seriously dislike programming languages which choose two character sigils for basic operations. I also heavily dislike |x| in Rust.

pantulis 4y ago
Not to get on the merits of Rust or Elixir, but while you are absolutely entitled to your preferences I should suggest that perhaps you may miss out something important by ditching languages based purely on the format of sigils.
goatlover 4y ago
It's like whitespace in Python, parens in Lisp, begin/ends in Ruby, or 1-based arrays in Julia. You get used to it and eventually it feels natural when using that language.
pdimitar 4y ago
Not going to judge you. When you feel a bit more generous and adventurous, I recommend you give it another go. Syntax is easy enough. Like all programming languages, you'll get used to it in a weekend and won't even notice it afterwards. Elixir is absurdly productive: very terse code, very self-explanatory stdlib API, transparent concurrency / parallelism, and in-OS-process high availability and mostly-self-healing hierarchy of green threads and supervisors observing them. People on HN and Reddit really love to roll their eyes at stuff that's getting popular, and likely will avoid the technology out of a misplaced spite, just because a lot of people are talking about it. It's a weird phenomena. (Not saying you're doing it, I just kinda got carried away here.)
iudqnolq 4y ago
Minor clarification: Elixir uses = for assigment. There's a special construct called "with" that's basically fallible pipes, and that's probably where you saw <- with {:ok, id} <- get_id(), {:ok, val} <- get_val(id) do show_success(val) else {:error, e} -> # We reach this if either get_id or get_val fails show_error(e) end

elcritch 4y ago

The Rust tendency toward “golfing” is why I don’t like it. It’s not even lifetimes, but the way traits are setup. And the lack of unified function call syntax. Sometimes it’s a function, sometimes a method — that distracts a lot from the problem at hand IMHO.

steveklabnik 4y ago
You can call any method as a function, if you'd like. foo.bar(baz) becomes bar(foo, baz) Though you may also need to add in some &s and/or *s, because method call syntax autoref/derefs, and function call syntax does not.

sitkack 4y ago

While not Elixir good, the evcxr python notebook plugin gets you 50% of the way there. https://depth-first.com/articles/2020/09/21/interactive-rust-in-a-repl-and-jupyter-notebook-with-evcxr/ https://depth-first.com/articles/2020/09/21/interactive-rust... https://github.com/google/evcxr https://github.com/google/evcxr The other option is to use the playground, https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d87aebdc6efff6396ad923a2ed371fb6 https://play.rust-lang.org/?version=stable&mode=debug&editio...