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

201–210 of 296 posts

Re: Go runtime: 4 years later

#201

Post by hknmtt »

baby wrote: post #142
hknmtt wrote: post #126

Quoted post unavailable.

What do you have against BLM?

My personal opinions aside, what does a programming language has to do with a political movement in one of the 195 countries in this world? Nothing, that's what. The political activists hijacked the Go community they had access to and power over for their own personal beliefs and agenda disregarding every bit of ethics or responsibility they were entrusted with. As the saying goes, with great power comes great responsibility. And they took advantage of that power for their own benefit. That's what i have a problem with. I could care less about BLM, I am not black nor live in or hold a US citizenship. But I have a problem with someone forcefully shoving their own personal beliefs down my throat.

Re: Go runtime: 4 years later

#202

Post by cygx »

kaba0 wrote: post #185
cygx wrote: post #170

Earlier quoted context omitted.

Not every runtime environment is a virtual machine...

Then you can sure list some differences between go's and JVM's runtime.

Most relevant in context of our discussion: The JVM is a (virtual) stack machine with its own instruction set and semantics specified in the Java Virtual Machine Specification. As far as I'm aware, something equivalent does not exist for Go, or as an internal implementation detail at best (some intermediate representation might potentially qualify if you squint at it the right way).

Re: Go runtime: 4 years later

#203

Post by kweingar »

simiones wrote: post #194
kweingar wrote: post #188

Earlier quoted context omitted.

One of the underrated difficulties of learning Java is the fact that it demands separate files for each exported class. Writing and reading simple Go libraries is a breeze. I’ve written tiny libraries that fit in one file. You can read it linearly, starting at the top and following the logical progression of type declarations, functions, globals, etc. Whereas with an identical Java library, a reader would be presente…

If you really need this, you can always expose all your actual classes as public static class members of a single wrapper class: public class Wrapper { public static class C1 { } public static class C2 { } } //other module: var x = new Wrapper.C1();

You could do that, but it doesn’t work with interfaces.

The Go style just lets your code live together for easy reading, no problem. You can comfortably fit all of this into one file: a one-function interface, a couple of small functions that take the interface as a parameter, and two implementations of the interface.

Compare this to 3 or 4 tiny Java files. You’d have to guess which one to click on first.

Re: Go runtime: 4 years later

#204

Post by Bakary »

hknmtt wrote: post #201
baby wrote: post #142

Earlier quoted context omitted.

What do you have against BLM?

My personal opinions aside, what does a programming language has to do with a political movement in one of the 195 countries in this world? Nothing, that's what. The political activists hijacked the Go community they had access to and power over for their own personal beliefs and agenda disregarding every bit of ethics or responsibility they were entrusted with. As the saying goes, with great power comes great respon…

I can understand being frustrated but isn't this somewhat of a very strong reaction to literally just a static element on a webpage? The more likely explanation is that you do care about that ideology in some way

Re: Go runtime: 4 years later

#205

Post by pjmlp »

simiones wrote: post #196
pjmlp wrote: post #122

Earlier quoted context omitted.

It is more powerful than Go on every sense, and I really don't get what people think using Go runtime into a completly different language would help. Maybe they should spend more attention in their compiler design classes regarding runtime implementations and language semantics.

I generally agree about the runtime and language semantics. However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).

What happened to microservices and UNIX way, each tool does one thing?

Yes, multithreading support is only in version 5.0, yet for many decades UNIX was multi-process only, and thanks to the latest security exploits, sandboxing with multi-processing alongside IPC seems to be the latest fashion anyway, so no big deal.

OCaml has several backends, including a bytecode one that is used for the REPL and porting purposes.

Re: Go runtime: 4 years later

#206

Post by simiones »

pjmlp wrote: post #205
simiones wrote: post #196

Earlier quoted context omitted.

I generally agree about the runtime and language semantics. However, (stable) OCaml not having multithreading support is still a gigantic limitation. Also, OCaml supports fewer target platforms, and I believe it's worse at cross-compiling (though I admit I may be wrong on this).

