Hacker News new | past | comments | ask | show | jobs | submit | 4ad's comments login

No, Go can never use WasmGC because Go has interior pointers. Not even fat pointers help because Go has unboxed types.

Go will continue to use its own GC for the foreseeable future.


Interesting. Can it collect garbage _concurrently_ in WASM?

Last I checked WASM applications are single threaded, not sure if that's changed. GC is concurrent, but not parallelized.

Poorly. The tooling is very bad. But to be fair, this is not specific to Go.

> why is Go compelling as a source language for WASM?

"Compelling" has nothing to do with it. People write Go code (or have already written it) and want to run in Wasm, just like they want to run it in any other environment. It's as simple as that.

Your question is equivalent to "why do people want to write Go?".


Just the same as it works on amd64 or arm64 or any other architecture.

You mean inside another thread, collecting garbage concurrently? I'd be very surprised if it worked that way.

WASIp2 implies component model. WASIp2 is implemented using component model.

I see, thank you. I'm trying to get up to speed with the whole ecosystem as I have a use case for it. I would like to interact with WASM components from a go binary, but it seems like wazero doesn't and won't support the component model anytime soon. The rust tooling seems more mature ATM :(

At some point Wazero will have to support component model, regardless of their opinion about it. Otherwise they will lose any relevance.

But I agree with you, the tooling is very immature.


It's not just a matter of opinion, but resource allocation.

WASI preview 1 was already a significant effort. It is the least polished bit of the wazero implementation, but even compared to: a spec compliant interpreter, two compilers and runtime, it weighs. It has some issues around filesystem sandboxing. And portability to “everywhere Go runs” is a pain.

Preview 2 is a significant departure, with little promise that preview 3 isn't another, ad nauseam. For a small team, that's hard to track.

Wasm 1.0 is a useful spec; Wasm 2.0 is still a draft. wazero supports everything final from 2.0 so far.

WASIp1 was useful too, but wazero is useful without WASI.

Until the dust settles, I'd rather wazero was reworked to make WASI even more pluggable from the outside (there are two impls already), than invest more resources in the WASI implementation itself.

Still, if anyone wants to fund fulltime work on this, I guess that can be arranged.


no it will not. Wazero will likely never do that.

Great, there are other Wasm runtimes to choose from.

The component model is... part of WASI, so that criticism doesn't make any sense.

When Go adds support for WASI Preview 2 (or 3), it will have no choice but to support component model. The way WASI Preview 2 works is by making use of the component model.


if Go supports it. I do not believe it is likely. There will still be no native Go runtime to execute components. No one is using WASI p2.

do you need a disclaimer to your comments that you work on a product (XTP Bindgen) that is basically competing with the WASI component model? I don't care for either but thought the transparency was necessary.

Predicting things is hard, especially about the future, that being said, the people doing the Wasm work for Go want to move to the component model.

ok. it’s on the brink of collapse. Bytecode Alliance is basically comprised of near-dead startups and one or two large corporates who do not care about it.

Considering the near complete overlap of people comprising the Bytecode Alliance with the people who created WebAssembly and people who maintain WebAssembly (especially the formal specification), I very much doubt that the Bytecode Alliance is in any sort of immediate danger. That said, you are right that corporations don't care about it, with some corporations even working against it.

the active overlap is basically 1 person.

