Hacker News Reader

This is very thoughtful :)

So I _do_ like Rust for other reasons, or at least, I did initially. My opinion has changed over time. I used to say "I'd never write web application in Rust," but soon, I'd prefer it slightly. Needs some more libraries to come out, and they're close...

There's two sides to "is the flipside true"? One is, there's a huge variety of static type systems. Some of them are more flexible than others. So for example, if I had to use Java 1.4, or even Java 1.5 (which are very old, but were two releases I am very familiar with), I'd wish I was back in Ruby. This is because it's _too_ rigid; I can't express enough things in the type system to make up for the lack of flexibility. In a language with a better type system (and Java itself has a better one today, even), it changes the value of the equation.

In Rust though, there's another axis: speed, memory usage, stuff like that. I don't miss Ruby's flexibility here, because even basic operations in Ruby are _so so so_ much more expensive than in Rust. So when I think "oh yeah, I could do that, but if I think about how Ruby does it under the hood... it's not worth the cost." This makes me miss Ruby less as well.

Ruby is an excellent language, and I will always love working with it. But there's only so many hours in the day, and I've spent so much time with it already...

Are you talking about strong typing or static typing? I've been using statically typed languages for 20 years (C++, Java, Objective-C) and I haven't gotten tired of it yet. Especially when working in a large code-base I didn't write, Python is rough. What's a "session"? Who knows, guess I'd better put `print type(session)` and figure out how to get that function executed.

Although, the thing that bothers me about Python (haven't used Ruby) is the fact that it is interpreted. It's really annoying to have to run my program to discover syntax errors and typos, when a compiled language would do that for me. With interpreted and dynamically typed languages, you have to have 100% test coverage, because you have no idea if your code is even syntactically valid until you run it, and of course if it isn't valid, then you throw an exception. (Hopefully that crashes the program, unless someone was brilliant enough to catch all exceptions and not print any error messages, then it looks like everything worked fine until you discover it didn't.) So every change is a potential for an exception, until you execute that line of code to make sure there wasn't a misspelled variable name or something.

So, yeah, I love the compiler. (I also love Python for scripty stuff.)

> With interpreted and dynamically typed languages, you have to have 100% test coverage, because you have no idea if your code is even syntactically valid until you run it, and of course if it isn't valid, then you throw an exception.

I think you mean _semantically_ valid, e.g. no undefined variables. Most dynamic languages provide file-level syntax checking, rather than line-level. But I completely agree that this is the easiest argument against dynamic languages. Computers are better at bookkeeping than humans, and we should use them as such.

> until you execute that line of code to make sure there wasn't a misspelled variable name or something

But isn't it the purpose of tools such as IDEs? PyCharm is pretty damn good at it. Of course, it's not always possible or convenient firing up an IDE. But I suppose editors such as vim should be fully capable of doing this via plugins as well.

The best use case I know of is avoiding the common Python & Ruby pitfall of "just stick everything in a dictionary and index it by key". Welp, forgot to update every instance of that string index (particularly if that name overlaps with anything else, including variable and function and class names... so, like, a lot of the time).

Yeah, no, I don't think that is the job for an IDE. Maybe for you on your desktop, but your software should work regardless of any IDE or editor.

Languages I use most are Rust and Ruby. I find the type system not frustrating, but challenging, on occasion. But only when I'm trying to write a library with a very convenient, flexible API. Its probably easier to write the first draft of this sort of library in Ruby, but in my experience what the library does under edge cases and bugs is often super unpredictable. Not so much in Rust.

I haven't had these frustrations in application code in Rust.

Have you tried crystal? Looks like it could be the best of both worlds.

I've worked primarily in Java and C++ for the past few years, but also with several dynamic languages. I sometimes miss the expressiveness of Python, but I can't say I'm ever frustrated by a strong type system nor does the compile step annoy me as long as my write-compile-test cycle is reasonably quick (usually achievable). With Java 8, and even more so with Rust, I'm less frustrated by the lack of expressiveness, so I find myself missing dynamic languages even less.

> but I can't say I'm ever frustrated by a strong type system

Never? I can't say it happens very often but occasionally the type system get's in the way, usually when you want the function to be type T1 but sometimes it'd be convenient to do a little bit more if the type is also T2.

Rust supports algebraic types and switching over the type, which handles your example quite efficiently. You would simply define an algebraic union of T1 and T2, and switch on the type into the desired code for each branch.

What does that look like in code? I was using c# so I did the dirty:

T1 arg;

var foo = arg as T2;

if (foo != null)

  ....

Also, how do we format code here?

I expect Rust should be able to handle this nicely, but I'm more familiar with Pony... So here's how to do it nicely in it:

    fun f(x: (T1 | T2 | None)): ReturnType =>
      match x
      | T2 => /* do something */
      | T1 => /* do something else */
      | None => /* Handle badly behaved. Optional to have, compiler can enforce good behaviour if you want. */

