Go - Revision history

JaroslavTulach at 05:38, 26 March 2022

2022-03-26T05:38:41Z

←Older revision		Revision as of 05:38, 26 March 2022
Line 4:		Line 4:
	* [[wikipedia:compiled language\|compiled]] language in the tradition of [[C]]		* [[wikipedia:compiled language\|compiled]] language in the tradition of [[C]]
	* with [[wikipedia:memory safety\|memory safety]]		* with [[wikipedia:memory safety\|memory safety]]
-	* and [[~~wikipedia:garbage collection (computer science)\|garbage collection~~]]	+	* and [[Garbage Collection]]
	* and [[wikipedia:structural type system\|structural typing]]		* and [[wikipedia:structural type system\|structural typing]]
	* and [[wikipedia:communicating sequential processes\|CSP]]-style [[wikipedia:concurrency (computer_science)\|concurrency]]		* and [[wikipedia:communicating sequential processes\|CSP]]-style [[wikipedia:concurrency (computer_science)\|concurrency]]
Line 12:		Line 12:
	=== Forget [[Go]]! ===		=== Forget [[Go]]! ===

-	[[Go]] is mostly used in places where fast start, low system requirements and multi-threaded communication is needed and where lower level language like [[C]] is considered too dangerous. [[Go]] comes with a promise of a system language, yet adding memory safety and automatic [[~~wikipedia:garbage collection (computer science)\|garbage collection~~]]. If you have such needs and you are looking for a language, you may think that [[Go]] is the right choice. Maybe it is for you, however, it is not the only choice. Let's consider an alternative. Let's consider [[Java]]!	+	[[Go]] is mostly used in places where fast start, low system requirements and multi-threaded communication is needed and where lower level language like [[C]] is considered too dangerous. [[Go]] comes with a promise of a system language, yet adding memory safety and automatic [[Garbage Collection]]. If you have such needs and you are looking for a language, you may think that [[Go]] is the right choice. Maybe it is for you, however, it is not the only choice. Let's consider an alternative. Let's consider [[Java]]!

	==== [[Java]] as a [[Language]] ====		==== [[Java]] as a [[Language]] ====
Line 23:		Line 23:
	** or with [[NativeImage]] into native code in the tradition of [[C]]		** or with [[NativeImage]] into native code in the tradition of [[C]]
	* with [[wikipedia:memory safety\|memory safety]]		* with [[wikipedia:memory safety\|memory safety]]
-	* and [[~~wikipedia:garbage collection (computer science)\|garbage collection~~]]	+	* and [[Garbage Collection]]
	* and [[OOP\|object oriented typing]]		* and [[OOP\|object oriented typing]]
	* with [[Monitor\|multi-threading concepts]] built into the [[language]] since day one		* with [[Monitor\|multi-threading concepts]] built into the [[language]] since day one

JaroslavTulach: /* Freedom of Choice */

2019-05-21T15:10:31Z

Freedom of Choice

