821–830 of 943 posts
Earlier quoted context omitted.
Go’s static binaries are orders of magnitude smaller than .Net’s static binaries. However, you are right, all binaries have some bloat in order to make them executable.
This is flat out incorrect if you are doing AOT in C#
Earlier quoted context omitted.
Yeah. If I remember it correctly, you need to compile the GC to run on WASM if the GC extension is not supported.
The GC extension is supported within browsers and other WASM runtimes these days - it's effectively part of the standard. Compiler developers are dropping the ball.
I'm hoping that a later version makes this possible.
Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?
> a significant performance penalty with typescript There's a significant performance penalty for using javascript outside the browser. I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. It's generally also very difficult to make a JS program as fast as even a naive go program, and the performance…
You haven't looked very hard then, NodeJS has supported worker threads for years. However, to uphold Javascript's safety guarantees, they can only communicate via message passing, or sharing a special `SharedArrayBuffer` datatype, neither of which are well suited to sharing large immutable data structures.
Earlier quoted context omitted.
I'm happy to see it to be honest; at this point C# is 25 years old, and since then there's been a lot of innovation and development in programming languages and ecosystems (as well as 10x more software developers, at least - I am guessing at this number). Current-day programming languages, including Go and Typescript, will have had a lot of learnings from C#, including in things like generics and the like.
Go is a step back in key areas: generics, nullability, functional constructs, concurrency. The praise of the latter in particular is egregious. Surely we can do better than having to wire the transfer of data and forking/joining the logical flows manually in 2025? The concept of virtual threading in Go, despite having nice implementation, did not progress much from what we’ve had 10 or even 20 years ago either. It ca…
What do they mean by improving editor startup time? Does the editor (I assume vscode?) run the compiler as part of the startup? Why?
Earlier quoted context omitted.
What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. Let's be real: You can absolutely write "Go-style" code in just about any language that might have been considered for this. But you wouldn't want to, as a more advanced type system enables entirely diffe…
> What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language. I would say structural typing is very "esoteric" for most strongly typed languages actually, but this is not a problem. And proceeding, the implications of your response is very strange. See, your point…
He did, but much more importantly Cavanaugh said that he chose Go because of it having similar semantics and code structure. In other words, idiomatic Go is similar to how the original code was written. While I am sure Hejlsberg's input was icing on the cake, it was the not the ultimate determinator. C# having the best compiler in the world on every front still wouldn't have ticked the boxes the guy in charge needed to tick.
> So I don't think he would agree with you that this was his reasoning for using go
He may not, but it also wasn't his choice in the end anyway, so its a bit strange that you are leaning on his word.
Earlier quoted context omitted.
| with no frills. People say this like it's a bad thing. It's not, it's Go's primary strength.
I can see the appeal. Not having to write C# style oop probably gave the team a huge productivity boost. I bet it compiles hundreds of times faster making the team, cicd, and dev efforts substantially more productive. Cohesive integrated modern tooling is also a huge plus. Project structure is considerably simpler... I am not really a go fan but I would chose it over c# in a majority of cases as well. I think they mi…
Rust is really hard , compared to golang. This can increase outside contributors as well.
Golang is love , Golang is life.
Earlier quoted context omitted.
That is not a violation of memory safety, that's a violation of concurrency safety, which Go doesn't promise (and of course, Rust does.)
Segfaults are very much a memory safety issue. You are correct that concurrency is the cause here, but that doesn't mean it's not a memory safety issue. That said, most people still call Go memory safe even in spite of this being possible, because, well, https://go.dev/ref/mem > While programmers should write Go programs without data races, there are limitations to what a Go implementation can do in response to a dat…
How can a segfault lead to attack or exploitation?
Edit: Answering my own question (from https://go.dev/ref/mem):
Reads of memory locations larger than a single machine word are encouraged but not required to meet the same semantics as word-sized memory locations, observing a single allowed write w. For performance reasons, implementations may instead treat larger operations as a set of individual machine-word-sized operations in an unspecified order. This means that races on multiword data structures can lead to inconsistent values not corresponding to a single write. When the values depend on the consistency of internal (pointer, length) or (pointer, type) pairs, as can be the case for interface values, maps, slices, and strings in most Go implementations, such races can in turn lead to arbitrary memory corruption.
Earlier quoted context omitted.
The automatic gc doesn't seem like an actual deal breaker though. They probably just didn't want to redesign a bunch of data types that assumed one existed. I'm not arguing saying they made a bad call. I think what they did was smart with the options in front of them and whatever budget they have. The world isn't good for idealism, but it ideally could have been written in rust in my opinion.
> it ideally could have been written in rust in my opinion What exactly would that buy and would the outcome matter much? In my opinion: pragmatism > idealism.
Golang is generally very fast and simple as well , the only problem is of memory allocation / garbage collector overhead but the benefits outweigh the loss.
Earlier quoted context omitted.
It’s a little more nuanced though — I doubt the audio processing in Discord is written in JavaScript. (But I haven’t looked!)
Isn't most of Discord backend Rust and Go?