3 ms·

On the flip side, what would be the point? There are already a million other languages that have everything and the kitchen sink. Not going down the same road

by 9rx 1y ago

On the flip side, what would be the point? There are already a million other languages that have everything and the kitchen sink. Not going down the same road is the only reason it didn't end up on the pile of obscure languages nobody uses.

pjmlp 1y ago
The only reason it didn't end on pile of obscure languages nobody uses, it called Google, followed by luck with Docker and Kubernetes adoption on the market, after they decided to rewrite from Python and Java respectively into Go, after Go heads joined their teams. Case in point, Limbo and Oberon-2, the languages that influenced its design, and authors were involved with.
- 9rx 1y ago
  > The only reason it didn't end on pile of obscure languages nobody uses, it called Google Dart ended up on the pile of languages nobody uses. And Carbon? What's Carbon? Exactly! > Case in point, Limbo and Oberon-2, the languages that influenced its design Agreed. Limbo and Oberon-2, as primitive as they may look now, had the kitchen sinks of their time. Why wouldn't they have ended up on the pile of languages nobody uses?
  - pjmlp 1y ago
    People love to bring those as counter examples, without actually knowing a single fact about them. Dart was a victim of internal politics between the Chrome team, Dart team, AdWords moving away from GWT wanting AngularDart (see Angular documentary), and the Web in general. Had Chrome team kept pushing DartVM, it might have been quite different story. Carbon, good example of failure to actually know what the team purposes are. It is officially a research project for Google themselves, where the team is the first to advise using Rust or another MSL. One just needs to actually spend like a couple of minutes on their wiki, but I guess that is asking too much on modern times. Limbo and Oberon-2 were definitely not kitchen sinks of their time, their failure was that neither Bell Labs in 1996, nor ETHZ in 1992, were that relevant for the programming language community in the industry.
    - 9rx 1y ago
      > Had Chrome team kept pushing DartVM, it might have been quite different story. Trouble with that line of thinking is that Google never pushed Go either. It didn't even bother to use it internally (outside from the occasional side project here and there). Google paid some salaries. I'll give you that. But it has paid salaries for a lot of different languages. That is not some kind of secret sauce. > It is officially a research project for Google themselves It's not just a research project. It is officially "not ready for use", but its roadmap has a clear "ready for use" plan in the coming months. Rust was also "not ready for use" when it hit the streets, it officially being a Mozilla research project, but every second discussion on HN was about it and what is to come. And that was without Google backing. If what you say is true, why isn't Carbon being shouted from every rooftop right now? I know you're struggling to grasp at straws here, but let's just be honest for a moment: If it hasn't caught attention already, it isn't going to. Just another language to add to the pile.
      - pjmlp 1y ago
        I guess Kubernetes doesn't count as Google pushing it then. It is officially "not ready to use", it isn't a strawman as people keep complaining about nothing.
        9rx 1y ago
        Kubernetes is written in Go (-ish. More like written in Java using Go syntax, especially in its early days when you claim it did some kind of pushing). But what kind of push are you dreaming up that it offered? If anything, Kubernetes leaves you to question if you ever want to write software again. The idea that it made anyone, let alone legions of people required to make something a "success", think "This is great. I should write my program in Go too!" is laughable.
- Animats 1y ago
  The strength of Go is not the language. It's that the libraries you need for web back-end stuff are written, maintained, and used in production by Google. All the obscure cases get exercised in production due to sheer volume of internal usage. At one time, Go maps were not thread-safe. Was that fixed?
  - Yoric 1y ago
    I'd be surprised if the JSON module was used within Google, though. It's neither particularly fast nor particularly convenient nor particularly suited to properly handle edge cases. But it's still in the stdlib for compatibility reasons.
    - deleted 1y ago
      [deleted]
  - 9rx 1y ago
    > At one time, Go maps were not thread-safe. Was that fixed? sync.Map was added, but isn't intended to be a general purpose map. —— The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content. The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.
  - pjmlp 1y ago
    Exactly, by Google.