What happened to microservices and UNIX way, each tool does one thing? Yes, multithreading support is only in version 5.0, yet for many decades UNIX was multi-process only, and thanks to the latest security exploits, sandboxing with multi-processing alongside IPC seems to be the latest fashion anyway, so no big deal. OCaml has several backends, including a bytecode one that is used for the REPL and porting purposes.

Doing one thing on multiple threads is very much possible. Threads enable (simple) shared memory multi-processing, which is the most efficient version of multi-processing. You can theoretically get something similar with different processes and memory-mapped files, but multi-threading is much easier in general.

For example, if you want a high-performance web server, it's much more efficient to serve requests through multiple threads (preferably also using efficient IO) than it is to spawn different processes for different requests. I imagine you can coordinate different processes in similar ways, but again, it's much more effort, and either way, those processes are far too intimately tied to each other at that point to call them "different tools".

Re: Go runtime: 4 years later

#207

Post by doctor_eval »

xvello wrote: post #179
doctor_eval wrote: post #102

Earlier quoted context omitted.

> No default struct values I love Go too but this does drive me nuts, especially when parsing JSON and wanting to set sane defaults for missing values. Like, for example, booleans that should default to "true".

For that use case, I think that you can assign your defaults before passing your target struct to the unmarshaller. The unmarshaller will iterate on the json input and set struct fields when json fields are found. This means that struct fields that don't match the json are ignored, and values you have set before will be left as is.

While true, this approach doesn’t work for nested structs, which are instantiated by the parser.

Re: Go runtime: 4 years later

#208

Post by kaba0 »

cygx wrote: post #202
kaba0 wrote: post #185

Earlier quoted context omitted.

Then you can sure list some differences between go's and JVM's runtime.

Most relevant in context of our discussion: The JVM is a (virtual) stack machine with its own instruction set and semantics specified in the Java Virtual Machine Specification . As far as I'm aware, something equivalent does not exist for Go, or as an internal implementation detail at best (some intermediate representation might potentially qualify if you squint at it the right way).

That's also an implementation detail, because the majority of execution time happens in native code with a native GC "managing it" the exact same way, not by interpreting abstract virtual machine instructions.

Re: Go runtime: 4 years later

#209

Post by kaba0 »

simiones wrote: post #195
kaba0 wrote: post #151

Earlier quoted context omitted.

What is hard about Java? It is a very small language.

I don't think that's really true, at least not anymore. It's definitely smaller than C++ or Rust, slightly smaller than C#, but larger than Python, JavaScript, Go.

It is def not slightly smaller than C#, C# is a cool language, but it is definitely well ahead on a road towards becoming the next C++. C# is probably the second or third most complex/feature-full language I know of (not sure whether the list goes from C++, Swift, C#, or the last two reversed), while Java is quite down the list.

Not sure about any objective metric on the other languages, though. Tried to look at ANTLR grammar files for each, but grammar is only one part -- language semantics are not included. (E.g. Rust's grammar is slightly smaller than Java's, yet I don't think many would argue that it is the easier one). JavaScript, while easy on the surface, can actually be quite complex/has many non-idiomatic concepts, e.g. `this` handling, property flags, etc. Python has similar "rabbit holes".

Re: Go runtime: 4 years later

#210

Post by randomdata »

kajaktum wrote: post #181
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…

>There are a lot of programs where you don't need to think about errors What kind of utopian programming job do you have that you don't have to think about errors? An error is not limited to technical issues like packet loss or unable to open socket. Its also "client A attempted to purchase item B which is limited to client C". How do you express this in Go? I have no idea why people are so opposed to ADTs. Its like…

> What kind of utopian programming job do you have that you don't have to think about errors?

My job primarily requires thinking about errors. It is why I wish for Go-style errors in the languages I use.

But on rare occasions I write things like batch scripts, automations, etc. in which failure means addressing the issue in realtime and trying again. There you don't care much about errors other than ensuring that the world stops when an error occurs to allow you to fix the problem before continuing.

While contrived, if you run into a "client A attempted to purchase item B which is limited to client C" error in this space you're probably going to have to phone them up and tell them that you can't process the transaction, apologize for the mistake, remove record of their purchase, and then once complete run the script again. The program crashing with an error message is sufficient here.

Different tools for different jobs.

Post reply on HN