Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Functional programmers need to take a look at Zig

pure-systems.org

Post reply on HN
Print view View original

61–70 of 163 posts

Re: Functional programmers need to take a look at Zig

#61

Post by tome »

I don't understand why Zig's `Io` is a "monad". In fact I discussed that with the author of this article and the author of Zig here, but no conclusion was reached (https://news.ycombinator.com/item?id=46129568).

But, flipping the script, if you want to see something like Zig's `Io` interface in Haskell then have a look at my capability system Bluefin, particularly Bluefin.IO. The equivalent of Zig's `Io` is called `IOE` and you can't do IO without it!

https://hackage-content.haskell.org/package/bluefin-0.5.1.0/...

Regarding custom allocators and such, well, that could fit into the same pattern, in principle, since capabilities/regions/lifetimes are pretty much the same pattern. I don't know how one would plug that into Haskell's RTS.

Re: Functional programmers need to take a look at Zig

#62

Post by whstl »

faangguyindia wrote: post #32

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…

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 and reasons, but having to constantly deal with “wrong tool for the job” for the thousandth time gets frustrating.

Especially in cases where four different languages were used across the company because different people had different preferences. Worst case was Python/Ruby/C#/Javascript.

I get that Bash is not perfect, but I enjoy the simplicity and directness, and dislike the multitude of problems caused by not using it have shown to me it’s a better tradeoff.

Re: Functional programmers need to take a look at Zig

#63

Post by mrkeen »

rienbdj wrote: post #52
mrkeen wrote: post #51

Maybe procedural programmers should take a look instead. I don't see functions. a function from a set X to a set Y assigns to each element of X exactly one element of Y. [ https://en.wikipedia.org/wiki/Function_(mathematics) ]

Under this strict definition you can’t even throw exceptions!

Then allow partial functions too. Maybe even require them to be tagged as such. (Is that within the capabilities of Zig's programmable type system?)

I don't mind escape hatches - as long as they're visible/greppable in the source code. You can always write undefined/error/panic/trace directives while you're coding, then come back and remove them later.

Re: Functional programmers need to take a look at Zig

#64

Post by Karrot_Kream »

faangguyindia wrote: post #32

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…

Yeah after writing some Haskell semi production apps (ported an old service at a previous company to Haskell and tried to productionize it enough for our staging environments) that's the conclusion I came to for using Haskell.

Curious if you've tried to use agents to read / write Haskell and how the experience has been?

Re: Functional programmers need to take a look at Zig

#66

Post by rienbdj »

mattalex wrote: post #54
rienbdj wrote: post #52

Earlier quoted context omitted.

Under this strict definition you can’t even throw exceptions!

Of course you can: you just have to define it in your type. The output set becomes a union type of the normal output and whatever you want as an exception. If you write this as a monad, your get very similar syntax to procedural code.

I get what you are saying, but…

An exception is different to an Either result type. Exceptions short circuit execution and walk up the call tree to the nearest handler. They also have very different optimization in practice (eg in C++)

Re: Functional programmers need to take a look at Zig

#67

Post by rienbdj »

mrkeen wrote: post #63
rienbdj wrote: post #52

Earlier quoted context omitted.

Under this strict definition you can’t even throw exceptions!

Then allow partial functions too. Maybe even require them to be tagged as such. (Is that within the capabilities of Zig's programmable type system?) I don't mind escape hatches - as long as they're visible/greppable in the source code. You can always write undefined/error/panic/trace directives while you're coding, then come back and remove them later.

I would love a language that distinguishes functions (pure mathematical constructs) from procedures (imperative constructs that map in a predictable way to the instruction set).

This feels like the direction Algebraic Effects might take us.

Re: Functional programmers need to take a look at Zig

#68

Post by imtringued »

faangguyindia wrote: post #45
5d41402abc4b wrote: post #39

Earlier quoted context omitted.

Why did you give up on Java and Rust?

Java is a resource hog when you use patterns and libraries popular in Java land. When you are working in the Java ecosystem, you just assume that this much resource is needed by the app! But when you'll code the same thing in Go using the same methods, you'll find resource usage is really very low. We’ve a 1: 1 copy of the app; on JVM, it's using 2GB RAM using Spring Boot, and on Go, it runs on 512MB RAM and is blazi…

I'm not sure the effort part makes sense now that we have LLMs? LLMs basically liberate language choice, which has made Rust incredibly attractive to me since I basically get good performance out of the box, while any possibly annoying pedantic obsession with correctness can be easily handed over to the LLM.

If I use a JVM language, running my test suite takes 10 to 30 seconds. With Rust it spends 3 seconds compiling and half a second to run 250 tests.

The irritating parts of Rust are more related with bloated libraries like serde that insist on generating code which massively slows down compilation for not much benefit.

Re: Functional programmers need to take a look at Zig

#69

Post by george_____t »

tome wrote: post #61

I don't understand why Zig's `Io` is a "monad". In fact I discussed that with the author of this article and the author of Zig here, but no conclusion was reached ( https://news.ycombinator.com/item?id=46129568 ). But, flipping the script, if you want to see something like Zig's `Io` interface in Haskell then have a look at my capability system Bluefin, particularly Bluefin.IO. The equivalent of Zig's `Io` is called…

> I don't understand why Zig's `Io` is a "monad".

I don't see how it's true in any meaningful sense. It seems about the same as stating that any function is an example of the reader monad.

The whole point of monads in programming languages is as an _abstraction_ that allows one to ignore internals like how the IO token is passed around.

Maybe Zig is a language for people who are scared of abstraction. Otherwise they'd presumably be using something more powerful like Rust.

Re: Functional programmers need to take a look at Zig

#70

Post by rienbdj »

y0ned4 wrote: post #60
rowanG077 wrote: post #53

Earlier quoted context omitted.

I cant really agree on Rust. It does take a bit more time to write the same code in rust vs go. But in my experience the code is much more likely to be incorrect in go than it is in rust. Which over longer periods means rust is easier to maintain.

This article convinced me to switch from Go to Rust: https://discord.com/blog/why-discord-is-switching-from-go-to...

The issues with Go in that article only surfaced at Discord scale.
Post reply on HN