5 ms·

I really like go. Its simple in that you can learn the language pretty quick. I might get burned in another comment below but it's the language that feels the c

I really like go. Its simple in that you can learn the language pretty quick. I might get burned in another comment below but it's the language that feels the closest to C to me. Both are really simple languages that can get relatively complicated pretty fast. Inheritance through embedding for one feels a lot like using -fms-extensions in C. However I think the coolest part of the language is the part no one talks about. The inclusion of comments as a major part of a program. // +linux for managing files for specific platforms is just wonderful. //go:embed for embedding files and directories into your program // #include <stdlib.h> import "C" is probably the coolest and easiest ways to use C libraries I've seen. You can write C code directly into your go files and even set complier and linker flags. //go:generate can allow you to automate your build process from within your codebase.

JeremyBanks 6y ago
Go: we have so few keywords! Simple language! Also Go: because we shoved them all into comments instead! This seems like an extremely weird choice.
- vram22 6y ago
  Yes, I agree. Also (with the big caveat that I am not even a little bit of a language designer / implementer / lawyer, just a guy interested in these PL topics from early in my career), the use of comments, which are meant to be ignored by the compiler, to make certain actions happen, seems non-orthogonal and not a good choice. Like shoehorning something into something else it was not meant to be or support.
  - isaiahg 6y ago
    As someone who uses the language. I think it's one of its most overlooked features. By convention comments are ignored, but the truth is they're not by the programmer. Comments are extremely important to keep track of what you're doing and reading other people's code. So I think this is a case where the convention doesn't meet the reality. Also using these features within comments makes it so every use of these extra features is documented and shows up in completions, so you the programmer always know what you're doing. I'm a fan haha
    - vram22 6y ago
      >By convention comments are ignored, but the truth is they're not by the programmer. Disagree. It's more like the opposite is mostly true: By convention comments are not meant to be ignored, but the truth is they mostly are, by the average programmer. And most programmers are average, by definition of the word 'average' and by the bell curve law. Yes, with exceptions. Even if comments are not ignored in normal work, just wait for the next crunch to hit (which is mostly the default state or mode in many companies, anyway), and then see the fun. Every dev scrambling to hack the code any which way to meet the deadline / target / ship date, and now maintaining comments is a goal that flies out of the window. Been there, seen that, plenty, though also worked in places where that was not the case. Those are few in number, though. There can be other issues too, with compiler directives as comments. What if the directive-as-comment is itself now commented out, maybe as part of commenting out a larger surrounding block of code? Now you (and the compiler writer) have two problems :) http://regex.info/blog/2006-09-15/247 http://regex.info/blog/2006-09-15/247
      - vram22 6y ago
        >>By convention comments are ignored, but the truth is they're not by the programmer. >Disagree. It's more like the opposite is mostly true: >By convention comments are not meant to be ignored Otherwise who on earth would write them? Who would like to write stuff that "by convention", is not going to be read?
  - everybodyknows 6y ago
    As someone who uses the language every day, I fully agree. My work would be easier if they all conformed to some syntax not easily mistaken for an ordinary line comment. A standard preamble of '///', say. No doubt sophisticated IDEs highlight them somehow, but more naive editor extensions e.g. Emacs 'go-mode', do not. No color-coding.
avaldeso 6y ago
> // #include <stdlib.h> import "C" > is probably the coolest and easiest ways to use C libraries I've seen. You should see Zig's interoperability.
everybodyknows 6y ago
Documentation links (incomplete): // +linux Dunno -- help, anyone? //go:embed https://golang.org/pkg/embed/ https://golang.org/pkg/embed/ // #include <stdlib.h> import "C" https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ // go:generate https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processi...
- ainar-g 6y ago
  > Dunno -- help, anyone? https://golang.org/cmd/go/#hdr-Build_constraints https://golang.org/cmd/go/#hdr-Build_constraints EDIT: Those are in the process of being replaced with //go:build directives. See https://github.com/golang/go/issues/41184 https://github.com/golang/go/issues/41184.

JeremyBanks 6y ago

Go: we have so few keywords! Simple language! Also Go: because we shoved them all into comments instead! This seems like an extremely weird choice.

vram22 6y ago
Yes, I agree. Also (with the big caveat that I am not even a little bit of a language designer / implementer / lawyer, just a guy interested in these PL topics from early in my career), the use of comments, which are meant to be ignored by the compiler, to make certain actions happen, seems non-orthogonal and not a good choice. Like shoehorning something into something else it was not meant to be or support.
- isaiahg 6y ago
  As someone who uses the language. I think it's one of its most overlooked features. By convention comments are ignored, but the truth is they're not by the programmer. Comments are extremely important to keep track of what you're doing and reading other people's code. So I think this is a case where the convention doesn't meet the reality. Also using these features within comments makes it so every use of these extra features is documented and shows up in completions, so you the programmer always know what you're doing. I'm a fan haha
  - vram22 6y ago
    >By convention comments are ignored, but the truth is they're not by the programmer. Disagree. It's more like the opposite is mostly true: By convention comments are not meant to be ignored, but the truth is they mostly are, by the average programmer. And most programmers are average, by definition of the word 'average' and by the bell curve law. Yes, with exceptions. Even if comments are not ignored in normal work, just wait for the next crunch to hit (which is mostly the default state or mode in many companies, anyway), and then see the fun. Every dev scrambling to hack the code any which way to meet the deadline / target / ship date, and now maintaining comments is a goal that flies out of the window. Been there, seen that, plenty, though also worked in places where that was not the case. Those are few in number, though. There can be other issues too, with compiler directives as comments. What if the directive-as-comment is itself now commented out, maybe as part of commenting out a larger surrounding block of code? Now you (and the compiler writer) have two problems :) http://regex.info/blog/2006-09-15/247 http://regex.info/blog/2006-09-15/247
    - vram22 6y ago
      >>By convention comments are ignored, but the truth is they're not by the programmer. >Disagree. It's more like the opposite is mostly true: >By convention comments are not meant to be ignored Otherwise who on earth would write them? Who would like to write stuff that "by convention", is not going to be read?
- everybodyknows 6y ago
  As someone who uses the language every day, I fully agree. My work would be easier if they all conformed to some syntax not easily mistaken for an ordinary line comment. A standard preamble of '///', say. No doubt sophisticated IDEs highlight them somehow, but more naive editor extensions e.g. Emacs 'go-mode', do not. No color-coding.

avaldeso 6y ago

> // #include <stdlib.h> import "C" > is probably the coolest and easiest ways to use C libraries I've seen. You should see Zig's interoperability.

everybodyknows 6y ago

Documentation links (incomplete): // +linux Dunno -- help, anyone? //go:embed https://golang.org/pkg/embed/ https://golang.org/pkg/embed/ // #include <stdlib.h> import "C" https://golang.org/cmd/cgo/ https://golang.org/cmd/cgo/ // go:generate https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processing_source https://golang.org/cmd/go/#hdr-Generate_Go_files_by_processi...

ainar-g 6y ago
> Dunno -- help, anyone? https://golang.org/cmd/go/#hdr-Build_constraints https://golang.org/cmd/go/#hdr-Build_constraints EDIT: Those are in the process of being replaced with //go:build directives. See https://github.com/golang/go/issues/41184 https://github.com/golang/go/issues/41184.