- tsimionescu 1y ago
  I don't think that's the (only) reason Go became popular. The huge thing about Go is the runtime: it's the only language runtime available today, at least in any language with a large org behind it, that offers (a) GC, (b) fast start-up time, (c) static types, (d) fast execution, and (e) multi-threading. This is a killer combination for any team looking to write code for auto-scalable microservices, to run for example on Kubernetes. Java is not great in this niche because of its slow startup time, relatively large memory overhead, and the need for warm-up before code actually starts executing fast (so scaling up and down has a very large cost for Java services). .NET has similar problems, and also a huge container size. Python is far too slow, and not typed. TypeScript is single threaded, and still has a pretty hefty runtime. OCaml doesn't have any large org behind it, is quite obscure syntax, and was still single-threaded at the time Kubernetes started. Haskell has similar issues, and is also large and slow starting. Rust, C++, C all require manual memory management. So, it's no surprise that Go was used for Kubernetes services themselves, and it's no surprise that people designing for Kubernetes mostly chose to write their new stuff in Go. Go the language, with its antiquated design, is actually quite secondary to all of that. But Go's runtime is completely unmatched in this space.
  - dev_l1x_be 1y ago
    F# does that too. > .NET has similar problems s/has/had/ https://blog.washi.dev/posts/tinysharp/ https://blog.washi.dev/posts/tinysharp/ The issue is that some people still fighting against the concepts ML family languages (primarily SML) introduced. Go implemented go routines and channels from CSP (https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce...) but dragged a lot on influence from C (understandable) into the language. I think Rust opted for the best combinations (some CSP, a lot of ML and a bit of C++).
    - tsimionescu 1y ago
      Not sure what you mean about F# - being a CLR language, it has the same runtime issues as C# (and IronPython, managed C++, etc). The article you quote is a toy example - if you write a C# or F# web API server, you'll see that it takes up way more space than a Go one with similar functionality (and has way higher memory overhead as well). A Go API web server is maybe 10MB on disk, with no dependencies (that is, you can run it perfectly in a container that is defined as `FROM scratch; COPY my-go-exec /my-go-exec `). The equivalent Java or .NET container is somewhere around 2-400MB at the minimum. As for the syntax and constructs, I don't care so much. If OCaml or SML had comparable support and a comparable ecosystem to Go, I'd bet plenty of people would have chosen them instead.
Yoric 1y ago
Well, that and the slight fact that it bears Google's brand name. I personally appreciate Go as a research experiment. Plenty of very interesting ideas, just as, for instance, Haskell. I don't particularly like it as a development language, but I can understand why some people do.
- 9rx 1y ago
  > Plenty of very interesting ideas Is there? When you get down to it, it is really just a faster Python. Which is exactly what it was said to be when it was released. Their goal was to create a "dynamically-typed" language that was more performant. It is likely that it wouldn't have had a static type system at all if they figured out how to achieve on the performance end without needing types. You can tell who is clueless when you hear someone say its type system is lacking. I mean, technically it is, but it is supposed to be. Like saying Javascript or Ruby's type system is lacking.
  - Yoric 1y ago
    Two examples of interesting ideas: - using zero values as an optimization mechanism; - (non-)pointers and passing self by copy. I mean, I hate both mechanisms, but intellectually, I find them quite interesting. Also, I'd not classify it as a faster Python. It's more of a cousin of Obj-C if the authors of Obj-C had fallen in love of Erlang instead of Smalltalk.
    - bombela 1y ago
      Those ideas where already present in C/C++ decades prior. BSS program area. And passing struct by value vs pointer.
  - pjmlp 1y ago
    Faster Python with a very small set of its capabilities.
stouset 1y ago
Having the weight of Google behind it is the primary reason it didn't end up on the pile of obscure languages nobody uses.
- deleted 1y ago
  [deleted]
- 9rx 1y ago
  Oh...? Dart never gained much steam. And let's not forget about Carbon! Can you name even just one person who has tried Carbon? Have more than a handful of people even heard of Carbon? I will grant you that Carbon is still in its infancy, but when Rust was in the same youthful stage we never heard an end to all the people playing with it. You, even if not tried it yourself, definitely knew about it. You've made up a fun idea, but reality doesn't support it. Google has not shown its weight carries anything. They have really struggled to get any for-profit business units off the ground since they gained the weight, never mind their hobbies! If anything, Google is detrimental to a project.
  - pjmlp 1y ago
    Already explained in another thread, learn the politics of Dart, and Carbon is still on the drawing board.
    - 9rx 1y ago
      Already...? Said "explanation" was posted over an hour after the comment replied to here. If only Google put their weight into a watch, maybe you'd have one? Oh wait. They did! Google can't successfully turn their weight into much of anything. Go's success, if we can call it that, clearly happened in spite of Google.
      - stouset 1y ago
        Googlers aren’t expected to wear a Google-branded watch at work. They are expected to write go. Having an entire Google’s worth of programmers using your programming language isn’t exactly a minor influence.

