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

Go runtime: 4 years later

go.dev

Post reply on HN
Print view View original

281–290 of 296 posts

Re: Go runtime: 4 years later

#281

Post by Tozen »

vlang1dot0 wrote: post #256
Tozen wrote: post #238

Earlier quoted context omitted.

That's complete and uncalled for troll nonsense. V has hundred of releases ( https://github.com/vlang/v/releases ), with hundreds of contributors to its open-source project (577 and growing). It exists and works. It's one thing to like some other language, its another thing to spew disinformation, lies, and flames about others.

It has an automated release generated every week. The could be no commit activity whatsoever and there would still be 52 "releases" of V every year. It's one thing to like V but it's another to constantly repeat misleading information in an attempt to give it more credence than it has. Even V's own changelog only contains 28 releases (mostly from the 0.1 era in 2019 - early 2020) not "hundreds" like you've claimed. h…

For starters, you are a known troll account. Your very account name, vlang1dot0, was made to harass and troll. That is all that you do on HN.

I was referring to the GitHub releases, which very clearly state they are releases. Each of these Vlang GitHub weekly releases has a compare tag to show what has changed from previous releases.

This is a comparison of changes made between the latest release and the one of 4 weeks ago: https://github.com/vlang/v/compare/weekly.2022.35...weekly.2.... That's 150 commits and 722 files changed. The releases are clearly different, with numerous changes. That's 1 month of changes, if we looked at 3 months, 6 months... We would see even more massive amounts of progression.

Now, back to the FUD you are pushing with your known troll account. The game you are trying to play is to obfuscate the clear as day lie that V is vaporware. Nobody is falling for it. And the more you keep engaging in trolling the V language, the more obvious it becomes to everyone else what you are doing and what your agenda is all about.

Re: Go runtime: 4 years later

#282

Post by Tozen »

cercatrova wrote: post #278
Tozen wrote: post #276

Earlier quoted context omitted.

Quoted post unavailable.

Look at your comments and post history in the past couple of weeks. You submitted 3 separate posts about V, and your recent comments are just calling people who call out V "trolls" and "spammers." Observe your own bias before you cast others down.

I hope you don't have some mental issue that doesn't allow you to discern differences. To support or like a programming language is not spamming or trolling.

I'm not running around HN posting that "Rust is lies", "Zig is fake", "C++ is dead", etc... To include, not here insulting or trolling the creators of other languages. Lastly, nor am I spamming people to visit my website or troll blogs, that contain resume and Patreon accounts.

If I don't like a programming language, I simply don't use it. Don't need to post hate spam everywhere or tell lies about it. If I like a programming language, I might post about it. And I'm not such a blind evangelist or fanatic, that I only have "one true language" and then crap and troll on all others.

Re: Go runtime: 4 years later

#283

Post by gompertz »

vlang1dot0 wrote: post #256
Tozen wrote: post #238

Earlier quoted context omitted.

That's complete and uncalled for troll nonsense. V has hundred of releases ( https://github.com/vlang/v/releases ), with hundreds of contributors to its open-source project (577 and growing). It exists and works. It's one thing to like some other language, its another thing to spew disinformation, lies, and flames about others.

It has an automated release generated every week. The could be no commit activity whatsoever and there would still be 52 "releases" of V every year. It's one thing to like V but it's another to constantly repeat misleading information in an attempt to give it more credence than it has. Even V's own changelog only contains 28 releases (mostly from the 0.1 era in 2019 - early 2020) not "hundreds" like you've claimed. h…

Didn't dang already issue you a warning for this perpetual nonsense?

https://news.ycombinator.com/item?id=31930011#31941278

Re: Go runtime: 4 years later

#284

Post by int_19h »

cygx wrote: post #244
int_19h wrote: post #230

Earlier quoted context omitted.

That's true, but I would argue that any runtime with custom green threads is.

Would you consider the C runtime a virtual machine once you link against libdill or use OpenMP? If not, why not? If so, well, then we just disagree on the term 'virtual machine'. My litmus test would be the presence of some sort of well-defined instruction set.

A quick look at libdill indicates that concurrency there is cooperative, so it's not green threads, either. So, that's just a library.

OpenMP uses OS threads, doesn't it?

When you have coroutines that can be preempted, without explicit yielding in the source code, that's the line at which I would consider it a VM. Basically, it's a VM if some userspace code (JIT, GC, scheduler etc) runs in the background and does things to your code.

I don't think there's a definitive interpretation of VM, so this is all arguable. But e.g. Java and C# are generally considered VM languages even if AOT-compiled, despite the fact that there's no bytecode involved past that point.

Re: Go runtime: 4 years later

#285

Post by int_19h »

yencabulator wrote: post #251
int_19h wrote: post #139

Earlier quoted context omitted.

The C ABI on pretty much any platform defines object layout for structs, which is usually good enough.

The C ABI is nowhere near enough for passing arbitrary Go structs, all you need is a map or a sync.Mutex field and you need to exactly match plugin compilation to caller compilation. I wish https://pkg.go.dev/plugin was clearly documented as not being a viable 3rd party plugin solution.

It's not enough to pass arbitrary C++ classes, either. The point is that you can still design a fairly expressive API involving structured data within the constraints that the C ABI imposes on you - and that C ABI will guarantee stability. This is how plugins were usually handled in the C++ world, historically speaking.

(There are also higher-level ABIs like COM, but they are usually reducible to the C ABI in practice - e.g. COM can be described entirely in terms of struct and function pointers.)

Re: Go runtime: 4 years later

#286

Post by randomdata »

