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

Zig, the Small Language

zserge.com

Post reply on HN
Print view View original

421–429 of 429 posts

Re: Zig, the Small Language

#421

Post by bb88 »

bb88 wrote: post #416
cassepipe wrote: post #402

Earlier quoted context omitted.

As I understand you advocate a bottom - up approach rather than a top-down one. I personally prefer the former over the latter as it makes more sense to me to learn how to make basic programs work before I learn what incredible things I can do with them. I have over one year of C experience in my school doing things like rewriting functions of the C stdlib and reimplementin getline() before I learn about radix sort,…

I have no argument there. But let's look at some actual data. https://www.registrar.iastate.edu/resources/enrollment-stati... In around 1995ish ISU moved to Scheme for their first level course, because they wanted to follow the MIT example. At about 2000/2001 they had a healthy number of students in both the computer-science and pre-computer science programs. The problem you can see in the data is converting the pre-…

I left out the fact that around 2007/2008ish (right around when SICP was phased out of MIT) Computer science enrollments dropped to ~100ish.

Re: Zig, the Small Language

#422

Post by hitekker »

dtolnay wrote: post #314
hsn915 wrote: post #305

Earlier quoted context omitted.

Here's a hypothesis I'd like to see Rust advocate attack: In any serious system written in Rust, significant portions of it will have to be written in "Unsafe Rust".

https://github.com/diem/diem is 387,952 lines of Rust code across 169 crates. In total there are 3 lines of unsafe code, which is less then 0.001% (1 thousandth of 1%).

> The launch was originally planned to be in 2020 but only rudimentary experimental code has been released until the project was abandoned in January 2022.

https://en.wikipedia.org/wiki/Diem_(digital_currency)

Re: Zig, the Small Language

#423

Post by masklinn »

naasking wrote: post #405
masklinn wrote: post #339

Earlier quoted context omitted.

> I’d assume they care because Go was designed to keep the codebase as “neat” and clean as possible when being worked on by many developers So someone’s anal retentive was made into a langage mandate rather than anything actually useful? > Given enough time and developers, things like unused variables will start to seep in and make the codebase dirtier. Why are dead variables any dirtier than dead stores? Or unchecke…

> Why are dead variables any dirtier than dead stores? If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this. If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. In principle, a dead variable in final code is also almost certainly a mistake: either by not including…

> If you mean stores to fresh local variables

I mean stores for which there is no load.

> I assume that should also count in a proper/ideal implementation of this.

It certainly does in a proper implementation, but not in zig. Or go.

> If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it.

That sounds stupid.

> a dead variable in final code is also almost certainly a mistake

See “final code” is the issue at hand. The problem with go is that it specifically does not do that. It has a half-assed implementation which it forces upon you all the time.

> Maybe a little annoying while you're figuring something out

It’s a bloody nuisance when you new figuring things out or in the middle or refactoring something.

> but makes sense in the context of polished code.

There’s a ton more which makes sense “in the context of polished code” which go can’t be arsed to do.

Checking that errors are not implicitly ignored for starters.

Re: Zig, the Small Language

#424

Post by littlestymaar »

dolmen wrote: post #401
littlestymaar wrote: post #125

Earlier quoted context omitted.

Integer division isn't a simple one either though… Matrix multiplication are “basic operations” in the sense that you use them as the basic block of your algorithms, and in code using such blocks you really appreciate having a simple operator for those instead of littering your formula with functions calls (which is basically writing your formulas in Polish notation, not the most legible way to write formulas …)

Matrix multiplication is a niche in the programming world.

The programming world is made of niches. That's why arithmetic operator overloading is nice, the language doesn't need to know which niche I'm in to satisfy my needs.

Re: Zig, the Small Language

#425

Post by dolmen »

adamdusty wrote: post #335
boywitharupee wrote: post #108

Earlier quoted context omitted.

For unused vars you can do this and the compiler will ignore it. _ = my_unsed_var;

Doesn't that entirely defeat the purpose of having the compiler not allow unused variables.