Note: You can see formatting at https://news.ycombinator.com/formatdoc

In Rust, you'd define an `enum` of two types.

    enum Either {
        Type1(T1),
        Type2(T2),
    }

let's say you get a value of type Either

then you can match on them:

    match value {
        Type1(v) => func(v),
        Type2(v) => func2(v),
    }

Does that let you work with the default type? What I was doing in c#:

  function(T1 thing) {
    //do normal T1 stuff here
    var foo = arg as T2;
    if (foo != null)
      foo.T2Stuff();
    //more normal T1 stuff
  }

If I'm understanding your example I would have to wrap all the T1 stuff in a match.

Yes, you do. There is no idea of a 'default' type here, because each variant of the enum is treated exactly the same. Your C# example assumes an inheritance relationship between T1 and T2 (i.e. T2 inherits from T1, so you can pass it to something expecting a T1 reference).

Rust doesn't have type inheritance, so the only way you can define relationships between types is to have something external tell you how to package them together, which is what the enum would do here. So it's not a parent-child relationship between the types, it's a new thing which says "here is a thing which can be a T1 or a T2 but not both at once".

Not having OO does require you to think somewhat differently about how to build your data structures in Rust. I've found my intuition from Haskell is a stronger guide when working with Rust, but since Rust's type system is much more like that in an ML-family language this makes quite a bit of sense! Sadly this does increase the learning curve for more mainstream languages.

(Rust does have trait inheritance, but all that says is that to implement trait T2 you have to also implement trait T1, and thus anything working with a T2 can assume that thing is also a T1).

Thanks.

The above example was actually using two entirely different interfaces. It seems like rust is quite similar to the OO subset I prefer to use. In this particular case it would have been a better match because traits can implement methods.

Rust is on my "to learn" list over the holidays.

Yes, you'd have to wrap it in a match. But maybe you don't have to.

If T1 is the normal case, then there's a type in Rust called Result that handles this kind of pattern.

    fn potentially_failing(thing: Result<Type1, Type2>) {
        thing.map(|foo| success_case(foo));
    }

this will only execute in the success case and ignore the error case

map_err does the same, but only touching the error case

Thanks, that's pretty cool.

Its nice to "take a break" from static types once in a while and hack together some kind of data munging script in python every once in a while. But every time I have tried to go larger in scope I ended up regretting it. I'm not sure I would want to do any kind of dynamically typed programming professionally again.

The main languages I use with work are:

* C

* Scheme (Gambit)

* Python 3.4

* Pony

I find all of them frustrating at times.

Python's dynamism is nice, but it's so damn inflexible, requiring my to follow the One True Way.

That can be good, and makes it easier to eliminate bad code in reviewing.

But it also means that you can fight with the interpreter to do what you want.

Scheme gives me both dynamism and flexibility, with less speed tradeoffs. Yay!

However, there was someone on my team obsessed with turning everything into a macro.

What's the point of first-class functions if you just macro everything?

Also, Scheme's stdlib is purposefully small, so you sometimes need to reinvent the wheel. Thankfully Scheme makes it both easy and pleasurable to do so.

The rundown is, though fast and dynamic, code review can be painful unless you follow standards, and you might run up against, "Oh... I need to build my own FTP library", though SLIB (depending on your circumstances), can eliminate some of that.

C's compiler feels like a breath of fresh air after that.

Unless you hit a runtime error, it makes writing code a breeze, quickly and efficiently.

Unfortunately, it doesn't protect you against yourself, or lazy people on the team trying to use void pointers for everything.

So code review can be harder, and catching edge case segmentation faults can be quite difficult.

Enter, Pony.

Pony deals with the same areas Rust does, but for reasons I won't go into, when both Rust and Pony were young, my team started using Pony for a few little things.

It has been... An experience.

Pony is very type safe, it is exception safe, and data race free, all enforced by the compiler.

Which sometimes means the compiler will sit there bashing your code for a full day before you realise that you weren't writing it safe enough, and you can't just tweak it, the whole thing needs to be rewritten.

Also, the Actor Model being central to everything can be quite annoying, when you just need to fit a couple extra functions in somewhere, but you aren't sure where's best.

However:

The compiler doesn't let you screw up.

What you do write can become massively concurrent fast programs, easily.

Pony also has some fairly good documents, for such a young language that really doesn't have the backing of Rust.

So...

I get frustrated with any language I am forced to deal with over time.

I wish Python had compile-time contracts, but there is mypy to ease the pain now.

I wish Scheme had a better stdlib, but it goes against the ethos. (See RSR6 community breakdown).

I wish C was safer, but it's lack of safety makes it easier to do things like JIT.

