Hacker News Reader

Comment by WJW | Hacker News Reader

Sounds a lot like programming in Haskell. Applying higher-order functions or condensing a parser into a oneliner just makes me feel smart in a way that generating a new Rails controller never does.

My personal theory is that a lot of Rust and Haskell (and many other "advanced" languages) usage is caused by people chasing that feeling. The publicly expounded benefits like memory and type safety are true, but the real reason is that people want to use the language for their own reasons and "I really like it" usually does not have enough weight in a business context.

View on HN

Unlike Haskell, Rust offers a unique combination of safety and runtime performance, which does provide real business value in sone domains.

Algebraic data types, monads, and things based around those have tons of business value for writing correct business logic for non-performance critical code. You get that in haskell.

Though admittedly you can get them other functional languages that are not quite as different. Like Ocaml.

Monads are so cumbersome to implement and consume in OCaml that they are not very commonly used. Jane Street Core has monadic abstractions for things like async but it’s a pain without syntax extensions.

That was true until 4.08. OCaml now supports monadic let bindings, and more generally, user defined let bindings [1].

You get the benefits of ppx_let (Jane Street) but in a more general and syntactically nicer form. I still wouldn’t call it as nice as do notation in Haskell but it makes monads highly usable in OCaml without the need for an external dependency.

[1]: https://github.com/ocaml/ocaml/pull/1947

Wow, I completely missed this! Nice.

Rust's safety and runtime performance are not unique, and these properties can be improved further from the level of Rust. Have a look at ATS:

- http://www.ats-lang.org

- https://www.youtube.com/watch?v=zt0OQb1DBko

What kind of project would be a sweet spot to ATS? Would it be comparible with F* [1]?

I would love to understand the nature of the theoretical advantage ATS has here over Rust.

ATS seems to be very much a concept/language in R&D phase. Its ergononics are difficult ergonomics (have a look at the error messages), documentation and example projects sparse.

[1] https://fstar-lang.org/

> What kind of project would be a sweet spot to ATS?

I'd say a large mission-critical C codebase that decides to grow and expand a formally-verified kernel of its most important functionality - it can be a real-time sytem, an OS kernel, a HFT algorithm etc.

Nowadays people seem excited about gradual typing in widespread dynamic languages like JavaScript and Python, because it allows them to adopt the best parts of static typing without having to rewrite the entire codebases in new langauges. Now imagine that you can introduce gradual formal verification to your battle-tested C codebase, without a loss in performance[1] and without forcing you into a new tooling ecosystem (compiler, debugger, profiler etc). Actually, you don't need to imagine it, because that's what ATS is :)

> I would love to understand the nature of the theoretical advantage ATS has here over Rust.

I'd say it's a synergy of two key features, that produce miracles when put together - 1) direct and safe pointer arithmetics [2], which enables the same data structures and optimisation tricks available in C, yet in a verifiable environment, and 2) refinement types [3].

> Would it be comparible with F*

Unfortunately, I don't know much about F*, MS Research regularly releases a new PL prototype after the other and I lost my count on Koka[4].

> ATS seems to be very much a concept/language in R&D phase. Its ergononics are difficult ergonomics (have a look at the error messages), documentation and example projects sparse

All true, but nonetheless it's a solid implementation of the mentioned theoretical parts, and if one dares to get through the objective lack of docs and ambigouos compiler messages, they are rewarded with an impressively powerful production-ready system-level compiler, complimentary to their standard C ecosystem which has decades of accumulated wisdom. That's the level of code-reuse other ecosystems can only dream of.

[1] http://blog.vmchale.com/article/ats-performance

[2] http://blog.vmchale.com/article/ats-safe-pointers

[3] http://ats-lang.github.io/DOCUMENT/INT2PROGINATS/HTML/c2584....

[4] https://www.microsoft.com/en-us/research/project/koka/

As someone who needs parsers in a daily basis, I got hooked by your "oneliner parser". A search for parser generation in Haskell only gave me typical parser generators. Can you point some examples?

What you'd want to google is "parser combinators" or "parsec tutorial" I think. The idea is that parsers are "just" functions and can therefore be combined with higher order functions in various ways to produce "bigger" parsers. For example, an element in the Redis replication stream can be either an Array, a BulkString, an Integer, an Error or a SimpleString and you can express that with the `choice` function:

  parseRedisValue = choice [ parseRedisArray, parseRedisBulkString, parseRedisInteger, parseRedisError, parseRedisSimpleString]

Each of the underlying parsers (ie `parseRedisArray` etc) are also built up out of smaller parsers, all the way down to parsers that just detect a single character. It seems like it should be slow, but in my experience the results have not diappointed yet. If you're interested, I wrote a longer example on my blog, at http://www.wjwh.eu/posts/2019-01-01-parsing-infinite-streams...

Reply on news.ycombinator.com