5 ms·

Maybe it's a little off topic here, but why would you consider Golang a terrible language?

xyzzy123 6y ago
Go seems to reliably trigger language wars every time it's mentioned. It's a surprisingly divisive language. Go users seem to mostly be happy cranking stuff out but a lot of people hate it. No generics, a culture of "if err != nil", type system not powerful enough, libraries not pure enough, too verbose, etc.
- pjmlp 6y ago
  Because it basically has a culture of driving to the bottom in language features. Sure I can code full applications in GW-BASIC or whatever programming language of similar age, and did, almost 40 years ago. It doesn't mean I enjoy doing them today, beyond some nostalgic weekend hobby. Then again, assuming that generics proposal doesn't end the same way as the error one, it won't be that bad. Go will finally feel like using CLU (from 1975).
  - xyzzy123 6y ago
    I think of it as the new PHP. Early PHP was a terrible language that people nonetheless built a ton of cool things with, for a variety of ergonomic and social reasons that are not that easy to pin down exactly.
    - nine_k 6y ago
      One reason is that people with ideas and a drive to implement them are often not experienced developers. They have a product mentality, and see the need to implement things in code as a nuisance that stands between them and their idea. So they pick the easiest, lowest-hanging tool, not the sharpest or cleanest.
    - fomine3 6y ago
      I'd like to say it's similar to old day's Java. PHP introduced random features early days but Java and Go doesn't.
