Hacker News Reader

Comment by vlovich123 | Hacker News Reader

> Hence, when the compiler is run in production mode, we disable the lie that allows the implicit Debug effect. As a result, using dprintln in production mode causes a compilation error.

The team can’t seem to make up its minds of the language is intended for high performance or not. They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code (eg imagine something like a browser and you’re trying to figure out some weird behavior that’s difficult to catch in a debugger but too slow to reproduce in a debug build or even not reproducible due to different timings resulting in different race conditions)

Also blaming the users of your language for your language not being able to meet their needs isn’t a good look. It suggests the language is probably attracting the wrong users or positioning itself incorrectly in the market place.

View on HN

This seems like an uncharitable reading of the post.

> They talk about the importance of purity for automatic optimizations but in the real world there’s all sorts of practical reasons for needing to debug production compiled code

I imagine they're talking about their defaults. One can commonly reconfigure how different build profiles work.

> Also blaming the users of your language for your language not being able to meet their needs isn’t a good look.

Isn't that what the whole post is about though? They even say the following.

> Returning to earth: we may be academics, but we are trying to build a real programming language. That means listening to our users and that means we have to support print debugging. The question is how?

> What do you mean turning off the fuel for the engines crashes the plane? I thought you said this was a safe airplane?!

Things like this - they're painting users of programming languages as the ones being unreasonable.

> I imagine they're talking about their defaults. One can commonly reconfigure how different build profiles work.

From the article:

> We don’t want published packages to (a) lie to the type and effect system, or (b) contain print debugging statements > As a result, using dprintln in production mode causes a compilation error.

There is no documentation about the existence of build profiles or how they might work. I think you're reading too charitably.

We think that functional programmers should be able to write e.g. `List.count(x -> x > 5, l)` (or e.g. use pipelines with |>) and have it run as fast as an ordinary imperative loop with a mutable variable. The Flix compiler gives them that-- but it requires the program to undergo certain transformations that may require expressions to be moved around and eliminated. It is dangerous to perform such optimizations with incorrect assumptions about types or effects. How to support that together with print-debugging is the challenge.

For systems in production, we have the `Logger` effect and associated handlers.

And yet modern optimizers don’t actually seem to have a problem with a transformation like that as you must know. Try list.iter().filter(|x| x>5).count() in Rust

And yes, Rust doesn’t have an effect system yet, but others have mentioned Haskell and how it handles tracing and logging and the limitations of effect systems interplaying with such things.

It was a simple example; whether a specific optimization applies is very tricky. We have to look at the details. When can Rust move or eliminate a binder? Does Rust support automatic parallelization? What happens if you use unsafe blocks to lie to their type and ownership system? I think many of the same issues will surface.

To be me, the interesting question is: What happens when you lie to the type (and effect or ownership) system?

> Does Rust support automatic parallelization

No, and there's no indication that automatic parallelization is at all worth the effort vs having the author explicitly annotate which things need parallelization (e.g. Rayon is drop-in for many tasks where you know you'll need it). Otherwise you're at the mercy of heuristics baked into the language which in practice never work out well and also slow down the non multithreaded use-cases.

> To be me, the interesting question is: What happens when you lie to the type (and effect or ownership) system?

As others have said, just having the print get elided if the operation gets optimized out would be fine. That's what Haskell does. It's a weird choice to look at the challenges of effect systems and conclude the effect system idea is perfect it's the programmers who are wrong and not that the effect system has gaps that can't be addressed and solve it in other less surprising ways.

Reply on news.ycombinator.com