by 9rx 1y ago

pjmlp 1y ago

The only reason it didn't end on pile of obscure languages nobody uses, it called Google, followed by luck with Docker and Kubernetes adoption on the market, after they decided to rewrite from Python and Java respectively into Go, after Go heads joined their teams. Case in point, Limbo and Oberon-2, the languages that influenced its design, and authors were involved with.

9rx 1y ago
> The only reason it didn't end on pile of obscure languages nobody uses, it called Google Dart ended up on the pile of languages nobody uses. And Carbon? What's Carbon? Exactly! > Case in point, Limbo and Oberon-2, the languages that influenced its design Agreed. Limbo and Oberon-2, as primitive as they may look now, had the kitchen sinks of their time. Why wouldn't they have ended up on the pile of languages nobody uses?
- pjmlp 1y ago
  People love to bring those as counter examples, without actually knowing a single fact about them. Dart was a victim of internal politics between the Chrome team, Dart team, AdWords moving away from GWT wanting AngularDart (see Angular documentary), and the Web in general. Had Chrome team kept pushing DartVM, it might have been quite different story. Carbon, good example of failure to actually know what the team purposes are. It is officially a research project for Google themselves, where the team is the first to advise using Rust or another MSL. One just needs to actually spend like a couple of minutes on their wiki, but I guess that is asking too much on modern times. Limbo and Oberon-2 were definitely not kitchen sinks of their time, their failure was that neither Bell Labs in 1996, nor ETHZ in 1992, were that relevant for the programming language community in the industry.
  - 9rx 1y ago
    > Had Chrome team kept pushing DartVM, it might have been quite different story. Trouble with that line of thinking is that Google never pushed Go either. It didn't even bother to use it internally (outside from the occasional side project here and there). Google paid some salaries. I'll give you that. But it has paid salaries for a lot of different languages. That is not some kind of secret sauce. > It is officially a research project for Google themselves It's not just a research project. It is officially "not ready for use", but its roadmap has a clear "ready for use" plan in the coming months. Rust was also "not ready for use" when it hit the streets, it officially being a Mozilla research project, but every second discussion on HN was about it and what is to come. And that was without Google backing. If what you say is true, why isn't Carbon being shouted from every rooftop right now? I know you're struggling to grasp at straws here, but let's just be honest for a moment: If it hasn't caught attention already, it isn't going to. Just another language to add to the pile.
    - pjmlp 1y ago
      I guess Kubernetes doesn't count as Google pushing it then. It is officially "not ready to use", it isn't a strawman as people keep complaining about nothing.
      - 9rx 1y ago
        Kubernetes is written in Go (-ish. More like written in Java using Go syntax, especially in its early days when you claim it did some kind of pushing). But what kind of push are you dreaming up that it offered? If anything, Kubernetes leaves you to question if you ever want to write software again. The idea that it made anyone, let alone legions of people required to make something a "success", think "This is great. I should write my program in Go too!" is laughable.
Animats 1y ago
The strength of Go is not the language. It's that the libraries you need for web back-end stuff are written, maintained, and used in production by Google. All the obscure cases get exercised in production due to sheer volume of internal usage. At one time, Go maps were not thread-safe. Was that fixed?
- Yoric 1y ago
  I'd be surprised if the JSON module was used within Google, though. It's neither particularly fast nor particularly convenient nor particularly suited to properly handle edge cases. But it's still in the stdlib for compatibility reasons.
  - deleted 1y ago
    [deleted]
- 9rx 1y ago
  > At one time, Go maps were not thread-safe. Was that fixed? sync.Map was added, but isn't intended to be a general purpose map. —— The Map type is specialized. Most code should use a plain Go map instead, with separate locking or coordination, for better type safety and to make it easier to maintain other invariants along with the map content. The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.
- pjmlp 1y ago
  Exactly, by Google.