linkdd 6y ago
Golang is great for small code bases, in a UNIX world where each program do only one thing, this is perfectly fine. But once the code base grows, it easily becomes a tangled mess. My biggest con for Go would be the project directory structure. At the toplevel of a project, I like to have only "src", "tests", "docs", "examples" and eventually "containers" if I provide Docker images. With go, it seems that everything should be at the toplevel (or maybe I haven't seen nicely structured projects yet?).
- antoinealb 6y ago
  Could this be an issue with Go's built in build system rather than go the language ? At work I use go with Bazel and found it okay with regard to source layout, similar to my experience with c++. I don't have experience with go outside of Bazel though.
  - linkdd 6y ago
    When I try to decide if i want to use a language, I look at its ecosystem. It may have the best features in the world, but if the ecosystem is not there, it will be a pain to use it. On the opposite, a language can have the worst features and a great ecosystem, for example Python is slow but as great scientific tools, or Javascript has a weird "typing system" but has tons of tools in every domain to make the best of it. I don't know Bazel though, I'll take a look at it, thanks!
- arp242 6y ago
  You can store Go files in src/ if you really want, nothing really stopping you, but it's not the usual approach, no. Tests are usually stored next to the actual implementations rather than a tests/ directory. In which directory to store files is an incredibly small and minor detail though.
  - linkdd 6y ago
    > nothing really stopping you, but it's not the usual approach In my experience, if you open-source a project, it better have to follow conventions. Following conventions makes sure someone else can read your code easily. > In which directory to store files is an incredibly small and minor detail though. Yeah it's a small detail, but it is important to me to not get lost in a directory tree. Random example taken from a github search: https://github.com/gofiber/fiber https://github.com/gofiber/fiber Is it really ok to have that much source code at the toplevel? Is the code architecture clear at a glance? For me, it is not, and I'll have to put in extra work (I'm lazy) to understand the code and how it works. I don't mind doing that for other projects, but for my projects as I work on them daily, it becomes a pain very quickly.
richardjennings 6y ago
In the container context, the Go runtime gets in the way of namespace control; 'Docker' as in RunC uses C to work around this (last time I looked) and so is compiled with cgo. I'm not sure that the direct creation/control of a container is possible using just Go. I would love to be out of date and wrong!?
- pjmlp 6y ago
  At some level one needs to provide bindings to the underlying OS APIs. Naturally C doesn't need bindings, when the OS APIs are written in C.
  - richardjennings 6y ago
    The particular implementation detail I was referring to: https://github.com/opencontainers/runc/tree/master/libcontainer/nsenter https://github.com/opencontainers/runc/tree/master/libcontai... The distinction I was attempting to make is whether or not C source code is required in your Go project to fully implement a container runtime.
    - pjmlp 6y ago
      How do you propose to implement bindings to Linux APIs, written in C?
      - richardjennings 6y ago
        From Go? There is the syscall package. More generally C is just adding some conventions, like 'calling' that can be interacted with by following the rules from e.g assembly or a higher level language that can compile to compatible calls.
        pjmlp 6y ago
        Fair enough, I forgot about that one.

Go seems to reliably trigger language wars every time it's mentioned. It's a surprisingly divisive language. Go users seem to mostly be happy cranking stuff out but a lot of people hate it. No generics, a culture of "if err != nil", type system not powerful enough, libraries not pure enough, too verbose, etc.

pjmlp 6y ago
Because it basically has a culture of driving to the bottom in language features. Sure I can code full applications in GW-BASIC or whatever programming language of similar age, and did, almost 40 years ago. It doesn't mean I enjoy doing them today, beyond some nostalgic weekend hobby. Then again, assuming that generics proposal doesn't end the same way as the error one, it won't be that bad. Go will finally feel like using CLU (from 1975).
- xyzzy123 6y ago
  I think of it as the new PHP. Early PHP was a terrible language that people nonetheless built a ton of cool things with, for a variety of ergonomic and social reasons that are not that easy to pin down exactly.
  - nine_k 6y ago
    One reason is that people with ideas and a drive to implement them are often not experienced developers. They have a product mentality, and see the need to implement things in code as a nuisance that stands between them and their idea. So they pick the easiest, lowest-hanging tool, not the sharpest or cleanest.
  - fomine3 6y ago
    I'd like to say it's similar to old day's Java. PHP introduced random features early days but Java and Go doesn't.

linkdd 6y ago

Golang is great for small code bases, in a UNIX world where each program do only one thing, this is perfectly fine. But once the code base grows, it easily becomes a tangled mess. My biggest con for Go would be the project directory structure. At the toplevel of a project, I like to have only "src", "tests", "docs", "examples" and eventually "containers" if I provide Docker images. With go, it seems that everything should be at the toplevel (or maybe I haven't seen nicely structured projects yet?).

antoinealb 6y ago
Could this be an issue with Go's built in build system rather than go the language ? At work I use go with Bazel and found it okay with regard to source layout, similar to my experience with c++. I don't have experience with go outside of Bazel though.
- linkdd 6y ago
  When I try to decide if i want to use a language, I look at its ecosystem. It may have the best features in the world, but if the ecosystem is not there, it will be a pain to use it. On the opposite, a language can have the worst features and a great ecosystem, for example Python is slow but as great scientific tools, or Javascript has a weird "typing system" but has tons of tools in every domain to make the best of it. I don't know Bazel though, I'll take a look at it, thanks!
arp242 6y ago
You can store Go files in src/ if you really want, nothing really stopping you, but it's not the usual approach, no. Tests are usually stored next to the actual implementations rather than a tests/ directory. In which directory to store files is an incredibly small and minor detail though.
- linkdd 6y ago
  > nothing really stopping you, but it's not the usual approach In my experience, if you open-source a project, it better have to follow conventions. Following conventions makes sure someone else can read your code easily. > In which directory to store files is an incredibly small and minor detail though. Yeah it's a small detail, but it is important to me to not get lost in a directory tree. Random example taken from a github search: https://github.com/gofiber/fiber https://github.com/gofiber/fiber Is it really ok to have that much source code at the toplevel? Is the code architecture clear at a glance? For me, it is not, and I'll have to put in extra work (I'm lazy) to understand the code and how it works. I don't mind doing that for other projects, but for my projects as I work on them daily, it becomes a pain very quickly.

richardjennings 6y ago

In the container context, the Go runtime gets in the way of namespace control; 'Docker' as in RunC uses C to work around this (last time I looked) and so is compiled with cgo. I'm not sure that the direct creation/control of a container is possible using just Go. I would love to be out of date and wrong!?

pjmlp 6y ago
At some level one needs to provide bindings to the underlying OS APIs. Naturally C doesn't need bindings, when the OS APIs are written in C.
- richardjennings 6y ago
  The particular implementation detail I was referring to: https://github.com/opencontainers/runc/tree/master/libcontainer/nsenter https://github.com/opencontainers/runc/tree/master/libcontai... The distinction I was attempting to make is whether or not C source code is required in your Go project to fully implement a container runtime.
  - pjmlp 6y ago
    How do you propose to implement bindings to Linux APIs, written in C?
    - richardjennings 6y ago
      From Go? There is the syscall package. More generally C is just adding some conventions, like 'calling' that can be interacted with by following the rules from e.g assembly or a higher level language that can compile to compatible calls.
      - pjmlp 6y ago
        Fair enough, I forgot about that one.