nyberg

> I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. > Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then.

This depends on what the language is being used for. If it's to write high level glue code then passing references/pointers around is likely the norm. However the majority of cases you will care about how things are passed, how they're allocated, where they're allocated, and so on. If you don't care you're often using the wrong tool for the job or you're writing inefficient messy code.

Writing allocators (arena/bump, heap, gc, rc, memory pools, etc) requires control more often than not and applications which desire performance often need to write their own tailored to their usage patterns (e.g you don't want it to free things at the wrong time). Data layout and alignment of said data play a key role in keeping the application performant along with the ability to reinterpret memory without copying values which is something TS lacks. Access to inline assembly for the cases where the compiler generates undesirable code or where what you want to do can't be expressed in the language itself.

The above applies to quite a few domains and especially to embedded where you often have limited resources (time, memory, code size, etc). It may seem like a rare case but if you look around your at your everyday appliances around your home, sensors in your car, your headphones, and so on, you'll see that it's a rather common case.

It would be good for you to try such languages for a while so you can see why the features presented to you exist and try to develop something which touches the different areas where it's used. Embedded is a nice start with especially dealing with MMIO.

300-700 ms is a huge span of time for certain (real-time) tasks and worth considering.

It was rather a failure to deliver on the promises than perceived as a threat to Zig and the target audience for both differ enough that V doesn't have an effect on the success of Zig nor does Zig have an effect on the success of V. They are both reaching for success within their own domains with some but not much overlap.

I know you're very fond of V but misrepresenting criticism or a negative view of the project as "fear", "perceived threat", and so on is rather dishonest and a disservice to the project. The above is a comparison of before release and long after where there's been a chance to evaluate V for what it is rather than for what it advertised.

Wayland being a requirement sounds like a sound choice in terms of maintenance and the issues of X itself. Applications don't need to update to GTK5.

- Passing the allocator gives the user of the container control over where memory is allocated and the scheme used to clean it all up. You can always set a global allocator if you wish, nothing forces you to use it as a parameter.

- Regex can be provided as a library and specialized at comptime. There's never been a need for regex to be part of a primitive type and many other languages do fine without it. Concatenation is a question of "where do you allocate memory" as you have explicit allocation it's not clear what zig should do with it thus the default is to let you call std.mem.concat and dealing with the possible failure or having a look at the problem and asking if you really need concat in the first place. Often you don't as formatting string is better done with std.fmt and ArrayList(u8)'s writer().

How do you handle function-like macros and concatenation? Also, both D and Zig seem to have switched to including a full C compiler instead due to issues with translating C source wise, is that a possible direction for this in V or is the source translation good enough?

Just because 4chan has a higher ratio within specific boards doesn't mean it's any worse than other places given that facebook/twitter which often reward cult-like behaviour and boosts calls to violence.

The difference here is that with 4chan it's easier to see unpleasant behaviour given that the two containment boards are easily accessible and observable without much effort. Though take note that not all of the site is represented by those two boards and they are `containment boards`.

That's just Zig flavoured EEE.

I don't see how the Zig Software Foundation is related to SYCL not mainly marketing a concept.

Note, there's nothing wrong with marketing and providing courses (something which the FSF also provides), it's just the act of promoting it while complaining about another organization not having "done enough" that has done much more within this space over the years.

And what is SYCL if not marketing? It's a conference which sells the idea that we can make better software for the end user which is marketing just without the freedom aspect of a user being able to modify and study software.

What should the FSF have done to do a better job? It's easy to say that some entity hasn't done enough without being in the same position and without providing an alternative solution.

I think this comes off a bit arrogant and narrow minded which is a bit disappointing coming from the VP of community.

There are many other projects which the FSF provides support for to further the goal of spreading free software and picking at one for presenting work they're proud of strikes contrast with the purpose of the conference.

The issue isn't the Go module system but rather their proxy which is not part of Go and should respect server resources but doesn't. The workaround makes any 3rd party host for go modules a bad choice as packages will always be stale.

The issue has nothing to do with DD other than him raising the issue and being ignored. The fault is with google.

It doesn't adequately explain what it does before having you ruing your configuration nor should it really be part of this application. An informative message explaining that the application doesn't work on wayland, why, and a link to a page with solutions would have been much better and not placed the user at risk.

There's https://github.com/ZigEmbeddedGroup/microzig and other work within the same space.

I've used it for linux-based embedded platforms to both debug and build switches.

Zig comptime would be one of the major features which provides most of the language at compilation time for use in metaprogramming, conditional compilation (e.g `if (target == .windows) {}`), generics, and many other use cases for partial evaluation. This is used within the standard library to provide generic containers and, in the case of std.MultiArrayList, compute a more compact memory layout for the type you've given using plain zig code at compile-time.

Another would be the standard library design which in zig, focuses on giving the user control over allocations by having a pass-the-allocator interface for everything that would allocate memory rather than a single global allocator as is present in both Hare and V from what I can tell. This allows for the non-os specific parts of the standard library to be used on freestanding targets without having to reimplement std.HashMap for it to work with a new allocator.

If it's at compilation time, you have the full zig language so you certainly could implement your very own functional programming language https://github.com/igmanthony/zig_comptime_lisp in regular zig rather in an external preprocessor.

Rust doesn't provide integer overflow safety unless explicitly requested. This is something refinement types which ATS2 provides would catch.

Sounds like WASI might be the ideal to get around this in the near future given that it's also capability based similar to how browsers guard specific functions.

Would expect the challenges in lisp with such a name

  const Json = union(enum) {
      null,
      number: f64,
      bool: bool,
      string: []const u8,
      array: []const Json,
      object: HashMap([]const u8, Json),
  };

Usually it's a tagged union of the base JSON types which can easily be consumed by most statically typed languages or a variant of it.

EDIT: added "tagged"

One of the issues with operator overloading itself in relation to bignums and similar is the need for an allocator (there's nowhere to pass one) along with the lack of error handling (suppose allocation fails) and when/how to cleanup. Same with string concatenation at runtime via operators and many other places where it could be used.

So even if zig allowed for operator overloading, those issues would have to be solved.

It's an open question [1] along with other safety checks both comptime and runtime [2]. The issue here is a balance of keeping language complexity low while providing safety at the same time and not depriving users of control when they know better than the type checker/lifetime analysis.

[1]: https://github.com/ziglang/zig/issues/782

[2]: https://github.com/ziglang/zig/issues/2301

To some degree, part of the thing which places V in the spotlight for such drama is it being brought up in quite a few zig (and of course other) posts with a note on how the community is in some way treating V unfairly despite this being around 2-3 years ago along with excuses [1] for what took place. It would be better if there were more V posts instead which focus on it's merits or projects rather than holding on to and bringing up that most would have forgotten/walked away from by now.

[1] not the best word but I can't think of a better one at the moment.

It feels like most of the SPAs should really just be desktop applications and hopefully with wasm, wgpu, and wasi that can be reduced to a smaller runtime than the current v8 for everything solution. They're not really web pages anyway and trying to get them to convert to static documents doesn't seem like it will go so well considering the "interactive experiences" they provide (using the browser as a cheap GUI framework).

Would possibly be nicer to ship for the new "java platform" that wasm is slowly recreating even for software that's not currently written as web apps.

Telegram notification sounds and maybe the ringtone would be "nice".

You can use union(enum) to avoid having to write a separate enum definition for tags and std.meta.FieldEnum() exists should you also want to derive an enum from the union later on.

Zig is general purpose and isn't really focused on embedded as much as it's focused on being flexible enough to also support embedded development.

Configurable allocators are present in other languages (iirc rust allows it at the crate level, in C++ https://en.cppreference.com/w/cpp/memory/allocator) but in zig the style makes allocating functions explicit which is nice even for regular application development. It's a bit like Haskell being explicit about side-effects (IO Monad, Eff, etc). Also, passing the allocator in zig is just a convention and not enforced by the compiler so you could use `std.heap.page_allocator` or any other global allocator anywhere in your code without passing it in but then your code is less flexible.

Now for the use of the, imagine you need to serve a HTTP request; you pass an ArenaAllocator to the request handler which can allocate memory by need and without a need for calling free() for small objects. Once the handler has generated a response, the caller can free up all of the allocated memory in one step rather than having small deallocations all over for memory that will only have a life-time for the duration of the request. The handler itself doesn't need to know that it's being used this way and can be written to call free in the usual manner to be compatible with other allocators (free() with ArenaAllocator is a "nop").

Imagine you have a game, there you'll likely allocate a huge chunk at the start for all of your resources then use your own custom allocators within to both isolate systems from one another along with allowing different strategies based on your usecase. You might not always know which compiler will be best but since it's a parameter you can easily test or even decide at runtime on the strategy to use.

This is possible with statically typed languages with Haskell being one of the examples where it's encouraged to use the REPL to work towards a solution and/or qucikly test ideas without having to write unit tests or full program tests. Ocaml and friends fall within this category too and none require extensive type annotation due to type inference.

I feel that too much focus is on static languages like C/C++ where types become a chore and judging it on that rather than looking at the plenty of languages with type inference brought by ML-style languages.

With that it would waste more resources on running a partial web browser for one small GUI application where soon any system with 8GiB RAM or less is considered an obsolete and unsupported user experience when starting more than a few instances as they aren't shared nor do they have a small memory footprint.

But the new class(es) needs to be documented regardless as the relation to the code has changed from the old.

Keeping documentation in another document would see this going out of sync over time until the document doesn't at all reflect how the code looks. Not updating anything at all will leave others clueless of why the change was needed 4 months later and might see the other classes grow to the same size. Thus, eventually the code base will once again be opaque unless you ask the nearest person that worked on it last.

A nicer way of handling the flow of the document would be to use a literate programming tool that allows for keeping code snippets in an order which makes sense for the documentation rather than sprinkling as comments between the code. That way, code review happens at the same time as documentation review with code being local to the text documenting it in a format which is easy to understand for both.