tsimionescu 1y ago
I don't think that's the (only) reason Go became popular. The huge thing about Go is the runtime: it's the only language runtime available today, at least in any language with a large org behind it, that offers (a) GC, (b) fast start-up time, (c) static types, (d) fast execution, and (e) multi-threading. This is a killer combination for any team looking to write code for auto-scalable microservices, to run for example on Kubernetes. Java is not great in this niche because of its slow startup time, relatively large memory overhead, and the need for warm-up before code actually starts executing fast (so scaling up and down has a very large cost for Java services). .NET has similar problems, and also a huge container size. Python is far too slow, and not typed. TypeScript is single threaded, and still has a pretty hefty runtime. OCaml doesn't have any large org behind it, is quite obscure syntax, and was still single-threaded at the time Kubernetes started. Haskell has similar issues, and is also large and slow starting. Rust, C++, C all require manual memory management. So, it's no surprise that Go was used for Kubernetes services themselves, and it's no surprise that people designing for Kubernetes mostly chose to write their new stuff in Go. Go the language, with its antiquated design, is actually quite secondary to all of that. But Go's runtime is completely unmatched in this space.
- dev_l1x_be 1y ago
  F# does that too. > .NET has similar problems s/has/had/ https://blog.washi.dev/posts/tinysharp/ https://blog.washi.dev/posts/tinysharp/ The issue is that some people still fighting against the concepts ML family languages (primarily SML) introduced. Go implemented go routines and channels from CSP (https://en.wikipedia.org/wiki/Communicating_sequential_processes https://en.wikipedia.org/wiki/Communicating_sequential_proce...) but dragged a lot on influence from C (understandable) into the language. I think Rust opted for the best combinations (some CSP, a lot of ML and a bit of C++).
  - tsimionescu 1y ago
    Not sure what you mean about F# - being a CLR language, it has the same runtime issues as C# (and IronPython, managed C++, etc). The article you quote is a toy example - if you write a C# or F# web API server, you'll see that it takes up way more space than a Go one with similar functionality (and has way higher memory overhead as well). A Go API web server is maybe 10MB on disk, with no dependencies (that is, you can run it perfectly in a container that is defined as `FROM scratch; COPY my-go-exec /my-go-exec `). The equivalent Java or .NET container is somewhere around 2-400MB at the minimum. As for the syntax and constructs, I don't care so much. If OCaml or SML had comparable support and a comparable ecosystem to Go, I'd bet plenty of people would have chosen them instead.

Yoric 1y ago

Well, that and the slight fact that it bears Google's brand name. I personally appreciate Go as a research experiment. Plenty of very interesting ideas, just as, for instance, Haskell. I don't particularly like it as a development language, but I can understand why some people do.

9rx 1y ago
> Plenty of very interesting ideas Is there? When you get down to it, it is really just a faster Python. Which is exactly what it was said to be when it was released. Their goal was to create a "dynamically-typed" language that was more performant. It is likely that it wouldn't have had a static type system at all if they figured out how to achieve on the performance end without needing types. You can tell who is clueless when you hear someone say its type system is lacking. I mean, technically it is, but it is supposed to be. Like saying Javascript or Ruby's type system is lacking.
- Yoric 1y ago
  Two examples of interesting ideas: - using zero values as an optimization mechanism; - (non-)pointers and passing self by copy. I mean, I hate both mechanisms, but intellectually, I find them quite interesting. Also, I'd not classify it as a faster Python. It's more of a cousin of Obj-C if the authors of Obj-C had fallen in love of Erlang instead of Smalltalk.
  - bombela 1y ago
    Those ideas where already present in C/C++ decades prior. BSS program area. And passing struct by value vs pointer.
- pjmlp 1y ago
  Faster Python with a very small set of its capabilities.

stouset 1y ago

Having the weight of Google behind it is the primary reason it didn't end up on the pile of obscure languages nobody uses.

deleted 1y ago
[deleted]
9rx 1y ago
Oh...? Dart never gained much steam. And let's not forget about Carbon! Can you name even just one person who has tried Carbon? Have more than a handful of people even heard of Carbon? I will grant you that Carbon is still in its infancy, but when Rust was in the same youthful stage we never heard an end to all the people playing with it. You, even if not tried it yourself, definitely knew about it. You've made up a fun idea, but reality doesn't support it. Google has not shown its weight carries anything. They have really struggled to get any for-profit business units off the ground since they gained the weight, never mind their hobbies! If anything, Google is detrimental to a project.
- pjmlp 1y ago
  Already explained in another thread, learn the politics of Dart, and Carbon is still on the drawing board.
  - 9rx 1y ago
    Already...? Said "explanation" was posted over an hour after the comment replied to here. If only Google put their weight into a watch, maybe you'd have one? Oh wait. They did! Google can't successfully turn their weight into much of anything. Go's success, if we can call it that, clearly happened in spite of Google.
    - stouset 1y ago
      Googlers aren’t expected to wear a Google-branded watch at work. They are expected to write go. Having an entire Google’s worth of programmers using your programming language isn’t exactly a minor influence.