I wish Pony was more flexible, but it'll never let me point a shotgun at my own foot.

If I spend too long in any world... It's time for a breath of fresh air.

Can you talk more about using Pony in a production environment? What are the performance aspects of it? How do you find writing 'non-actor' code - like just doing some string manipulation?

I find the language fascinating but I'm learning Erlang and I don't really want to get started with Pony at the same time. Do you have experience with Erlang?

what made you choose Pony?

Sorry for the bombardment of questions but I don't hear much about Pony. As a rust user, and a burgeoning fan of Erlang, I'm fascinated.

I've never met anyone else using Pony in production, so I'll try and give the best answer I can.

> What made you choose Pony?

We wanted a Type Safe language to run a REST API frontend. That is to say, we wanted to have something that could redirect requests to the appropriate servers, at scale, whilst maintaining Type Safety in the server itself. We got hit by so many issues from JSON's weak/absent typing causing runtime errors, we wanted something that could sanely prove that we wouldn't crash.

Whilst we were at it, the same language seemed great for the backend for a couple languages we develop in-house. For example, Owlang is a language developed for teaching with a group of teachers. The first iteration was written in Scheme, today, it runs on top of Pony.

We considered three languages:

* Rust

* Pony

* Erlang

Erlang was a bit odd to throw in the mix, but we couldn't ignore how amazing BEAM is, especially with recovery by dropping and creating thousands of processes without effort.

However, we found Rust was making too many breaking changes, and there was sort of a culture of using Rust Nightly, which doesn't give off a nice solid feel, or didn't back then.

Erlang has this sort of huge cognitive overload with it's syntax, making it take longer to learn, for no obvious benefits.

Pony's Philosophy[0] however, felt damn good, and we investigated their mathematical proof of safety and the like.

> Can you talk more about using Pony in a production environment?

Pony's got a few gotchas. Thankfully, they spell them out. [1]

We have been burned from long running procedures when we've had to tap out to an in-house C library. We went from using around 400mb of RAM for a group of processes, to running out of memory on a 16GB RAM machine.

That was a stupid mistake. However, using a Timer, like the docs tell you to, obliterated that, and we dropped back down to 4-500mb.

The non-preemptive nature of Pony's scheduler has taken a few people, myself included, some time to get used to.

> How do you find writing 'non-actor' code - like just doing some string manipulation?

If you try and avoid the fact you're using Actors, it'll bite you. Pony is designed for concurrency.

However, if we're just talking about methods and classes and so on, and how they feel... Pony feels simple, and easy to use.

Traits and interfaces make subtyping a breeze, especially interfaces.

But, being interested in Erlang, how about some pattern matching?

    fun f(x: (String | None), y: U32): String =>
      match (x, y)
      | (None, _) => "none"
      | (let s: String, 2) => s + " two"
      | (let s: String, 3) => s + " three"
      | (let s: String, let u: U32) if u > 14 => s + " other big integer"
      | (let s: String, _) => s + " other small integer"
      else
        "something else"
      end

One more bonus for something Pony has, that proved unexpectedly useful, is the ability to have multiple, or generate, Environments. In terms of Pony, that means argc, argv, argp. Being able to isolate environment variables between processes has been useful for making some configuration easier.

[0] https://tutorial.ponylang.org/#the-pony-philosophy-get-stuff...

[1] https://tutorial.ponylang.org/gotchas/

> Erlang has this sort of huge cognitive overload with it's syntax, making it take longer to learn, for no obvious benefits.

That's just weird. How much of an effort did you even put into it? Erlang may have ugly syntax but it's the simplest syntax of all popular languages and the cognitive load while writing is pretty much the lowest I've come across. The language itself is tiny. Or did yo mean you weren't used to a functional language and that was the cognitive overload?

I use Scheme extensively, which I would argue has the least syntax of the functional languages.

Erlang seems simple on the surface, but each type seems to have it's own DSL, allowing things that seem the same, to not be, which means you have to hold more context in your head.

e.g. Are these two the same?

  ensure(A, B) ->

  if A == B ->

Does -> always mean function? Or does it mean something similar to progn or begin from CL and Scheme? Or does it vary with context?

I had issues teaching where to use ; or . or end, and having people actually comprehend the reasons enough to do it without thinking.

At least with Scheme it's always )

We also investigated using Elixir, which has less overhead, and more people find easier to get up and running with. However, at the time Mix wasn't stable yet, which counted it out.

I think you mistook a barrier to entry (getting over the syntax) for a permanent cognitive load. At our company we don't care if you know erlang or not, but we expect a developer to learn it on the job and have had no issues either with junior or experienced developers. All who've tried it are amazed at the productivity.

Awesome. Thanks a lot. I'll have a look at those links with this context.