←Older revision		Revision as of 15:10, 21 May 2019
Line 112:		Line 112:

	The resulting file is slightly bigger (probably as a result of adhering to general [[Java]] semantics), but the size remains comparable to the size of the [[Go]] executable. The same benefits apply - just copy the file and it will carry everything necessary with it. No need to have multi megabyte [[JDK]] installation around. Slim and suitable for your [[docker]] or any other restricted system.		The resulting file is slightly bigger (probably as a result of adhering to general [[Java]] semantics), but the size remains comparable to the size of the [[Go]] executable. The same benefits apply - just copy the file and it will carry everything necessary with it. No need to have multi megabyte [[JDK]] installation around. Slim and suitable for your [[docker]] or any other restricted system.
		+
		+	{{#ev:youtube\|TJU3zy4b-Iw}}

	==== Freedom of Choice ====		==== Freedom of Choice ====

JaroslavTulach: /* Summary */

2018-11-29T13:51:20Z

Summary

←Older revision		Revision as of 13:51, 29 November 2018
Line 121:		Line 121:
	Another area that benefits from the fierce competition in the last two decades is tooling support. Those twenty years of industry competition for the best [[Java]] [[IDE]] lead to enormous amount of refactorings, completions, libraries and frameworks. Moreover [[NativeImage]] isn't restricted to [[Java]]. It processes any [[JVM]] language. As such you can code in [[Scala]] or [[Kotlin]] or any other language that compiles to bytecode enlarging the freedom of choices even more.		Another area that benefits from the fierce competition in the last two decades is tooling support. Those twenty years of industry competition for the best [[Java]] [[IDE]] lead to enormous amount of refactorings, completions, libraries and frameworks. Moreover [[NativeImage]] isn't restricted to [[Java]]. It processes any [[JVM]] language. As such you can code in [[Scala]] or [[Kotlin]] or any other language that compiles to bytecode enlarging the freedom of choices even more.

-	== ~~Summary~~ ==	+	== Go [[Java]], Go! ==

	[[NativeImage]] provides viable alternative to [[Go]]. Not only it benefits from [[Java]] ecosystem features, but it even yields '''faster''' code, while keeping up on the essential aspects [[Go]] was invented for: [[NativeImage]] produces single '''self-contained''' binary with '''instant''' startup and '''low memory''' consumption. [[Java]] and other [[JVM]] [[language]]s and [[NativeImage]] form a great choice when considering [[OS]]-level development.		[[NativeImage]] provides viable alternative to [[Go]]. Not only it benefits from [[Java]] ecosystem features, but it even yields '''faster''' code, while keeping up on the essential aspects [[Go]] was invented for: [[NativeImage]] produces single '''self-contained''' binary with '''instant''' startup and '''low memory''' consumption. [[Java]] and other [[JVM]] [[language]]s and [[NativeImage]] form a great choice when considering [[OS]]-level development.

	PS: Next time we look at the interface to [[C]] (e.g. operating system [[API]]).		PS: Next time we look at the interface to [[C]] (e.g. operating system [[API]]).

JaroslavTulach: /* Freedom of Choice */

2018-10-01T12:56:37Z

Freedom of Choice

←Older revision		Revision as of 12:56, 1 October 2018
Line 117:		Line 117:
	[[Go]] is a [[language]] designed from scratch to solve problems that arise when developing low level [[OS]] programs. [[Go]] does that quite well. On the other hand, the from scratch design has its drawbacks. The whole [[Go]] stack is written by the [[Go]] team. It is not based on any industry wide accepted solution. It is not based on [[LLVM]] stack. It is not build around [[GCC]] infrastructure. It is written by [[Google]] from top to bottom. This has a negative effect on features, as well as speed. The team paid for [[Go]] support isn't infinite, and thus it cannot address all the incoming requests immediately.		[[Go]] is a [[language]] designed from scratch to solve problems that arise when developing low level [[OS]] programs. [[Go]] does that quite well. On the other hand, the from scratch design has its drawbacks. The whole [[Go]] stack is written by the [[Go]] team. It is not based on any industry wide accepted solution. It is not based on [[LLVM]] stack. It is not build around [[GCC]] infrastructure. It is written by [[Google]] from top to bottom. This has a negative effect on features, as well as speed. The team paid for [[Go]] support isn't infinite, and thus it cannot address all the incoming requests immediately.

-	This is not the case of [[Java]], neither [[NativeImage]]. [[JVM]] has been around for more than twenty years. The [[HotSpot]] virtual machine and compiler have been enormously optimized. The whole [[GraalVM]] stack builds upon that work. So does [[NativeImage]] - in fact the [[AOT]] compiler behind it is the same as the [[JIT]] compiler used in [[GraalVM]] [[HotSpot]] mode - e.g. the same optimizations that are applied to your code when running on a standard [[JDK]] are applicable to [[NativeImage]] generated binary.	+	This is not the case of [[Java]], neither [[NativeImage]]. [[JVM]] has been around for more than twenty years. The [[HotSpot]] virtual machine and compiler have been widely accepted by the whole industry and as a result of that enormously optimized. The whole [[GraalVM]] stack builds upon that work. So does [[NativeImage]] - in fact the [[AOT]] compiler behind it is the same as the [[JIT]] compiler used in [[GraalVM]] [[HotSpot]] mode - e.g. the same optimizations that are applied to your code when running on a standard [[JDK]] are applicable to [[NativeImage]] generated binary.

	Another area that benefits from the fierce competition in the last two decades is tooling support. Those twenty years of industry competition for the best [[Java]] [[IDE]] lead to enormous amount of refactorings, completions, libraries and frameworks. Moreover [[NativeImage]] isn't restricted to [[Java]]. It processes any [[JVM]] language. As such you can code in [[Scala]] or [[Kotlin]] or any other language that compiles to bytecode enlarging the freedom of choices even more.		Another area that benefits from the fierce competition in the last two decades is tooling support. Those twenty years of industry competition for the best [[Java]] [[IDE]] lead to enormous amount of refactorings, completions, libraries and frameworks. Moreover [[NativeImage]] isn't restricted to [[Java]]. It processes any [[JVM]] language. As such you can code in [[Scala]] or [[Kotlin]] or any other language that compiles to bytecode enlarging the freedom of choices even more.

JaroslavTulach: /* Freedom of Choice */

2018-10-01T12:55:43Z

Freedom of Choice

←Older revision		Revision as of 12:55, 1 October 2018
Line 115:		Line 115:
	==== Freedom of Choice ====		==== Freedom of Choice ====

-	[[Go]] is a [[language]] designed from scratch to solve problems that arise when developing low level [[OS]] programs. [[Go]] does that quite well. On the other hand, the from scratch design has its drawbacks. The whole [[Go]] stack is written by the [[Go]] team. It is not based ~~only~~ any industry wide accepted solution. It is not based on [[LLVM]] stack. It is not build around [[GCC]] infrastructure. It is written by [[Google]] from top to bottom. This has a negative effect on features, as well as speed. The team paid for [[Go]] support isn't infinite, and thus it cannot address all the incoming requests immediately.	+	[[Go]] is a [[language]] designed from scratch to solve problems that arise when developing low level [[OS]] programs. [[Go]] does that quite well. On the other hand, the from scratch design has its drawbacks. The whole [[Go]] stack is written by the [[Go]] team. It is not based on any industry wide accepted solution. It is not based on [[LLVM]] stack. It is not build around [[GCC]] infrastructure. It is written by [[Google]] from top to bottom. This has a negative effect on features, as well as speed. The team paid for [[Go]] support isn't infinite, and thus it cannot address all the incoming requests immediately.

	This is not the case of [[Java]], neither [[NativeImage]]. [[JVM]] has been around for more than twenty years. The [[HotSpot]] virtual machine and compiler have been enormously optimized. The whole [[GraalVM]] stack builds upon that work. So does [[NativeImage]] - in fact the [[AOT]] compiler behind it is the same as the [[JIT]] compiler used in [[GraalVM]] [[HotSpot]] mode - e.g. the same optimizations that are applied to your code when running on a standard [[JDK]] are applicable to [[NativeImage]] generated binary.		This is not the case of [[Java]], neither [[NativeImage]]. [[JVM]] has been around for more than twenty years. The [[HotSpot]] virtual machine and compiler have been enormously optimized. The whole [[GraalVM]] stack builds upon that work. So does [[NativeImage]] - in fact the [[AOT]] compiler behind it is the same as the [[JIT]] compiler used in [[GraalVM]] [[HotSpot]] mode - e.g. the same optimizations that are applied to your code when running on a standard [[JDK]] are applicable to [[NativeImage]] generated binary.

JaroslavTulach: /* Encapsulated Single Binary */

2018-10-01T12:54:32Z

Encapsulated Single Binary

←Older revision		Revision as of 12:54, 1 October 2018
Line 111:		Line 111:
	</source>		</source>

-	The resulting file is slightly bigger (probably as a result of adhering to ~~various~~ [[Java]] semantics), but the size remains comparable to the size of the [[Go]] executable. The same benefits apply - just copy the file and it will carry everything necessary with it. No need to have multi megabyte [[JDK]] installation around. Slim and suitable for your [[docker]] or any other restricted system.	+	The resulting file is slightly bigger (probably as a result of adhering to general [[Java]] semantics), but the size remains comparable to the size of the [[Go]] executable. The same benefits apply - just copy the file and it will carry everything necessary with it. No need to have multi megabyte [[JDK]] installation around. Slim and suitable for your [[docker]] or any other restricted system.

	==== Freedom of Choice ====		==== Freedom of Choice ====

JaroslavTulach: /* Encapsulated Single Binary */

2018-10-01T12:53:46Z

Encapsulated Single Binary

←Older revision		Revision as of 12:53, 1 October 2018
Line 95:		Line 95:
	==== Encapsulated Single Binary ====		==== Encapsulated Single Binary ====

-	One of the great things on [[Go]] is its ability to compile everything into a single executable file. This results in faster startup (no dynamic [[libraries]] are needed once the executable file is loaded in) and easier portability in embedded systems - enough to transfer the single file, which carries all its [[environment]] with it. In our sieve ~~exapmle~~ the size is less than two megabytes:	+	One of the great things on [[Go]] is its ability to compile everything into a single executable file. This results in faster startup (no dynamic [[libraries]] are needed once the executable file is loaded in) and easier portability in embedded systems - enough to transfer the single file, which carries all its [[environment]] with it. In our sieve example the size is less than two megabytes:

	<source lang="bash">		<source lang="bash">

JaroslavTulach: /* Encapsulated Single Binary */

2018-10-01T12:53:19Z

Encapsulated Single Binary

←Older revision		Revision as of 12:53, 1 October 2018
Line 95:		Line 95:
	==== Encapsulated Single Binary ====		==== Encapsulated Single Binary ====

-	One of the great things on [[Go]] is its ability to compile everything into a single executable file. This results in faster startup (a no dynamic [[libraries]] are needed once the executable file is loaded in) and easier portability in embedded systems - enough to transfer the single file, which carries all its [[environment]] with it. In our sieve exapmle the size is less than two megabytes:	+	One of the great things on [[Go]] is its ability to compile everything into a single executable file. This results in faster startup (no dynamic [[libraries]] are needed once the executable file is loaded in) and easier portability in embedded systems - enough to transfer the single file, which carries all its [[environment]] with it. In our sieve exapmle the size is less than two megabytes:

	<source lang="bash">		<source lang="bash">

JaroslavTulach: /* The Speed */

2018-10-01T12:52:44Z

The Speed

←Older revision		Revision as of 12:52, 1 October 2018
Line 91:		Line 91:
	</source>		</source>

-	Again, some overhead is there. This [[NativeImage]] version is slower than [[C]], but this time at most twice as much. Clearly, in terms of execution speed the [[Java]]+[[NativeImage]] compilation is at least comparable to the [[Go]] version.	+	Again, some overhead is there. This [[NativeImage]] version is also slower than [[C]], but this time at most twice as much. Clearly, in terms of execution speed the [[Java]]+[[NativeImage]] compilation is at least comparable to the [[Go]] version.

	==== Encapsulated Single Binary ====		==== Encapsulated Single Binary ====

JaroslavTulach: /* The Speed */

2018-10-01T12:51:44Z

The Speed

←Older revision		Revision as of 12:51, 1 October 2018
Line 45:		Line 45:
	Comparing [[speed]] of various [[language]] implementations isn't trivial task and there is usually a lot of room for cheating. On the other hand, there is an independent set of operations ('''if''', '''while''', memory access, memory cleanup) which shall compare so called [[Turing Speed]] relatively accurately. I maintain a [https://github.com/jtulach/sieve project] to measure [[Turing Speed]] of various programming [[language]]s on a variant of Ancient and well known [[Sieve of Eratosthenes]] algorithm.		Comparing [[speed]] of various [[language]] implementations isn't trivial task and there is usually a lot of room for cheating. On the other hand, there is an independent set of operations ('''if''', '''while''', memory access, memory cleanup) which shall compare so called [[Turing Speed]] relatively accurately. I maintain a [https://github.com/jtulach/sieve project] to measure [[Turing Speed]] of various programming [[language]]s on a variant of Ancient and well known [[Sieve of Eratosthenes]] algorithm.

-	Let's compare [[Go]], [[C]] and ~~various flavors of~~ [[Java]]. What follows are results of https://github.com/jtulach/sieve revision a671eb115 compiled with go1.9.2 on [[Ubuntu]] 16.04:	+	Let's compare [[Go]], [[C]] and [[NativeImage]] [[Java]]. What follows are results of https://github.com/jtulach/sieve revision a671eb115 compiled with go1.9.2 on [[Ubuntu]] 16.04:

	<source lang="bash">		<source lang="bash">