Add a pre-commit hook to forbid use of '_ ='.

   grep '$ *_ ?=' *

Re: Zig, the Small Language

#426

Post by dolmen »

RcouF1uZ4gsC wrote: post #51

IME, general purpose "small" languages rarely stay small. Even C has accreted a lot of features. I think Python was small at some point. Pascal was small at some point, but by Delphi had become quite big. Go has just added generics. I think looking at a "smallness" for a relatively young language is likely to be misleading.

The Go team did an amazing work to add generics with a very small impact on the language. They even managed to add generics without breaking the Go 1.0 compatibility guarantee.

Check the short list of changes to the language specification in the Go 1.18 release notes: https://go.dev/doc/go1.18#generics

Go is still a small language, even with generics.

Re: Zig, the Small Language

#427

Post by naasking »

masklinn wrote: post #423
naasking wrote: post #405

Earlier quoted context omitted.

> Why are dead variables any dirtier than dead stores? If you mean stores to fresh local variables, I assume that should also count in a proper/ideal implementation of this. If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. In principle, a dead variable in final code is also almost certainly a mistake: either by not including…

> If you mean stores to fresh local variables I mean stores for which there is no load. > I assume that should also count in a proper/ideal implementation of this. It certainly does in a proper implementation, but not in zig. Or go. > If the idea is for code to be literally WYSISWYG, then your compiler will no longer eliminate variables or code for you, so you have to do it. That sounds stupid. > a dead variable in f…

> I mean stores for which there is no load.

Stores for which there are no load can still be observable in concurrent scenarios. That's why I specified stores to locals with no load because those are not observable.

> That sounds stupid.

Sounds totally reasonable to me in scenarios where you need the output of the compiler to be very predictable.

Re: Zig, the Small Language

#428

Post by Tozen »

brundolf wrote: post #297

It just occurred to me, Zig could be a great learning-language for CS When I was in college we mostly used C++, which exposed (and thereby taught) a lot of core concepts around how computers and low-level languages work. But it was also a bit of a nightmare for... unrelated, obvious reasons. Rust is great for building software, but as a learning language I think it introduces too many additional concepts, has too man…

I think many teachers would disagree about the usage of Zig for CS, and over the widely accepted and used C language or even over popular newer ones such as Go, D, or Rust. Not to mention the strong push that Embarcadero still makes to push Object Pascal (Delphi) into classrooms, and how well known Pascal/Object Pascal still is in countries outside of the U.S.

1) Zig lacks features where they could teach about OOP.

There is no classes or inheritance. To include Zig doesn't lend itself so well to even the more general object-orientated concepts, which are in newer languages like Go or Vlang and others (structs that can be assigned methods and having interfaces). Like it or not (rightly or wrongly), class-based OOP still has many "hypnotized" and conditioned to its necessity.

2) There is the issue of having to address manual memory management.

While that would be the same problem for C, many teachers choose to go the easier route, and select languages like Python or Java. Others like Go, Vlang, D, etc... would make things easier as well.

And Pascal/Object Pascal (Delphi) is still around (a language made for being taught in CS), with a ton of books covering pointers, the heap, bytes, memory management, etc...

3) Zig is still a widely unknown and developing language.

Zig is years away from reaching 1.0. Many teachers are conservative. They often will go with what is already widely known and will likely create the least amount of controversy.

If more teachers can be convinced out of being so conservative, it would probably be because a language is being so strongly pushed by famous companies that are targeting schools or by demand in the job market. Google pushing Go, Oracle pushing Java, Microsoft pushing C#, etc...

Re: Zig, the Small Language

#429

Post by timbit42 »

joshmarinacci wrote: post #171

It feels like there's room for a better C today. I don't mean a really different language. I'm thinking something that is semantically C, and 99% syntactically C, but that a much better story around macros, builds, modules, linking, volatile pointers, and all of the other C foot guns. Not C++ or Rust (though I love Rust). I'm thinking just a smoothed out C. And done in a way where a codebase can incrementally move fr…

Would the "Better C" in dlang work for what you want?
Post reply on HN