Live data from Hacker News

Functional programmers need to take a look at Zig

pure-systems.org

121–130 of 163 posts

Re: Functional programmers need to take a look at Zig

#121

My stack today is kinda nice but perhaps a bit odd: - Go - backend + CLIs - TypeScript - fronted, occasionally zx for more complex scripts - Nushell as my scripting language (I’ve been relentlessly using it everywhere I can instead of bash/zsh and man it is such an improvement) I heard so much good stuff about both Zig and Rust and would love to eventually get to know one of them.

nushell + 1. After ~20 years of bash+zsh, I'm translating all my scripts to nu.

Yesterday I noticed I still don't know how to write

  ls | where modified 
in zsh after all years.

Re: Functional programmers need to take a look at Zig

#122

While using "monads" in functional languages is a neat trick, I do not like them. In my opinion, the concept of automaton is fundamental and it deserves equal standing with the concept of function (even if it is a higher level concept that is built upon that of function). I believe that functional programming is preferable wherever it is naturally applicable, and most programs have components of this kind, but most c…

For me monads are similar to inheritance. There are areas where one topic/functionality is dominant and it can really help to define a base class in a library or define a monad like for async. The moment you start to mix/compose things, things get ugly pretty fast.

Re: Functional programmers need to take a look at Zig

#123
post #85
post #26

Earlier quoted context omitted.

Low-level doesn’t mean more information, it means more explicit. In Zig, that means being able to use the language itself to express type level computations. Instead of Rust’s an angle brackets and trait constraints and derive syntax. Or C++ templates. Sure, it won’t beat a language with sugar for the exact thing you’re doing, but the whole point is that you’re a layer below the sugar and can do more. Option is trivi…

> Option is trivial. But Tuple ? Parameterizing a struct by layout, AoS vs SoA? Compile time state machines? Parser generators? Serialization? These are likely where Zig would shine compared to the others. I don't see how any of that becomes easier in the Zig case. It's just extra syntactic ceremony. The Rust version conveys the exact same information.

It’s precisely not syntactic ceremony. It’s normal Zig running at compile time in which you can program types as values. In Rust (and most other languages) all you get is a highly abstract DSL:

Foo where for T: Bar

Information dense, but every new feature needs language design work. Zig lets you express arbitrary logic, loops, conditionals, etc. It’s lower level of abstraction than a type constraints DSL.

For example, adding “the method in this trait is Send” to Rust’s DSL took a whole RFC and new syntax. The Zig equivalent could be implemented with an if statement on a type at comptime.

Or how about the transformation of an async function into a state machine. Years of work, deep compiler integration, no way to write such transforms yourself. Same with generators, which still aren’t stable. I’d really like to be able to write these things like any other program.

If you don’t want or need to express things at this lower level of abstraction, fair, same reason most people stick to scripting languages and don’t think about memory layout. But “extra ceremony” is really underselling it.

Re: Functional programmers need to take a look at Zig

#124
post #118
post #108

Earlier quoted context omitted.

Note that Java makes breaking changes all the time, which is why it publishes a compatibility guide with each major release. These are usually judged to be minor breakages, but if you have a codebase on the order of millions of lines, there's a very good chance that at least one thing will break and require a little bit of work to upgrade. And Java's not unique here, every stable language makes changes all the time t…

Not that I need to tell you of all people, but I do find that Rust's editions system is one of the better ways to minimise this issue.

Indeed, editions are brilliant for making relatively large changes in a way that fully preserves backwards compatibility for codebases in the wild, but the existence of editions doesn't mean that Rust is exempt from sometimes desiring to make minor breaking changes in new versions for all editions. For that, it has the mechanism of future incompatibility lints, to give people ample advance warning: https://doc.rust-lang.org/rustc/lints/index.html#future-inco...

Re: Functional programmers need to take a look at Zig

#125
post #115
post #26

Earlier quoted context omitted.

Low-level doesn’t mean more information, it means more explicit. In Zig, that means being able to use the language itself to express type level computations. Instead of Rust’s an angle brackets and trait constraints and derive syntax. Or C++ templates. Sure, it won’t beat a language with sugar for the exact thing you’re doing, but the whole point is that you’re a layer below the sugar and can do more. Option is trivi…

I don't think there is a standardized meaning of 'low-level'. I think a useful definition is that a low-level language controls more/is explicit about more properties of execution . So zig/c/c++/rust all have ways to specify when and where should allocations happen, as well as memory layout of objects. Expressivity is a completely different axis on which these low-level languages separate. C has ultra-low expressivit…

