Live data from Hacker News

Functional programmers need to take a look at Zig

pure-systems.org

111–120 of 163 posts

Re: Functional programmers need to take a look at Zig

#111

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…

Good for you? I’m glad you have languages that fit your needs.

In the realtime/high assurance systems world, where garbage collection can be a huge source of non-determinism and overhead; we don’t have great options.

Zig is really the only language (idk about Odin?) trying to take the same approach that C did in giving you absolute control over a minimally abstracted CPU model. Us folks who need/want maximum control/performance should be allowed to have nice things too.

Re: Functional programmers need to take a look at Zig

#112
I found this funny. I am not sure if it was intended that way!

> Monads are not some kind of obscure math-y thing that only the big brains think are necessary. No, instead monads are a fundamental abstract algebraic description of imperative programming as a computational context.

Yep, as a non-big-brainer, I definitely get it now. :)

Re: Functional programmers need to take a look at Zig

#113
post #10

A functional programmer who casts away proper sum types and pattern matching is no functional programmer at all

You can do functional programming without strict typing. Not common, because strict types work just so well with the FP paradigm but definitely possible, it’s not in itself a contradiction

Re: Functional programmers need to take a look at Zig

#114

I found this funny. I am not sure if it was intended that way! > Monads are not some kind of obscure math-y thing that only the big brains think are necessary. No, instead monads are a fundamental abstract algebraic description of imperative programming as a computational context. Yep, as a non-big-brainer, I definitely get it now. :)

You need to write a monad tutorial to really get it.

https://news.ycombinator.com/item?id=47958106

Re: Functional programmers need to take a look at Zig

#115
post #26

Earlier quoted context omitted.

I don't think so, where's the extra information in the Zig example? In Rust, which is arguably also a low level language, it looks like this: enum Option { None, Some(T), }

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 expressivity, you can barely create any meaningful abstraction there. Zig is much better at the price of remarkably small amount of extra language complexity. And c++ and rust have a huge amount of extra language complexity for the high expressivity they provide (given that they have to be expressive even on the low-level details makes e.g. rust more complex as a language than a similar, GC-d language would be, but this is a necessity).

As for this particular case, I don't really see a level difference here, both languages can express the same memory layout here.

Re: Functional programmers need to take a look at Zig

#116
From article " Where the next Programming Language will come from? that beautifully described the sad state of things. His main point is that the incentives for programming language innovation are at best misaligned and at worst non-existent"

Ok. Zig is great. But wont it still suffer from same headwinds as every other 'better' language. That industry wont adapt it? They have to much installed base and just want to hire Java/C#/etc...

Re: Functional programmers need to take a look at Zig

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

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.

Re: Functional programmers need to take a look at Zig

#119
post #10

A functional programmer who casts away proper sum types and pattern matching is no functional programmer at all

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?

Those are covered in Common Lisp, Scheme/Raket and Clojure, which are the Lisps most folks would be using, not Lisp 1.5 from McCarthy days.

Re: Functional programmers need to take a look at Zig

#120
post #83

Earlier quoted context omitted.

On the other hand, most pieces of software in this world are kind of mediocre code written by unmotivated employees within tight timelines. In such context, I think Go might be a better or at least, more realistic, compromise in most cases.

If you have unmotivated employees then using Go will only exacerbate the shortcomings it has. Cutting corners is much easier in Go than it is in Rust. But in general it's true, if you want a piece of code released a bit faster but spend more in developer hours maintaining it later than Go is the better fit. And there are definitely use cases for that.

You can write exploratory code in Rust fairly quickly, it's just obvious when you've done so due to the heavy boilerplate involved. Keep in mind that the earliest versions of Rust were actually very Golang-like, the language iteratively evolved towards what it is today.
Post reply on HN