Live data from Hacker News

Functional programmers need to take a look at Zig

pure-systems.org

131–140 of 163 posts

Re: Functional programmers need to take a look at Zig

#131
post #129
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…

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.

> Sure, though most of the time it's library-only, not language change

While this distinction is often useful, here we have to think about it from the perspective of users: you press the button to upgrade your toolchain, and code that formerly worked stops working. If a language supported upgrading your compiler/interpreter separately from your standard library then that would be different, but generally a standard library version is considered tightly coupled to a language version.

Re: Functional programmers need to take a look at Zig

#132
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 :/)

> 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 :/

This makes me sad and sounds very naive. AWK is a fantastic language on its own and should be called out when used as such.

Re: Functional programmers need to take a look at Zig

#133

I don’t get it Why write: EqPoint.eql(a, c) When you can write: Point.eql(a, c)

For the same reason things like "a, c as equal points" or even "some and other as equal points". That could just as easily be automatically parsed. Just a matter of sticking conventions, as if scriptural terseness was of any utility in the kind of case, apart maybe for esoteric representation that will filter non initiated people.

Re: Functional programmers need to take a look at Zig

#134

It’s possible (even true in my opinion) that garbage collected functional languages and low level languages like Zig are both great, and serve different purposes. I actually ship stuff in Haskell believe it or not. I also think Zig is very cool and have played around with it quite a bit. Yes, garbage collection hurts performance, but the reality is that the overwhelming majority of all software does not suffer from t…

> My team writes Haskell instead of Rust because Haskell is plenty fast for our use case and we don’t have to write lifetime annotations everywhere and think about borrowing.

it happened that in rust you also don't have to write lifetime annotations everywhere. Depending on how your code is structured, compiler infers lifetime very well. In my current project we have lifetime annotations in very few places.

Re: Functional programmers need to take a look at Zig

#135
A theme I found to be common here and in a lot of conversations in this vein on the site is the split between “We (software engineers) are programming actual computers whose behaviors we know” and “We (software engineers) are expressing business problems as abstract computation that should be independent of the computer on which they run.”

The truth is somewhere in the middle but it’s interesting how many ostensibly technical disputes seem to come down to placement on this philosophical axis.

Re: Functional programmers need to take a look at Zig

#136
post #123
post #85

Earlier quoted context omitted.

> 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…

> Foo where for T: Bar

But there's literally none of that in the example we're talking about. It's just an inert datatype declaration. And if anything the Zig version is more abstract - for the Rust version I have to understand , whereas for the Zig version I have to understand comptime, Self, and @.

Re: Functional programmers need to take a look at Zig

#137

Earlier quoted context omitted.

I thought lisps were all functional programming, and lack sum types and pattern matching? In which case, what's the term for the "proper sum types and pattern matching" flavour of things?

I think the lisp situation is peculiar, for 3 main reasons: - most of them are dynamically typed (thus don't need sum types, as there are no types). The ones that do have gradual type systems likely either implement some form of them (off the top of my head I can only remember typed racket, and I think it implements them through union types) - not all lisps lean functional: I believe that's mostly a prerogative of sc…

> most of them are dynamically typed (thus don't need sum types, as there are no types)

I think you're conflating. "No compile type checking" and "no sum types" are different things. Sum types are about modeling data as "one of these variants". You can do that in any language - the difference is whether the compiler enforces exhaustive handling or not. Clojure (for example) absolutely has the equivalent of sum types, just expressed idiomatically rather than enforced by a compiler - multimethods, keywors as tags or tuple vectors can be used as represenation of tagged unions. Malli and Spec both provide sum types with validation (it just happens runtime).

Re: Functional programmers need to take a look at Zig

#138

Isn't the whole point of abstraction to not care about whats underneath unless you really have to? But ideally, you don't because the abstraction is "good enough"? I haven't heard anyone writing code in Elixir complain about performance issues.

What’s up with the last paragraph? Nobody is complaining because the BEAM is good enough for the typical use case?

I meant to point out that, for the use-cases where functional languages are used - production performance seems very acceptable, compared to having to micromanage memory allocation.

Re: Functional programmers need to take a look at Zig

#139

Earlier quoted context omitted.

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…

> using SpringBoot well there's your answer, isn't it?

This is both a fair response and isn’t! The OP was talking about typical Java stuff you’ll encounter, which is overwhelmingly spring boot. But I also agree that you can do much better than that for resource usage if you’re willing to avoid the common defaults the community has embraced.

Re: Functional programmers need to take a look at Zig

#140
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 guess that if a burrito can illustrate what is a monad, anything can be casted as a projection of a monad in some perspective. https://i.imgflip.com/65gu3j.jpg

https://rakujourney.wordpress.com/2024/10/12/raku-burritos/
Post reply on HN