It’s one specific low-level abstraction, which is well defined: the primitive building blocks a higher level abstraction is built on and oblivious to.

Zig’s comptime is the primitive. Sum types, generics, etc. are things you can build on top.

The original example is the type-level equivalent of looking at:

  int foo() {
    return 4;
  }
and saying “why do I need all this function and return ceremony when I can just write the number 4 verbatim?”

Re: Functional programmers need to take a look at Zig

#126
post #100
post #62

Earlier quoted context omitted.

I am in a similar place. Especially regarding Bash. Used to be in a few companies where most developers just couldn’t/wouldn’t write in more than one language and it was always a pain to maintain different runtimes, languages, packages and internal dependencies of things that could have been a 20-line bash script, and had to be maintained and updated from time to time. I understand people have their own limitations a…

Funny, I have also converged on shell scripts for simple scripting or configuration, but I use /bin/sh for portability. Many of the machines I use do not even have bash installed.

When i talk about my "bash" scripts, i mean sh. I assume this is the same forgp (tbh, i tend to use AWK over bash in 80% of cases, but i call it from bash anyway, and still call it bash scripting :/)

Re: Functional programmers need to take a look at Zig

#127
post #126
post #100

Earlier quoted context omitted.

Funny, I have also converged on shell scripts for simple scripting or configuration, but I use /bin/sh for portability. Many of the machines I use do not even have bash installed.

When i talk about my "bash" scripts, i mean sh. I assume this is the same forgp (tbh, i tend to use AWK over bash in 80% of cases, but i call it from bash anyway, and still call it bash scripting :/)

Yep I'm the same. I just call it bash. I think old habits die hard.

Re: Functional programmers need to take a look at Zig

#128

These days I just use a few languages: 1. Go, when I first saw code I wrote almost a decade ago still compiles and runs in Go, I decided to use Go for everything. There were some initial troubles when I started using it a decade ago, but now it's painless. 2. Haskell, I use it for DSL and state machines. 3. Bash for all deployment scripts and everything. 4. TypeScript, well for the frontend. Lately, I’ve been using G…

IME Ruby is really good for working alone on tiny projects without an IDE (trying to get more than syntax highlighting causes problems). Sometimes I write single-file scripts or even just use interactive Ruby.

Ruby remains a joy for small things. I also tend to use it in place of Bash when I can.

Re: Functional programmers need to take a look at Zig

#129
post #108
post #104

Earlier quoted context omitted.

Well, Java would compile and work for 3 decades straight. If anything, go did have an actual breaking language change (for loop variable capture)

Note that Java makes breaking changes all the time, which is why it publishes a compatibility guide with each major release. These are usually judged to be minor breakages, but if you have a codebase on the order of millions of lines, there's a very good chance that at least one thing will break and require a little bit of work to upgrade. And Java's not unique here, every stable language makes changes all the time t…

Sure, though most of the time it's library-only, not language change (with the only exception I have in mind is new keywords, but those are pretty rare with java).

All in all, Java is pretty unique in the level of backwards compatibility it provides, I don't think any other language is comparable to this level. Especially that it is both source and binary compatibility.

Re: Functional programmers need to take a look at Zig

#130
post #38

Earlier quoted context omitted.

i dont think its generally a good idea to be making complex type generators like this in zig. just write the type out. the annoyingness of the thing you tried to do in zig is a feature. its a "don't do this, you will confuse the reader" signal. as for optional, its a pattern that is so common that it's worth having builtin optimizations, for example @sizeOf(*T) == @sizeOf(usize) but @sizeOf(?*T) != @sizeOf(?usize). i…

The point is that algebraic data types are common in functional languages. "Maybe" is just an example of an algebraic data type, there's tons more. If the article says "functional programmers should take a look at Zig", and Zig makes algebraic data types hard, then maybe they shouldn't use it. If you even say "the annoyingness is a feature, use zig the way it is intended to be used" then that's another signal for fun…

zig doesnt make algebraic types hard. algebraic types are exceptionally easy and also safe. and unlike rust, named in a way thats friendly to c devs.

zig makes stupid metaprogramming tricks on algebraic types annoying (not hard).

so, being precise: zig is not necessarily annoying for fp programmers (my main tool of trade in Elixir). zig is made to be annoying for architecture astronauts.

Post reply on HN