The interface layout has changed since the article (although this specific article doesn't mention interfaces, a later article in the series does). Additionally Go now has generics.

It's true that little has changed, but very little is changing in the data representation of any language, really. Even ones that are evolving rapidly.


This is a truth that's easily overlooked; most languages are several levels beyond basic types to the point that people forget about the low level constructs involved. This is one reason why I like Go, it exposes and educates on fairly low-level mechanisms that are not unfamiliar to anyone who's studied computer science, but at the same time you don't have to worry too much about the lower level stuff like memory, pointers, zeroing, etc. I think it's a good tradeoff.

An expressive type system absolutely, positively, unequivocally does not imply slower build times (especially with a Church-style type system). There are plenty of programming languages with advanced type systems which compile extremely quickly, even faster than Go, for example OCaml.

Don't make the fallacy of conflating Rust's slow compile time with its "advanced" (not really, it's 80's tech) type system. Rust compilation is slow for unrelated reasons.


Old doesn't mean non-advanced. GraalVM is based on a paper (Futamura) from fifty years ago. Off the top of my head I can't think of many language features younger than the eighties—maybe green threading? That would be surprising but might fit. I suppose you could also say gradual typing. Haskell has many recent innovations, of course, but very few of those have seen much use elsewhere. Scala has its implicits, I guess, that's another one.

Personally, I write java at my day job and the type system there makes me loooong for rust.


No need for Rust, when JVM has Haskell, Scala, Kotlin, Clojure, Common Lisp.

I prefer rust to all of them, but I also come from a very systemsy background. Plus it has the benefit of being much easier to embed inside or compose around basically any runtime you'd like than managed code, which is why I chose rust rather than basically any managed language.

But, it's just a tool, and the tools I choose reflect the type of stuff I want to build. The JVM is extremely impressive in its own right. You're just not going to to find any one runtime or ecosystem that hits every niche. I'm happy to leave the language favoritism to the junior devs—for the vast majority of situations, what you're building dictates which language makes the most sense, not vice versa.


It's exactly backwards, YouTube favours short videos and frequent uploads. People doing long videos do it purely out of passion.

The claim that most videos nowadays are hitting the one hour mark is trivially false.


I simply can't believe there isn't some incentive for longer videos. It may be that YouTube only cares about total watch time and doesn't care if a creator pushes lots of short ones or a few long ones, as long as viewers keep viewing. I see so many videos like this:

Tie Shoes Like a Pro "If you're watching this video you probably want to know the secrets to good shoe tying. We'll show you how in this video. It's surprisingly easy, so don't go anywhere. But first, have you ever wondered why we tie our shoes? The first shoes weren't actually tied but were just soles that people nailed to their feet. <Cue hammer sound effect and scream> Haha, actually this didn't hurt at all because... <10 minutes pass> ...and then in 1890 Eritrea was founded, but you don't care about that! Haha! You're here to learn how to tie shoes! Don't worry, we'll get to that too! Anyway, also in 1890 all the leather factories in France burned down and so they couldn't spare leather for shoe buckles, so they began using bits of string..."


The "youtube meta" has changed overtime and not all creators have stayed current with it, so you can find old videos which were once optimized for youtube but no longer are, or new videos being created in an outdated style. With some channels though, I think they've decided to make suboptimal videos from the youtube algorithm perspective because they're getting most of their revenue from a loyal fanbase donating to them on patron/etc, so they cater to the preferences of that specific crowd.


There could be multiple valid strategies too. I’ve seen some creators will put out a video once every few months, but that video will be shown on everyone’s feed and will get millions of views. While mass content posters like gaming channels probably get less exposure or their videos spend less time on the top.


True. And different kinds of content may have different metas. Some content needs to be timely and can only get views for a short period of time before effectively expiring. Other content is evergreen and can play the long game, counting on getting reliable view numbers for years.


Not really true anymore. Creators have talked about how youtube's incentive structure is pushing towards longer videos now. Not necessarily higher-quality ones, and posting more volume is still generally going to help, but because youtube's now optimising for watch time instead of views, long videos are pretty heavily rewarded. (In fact, as always, the high-effort but short content like animations are the least 'efficient' genre on youtube).


Apart from the HW requirements the others mentioned, Apple Intelligence is only available in the US (or at least it's not available in the EU). So make sure you're in the US.


It's not only available in US. It might be only available in US English language, but regionally I'm in Asia and have been using it since day one.


Macs in the eu can have it, iphones and ipads not (yet).


Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: