7 ms·

It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer

by toolz 2y ago

It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.

aorona 2y ago
subpar semantics?
wesselbindt 2y ago
I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great? I did not post your parent comment.
- wrs 2y ago
  To name a few things: Excellent and very stable stdlib (if you’re making a networked thing), fast GC optimized for latency, async I/O without any fuss, easy CSP-like concurrency, fast compile time, statically linked binaries, large user community.
- zer00eyz 2y ago
  GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ----------------------- Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism. As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....
  - eximius 2y ago
    > As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support. In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.
    - jimbokun 2y ago
      DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
      - eximius 2y ago
        I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
        jimbokun 2y ago
        The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
- zem 2y ago
  seamless cross compilation as a first-class citizen, for one
zer00eyz 2y ago
This is a terrible take. It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use. Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies. Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an adult and deal with your errors (it's a feature)... That minimalist no bullshit language semantics that force you not to be lazy is a feature not a bug.
- 2024throwaway 2y ago
  I'm not sure why you included php in your list of examples of things that become bloated with dependencies. I've never seen that be the case.
  - sleepybrett 2y ago
    [flagged]
    - 2024throwaway 2y ago
      I just opened the composer.json file for a complex PHP application, it has 20 imports, total. I just opened the package.json for a react frontend, it has 80 imports. I just opened the Gemfile for a complex rails application, it has 150+ imports. But sure, I'm just trolling I guess.
      - deleted 2y ago
        [deleted]
  - nasretdinov 2y ago
    Look at your list of built-in modules though :)
    - 2024throwaway 2y ago
ReflectedImage 2y ago
Ahh the failure to recognize that the great runtime and tooling is due to the language semantics.
- networked 2y ago
  I think the most complained-about semantics of Go have been the lack of generics, the lack of algebraic data types, nil, and the error handling. Generics are now implemented, and just about nobody considers the tooling and the runtime ruined because of them. Projects like Borgo and Oden are evidence that you can have what people like about the Go runtime and tooling combined with ADT-based error handling and restricted nil.

by toolz 2y ago

It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.

aorona 2y ago

subpar semantics?

wesselbindt 2y ago

I'm not trying to be argumentative, I'm genuinely curious: what is it about the go runtime and tooling that makes them great? I did not post your parent comment.

wrs 2y ago
To name a few things: Excellent and very stable stdlib (if you’re making a networked thing), fast GC optimized for latency, async I/O without any fuss, easy CSP-like concurrency, fast compile time, statically linked binaries, large user community.
zer00eyz 2y ago
GO: Easy to learn: you can be productive in go in a day or two. Strong standard library. Complies to binary. (you dont need to drag a run time around) And this is fast! Easy dependency management. Linting is built in. (No arguing over tabs vs spaces) First class testing. (and its fast) "good enough" coding is very fast. You can mostly ignore performance and pick it up when and where you need it. ----------------------- Go users tend to say "Idiomatic" a lot. Your not getting rails, there is no java like framework, and you really should NOT do the node js thing and stack tools to the sky. Minimalism, brutalism. As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. Its just a bit of code (100 ish lines) that you end up writing as part of your bootstrapping, config or testing (depending on the project)....
- eximius 2y ago
  > As an example: Most languages have tooling for dependency injection. Most go projects have dependency injection but dont use a library or framework or tooling to do it. I actually see this as a negative and we've been looking at Uber/Fx for more support. DI frameworks don't do anything you can't do without it, but it takes significantly more experience and technological/organizational maturity that I find the average developer doesn't have to do it without framework support. In the current zeitgeist of being towards the "micro" scale of the spectrum, that "average developer" support is necessary. If you have more modular monoliths or many high quality examples, maybe its better.
  - jimbokun 2y ago
    DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code. I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
    - eximius 2y ago
      I've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
      - jimbokun 2y ago
        The autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
zem 2y ago
seamless cross compilation as a first-class citizen, for one

zer00eyz 2y ago

This is a terrible take. It's like one of those people who buys a massive over priced knife block with 48 knives in it that they never use. Most go devs have lived through bloated java/php/python/ruby/js projects that become a pile of dependencies. Go is to coding what brutalism is to architecture. Simple, functional, efficient. Dont build a massive dependency chain, dont build magic, repeating yourself is OK. Be an adult and deal with your errors (it's a feature)... That minimalist no bullshit language semantics that force you not to be lazy is a feature not a bug.

2024throwaway 2y ago
I'm not sure why you included php in your list of examples of things that become bloated with dependencies. I've never seen that be the case.
- sleepybrett 2y ago
  [flagged]
  - 2024throwaway 2y ago
    I just opened the composer.json file for a complex PHP application, it has 20 imports, total. I just opened the package.json for a react frontend, it has 80 imports. I just opened the Gemfile for a complex rails application, it has 150+ imports. But sure, I'm just trolling I guess.
    - deleted 2y ago
      [deleted]
- nasretdinov 2y ago
  Look at your list of built-in modules though :)
  - 2024throwaway 2y ago

ReflectedImage 2y ago

Ahh the failure to recognize that the great runtime and tooling is due to the language semantics.

networked 2y ago
I think the most complained-about semantics of Go have been the lack of generics, the lack of algebraic data types, nil, and the error handling. Generics are now implemented, and just about nobody considers the tooling and the runtime ruined because of them. Projects like Borgo and Oden are evidence that you can have what people like about the Go runtime and tooling combined with ADT-based error handling and restricted nil.