EdwardDiego wrote: post #158
randomdata wrote: post #153

Earlier quoted context omitted.

> needs better error handling First it would need to add error handling before it could look to improve upon it. I'm not entirely convinced it should. I spend my days in a variety of other languages that have added error handling in various ways and, in my experience, it always ends up making errors unnecessarily difficult to do deal with. I regularly wish the idioms of those languages recognized errors as being core…

I like the reasoning behind Go's approach, but the `if err != nil` ends up polluting codebases like Java's checked exceptions did. I'm not sure what the better way to do it is tbh.

> but the `if err != nil` ends up polluting codebases

Pollute implies that it is unwanted, but this is something you do want. It is the most interesting and important part of your application logic. You want it up front and centre for all to see.

I think we all understand the human desire to want to believe that bad things won't happen, but when one becomes an engineer they have to set those emotions aside and realize that bad things will happen and that your job is to make sure that when bad things do happen that the failsafes achieve an acceptable outcome.

> I'm not sure what the better way to do it is tbh.

I'm not sure any better is fundamentally possible within an engineering context. The vast majority of the job is in understanding the failure modes and being able to communicate to the computer how to gracefully deal with the problems when they occur. As such, it stands to reason that the vast majority of the code is going to be related to errors.

If you are programming for hobby/learning purposes, where when bad things happen your program can simply crash with no consequence, there are different approaches that work well, but Go is decidedly not designed for this space. And, frankly, doesn't need to be as there are already plenty of languages designed for that. Go is, quite explicitly, meant to be an engineering language.

Re: Go runtime: 4 years later

#287

Post by cygx »

int_19h wrote: post #284
cygx wrote: post #244

Earlier quoted context omitted.

Would you consider the C runtime a virtual machine once you link against libdill or use OpenMP? If not, why not? If so, well, then we just disagree on the term 'virtual machine'. My litmus test would be the presence of some sort of well-defined instruction set.

A quick look at libdill indicates that concurrency there is cooperative, so it's not green threads, either. So, that's just a library. OpenMP uses OS threads, doesn't it? When you have coroutines that can be preempted , without explicit yielding in the source code, that's the line at which I would consider it a VM. Basically, it's a VM if some userspace code (JIT, GC, scheduler etc) runs in the background and does th…

Historically, goroutines worked like in libdill, only passing control to the scheduler on certain calls. So did the Go runtime suddenly become a VM at version 1.14, when preemption was added?

And why the distinction between OS threads and green threads? Sure, in case of OS threads, it's not the language runtime that does the scheduling, but that just means that the operating system is now our virtual machine.

I would argue that what makes a language runtime a virtual machine is not the presence of a garbage collector, a jit compiler, or a scheduler (with or without preemption), but that it has well-defined semantics in terms of something that looks a bit like a real machine - hence the name! In particular, there's a set of instructions it understands. In case of the JVM, the instruction set is defined in the Java Virtual Machine Specification (with Java bytecode its representation), in case of the CLR, it's defined in the Common Language Infrastructure specification (with CIL bytecode its representation), in case of Smalltalk, it's defined in the Blue Book, in case of WASM, in the WebAssembly core specification.

Re: Go runtime: 4 years later

#288

Post by bayindirh »

avgcorrection wrote: post #277
bayindirh wrote: post #154

Earlier quoted context omitted.

We always make this discussion with friends. I don't think every language should tick the boxes the same way. I also personally like Go a lot. It's filling the gap between C++ and Python for me. If I need something compiled with proper threading support, but C++ would be an overkill, I reach for Go. Go is designed with a human centric view, IMHO: "Make writing great programs easier rather than design a language with…

> Go is designed with a human centric view, IMHO: "Make writing great programs easier rather than design a language with novel/cutting edge features, but with a high cognitive load", and I find it as a noble aim as Rust's guarantees and aspirations. I don’t understand his horrid informal writing style trend. You are clearly not quoting anyone and just providing your own interpretation. So why in the hell are you usin…

Equally, I don’t understand the horrid assumption about everyone being born in an English speaking country and has English as the native language.

So, why in the hell are you just berating me via a comment box?

I made a mistake, alright, and used quotation marks as a tone modifier, because I know no other way to do that.

However in this case you could just pointed me the right direction without berating, since pointing out the mistake already acts as a kind direction arrow.

Re: Go runtime: 4 years later

#289

Post by cies »

seer-zig wrote: post #275
cies wrote: post #272

Earlier quoted context omitted.

But implicit nulls are a big pain point (in both Java and Go). And its very hard to fix for Java (and no plant thus far).

There are solutions like CheckerFramework or Nullaway or other compile time annotation processors.

...and Kotlin :)

Re: Go runtime: 4 years later

#290

Post by yencabulator »

int_19h wrote: post #285
yencabulator wrote: post #251

Earlier quoted context omitted.

The C ABI is nowhere near enough for passing arbitrary Go structs, all you need is a map or a sync.Mutex field and you need to exactly match plugin compilation to caller compilation. I wish https://pkg.go.dev/plugin was clearly documented as not being a viable 3rd party plugin solution.

It's not enough to pass arbitrary C++ classes, either. The point is that you can still design a fairly expressive API involving structured data within the constraints that the C ABI imposes on you - and that C ABI will guarantee stability. This is how plugins were usually handled in the C++ world, historically speaking. (There are also higher-level ABIs like COM, but they are usually reducible to the C ABI in practic…

You can write C plugins, or C-ABI plugins in any language that can do that, and call them from Go just fine. Nobody just considers that a very good way to write Go, or plugins for Go.
Post reply on HN