Hacker News Reader

Comment by gpderetta | Hacker News Reader

>Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want.

I'm not a rust programmer, but I guess that's an issue if you come from a dynamic language, not from c++.

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.

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.

Haven't tried but definitely will, thank you!

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.

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.

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.

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.

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

> 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.

Rust needs an interpreter mode for fast-turnaround of brain dump

Yep, I definitely wouldn't refuse one.

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

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.

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.

Thank you, I will.

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

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.

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.

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.

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.

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.)

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

Even F# uses |> for pipes and Rlang uses <- for assignments. This is not a Elixir only thingy.

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.

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.

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...

https://github.com/google/evcxr

The other option is to use the playground, https://play.rust-lang.org/?version=stable&mode=debug&editio...

Reply on news.ycombinator.com