7 ms·

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster i

I know they say that your programming language isn't the bottleneck, but I remember sitting there being frustrated as a young dev that I couldn't parse faster in the languages I was using when I learned about Go. It took a few more years before I actually got around to learning it and I have to say I've never picked up a language so quickly. (Which makes sense, it's got the smallest language spec of any of them) I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort.

tialaramex 11mo ago
> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort. I don't see it. Can you say what 80% you feel like you're getting? The type system doesn't feel anything alike, I guess the syntax is alike in the sense that Go is a semi-colon language and Rust though actually basically an ML deliberately dresses as a semi-colon language but otherwise not really. They're both relatively modern, so you get decent tooling out of the box. But this feels a bit like if somebody told me that this new pizza restaurant does a cheese pizza that's 80% similar to the Duck Ho Fun from that little place near the extremely tacky student bar. Duck Ho Fun doesn't have nothing in common with cheese pizza, they're both best (in my opinion) if cooked very quickly with high heat - but there's not a lot of commonality.
- klodolph 11mo ago
  > I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performance.
  - Xeoncross 11mo ago
    Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contained stdlib/test suite/package manger/formatter/etc.. with Go.
    - neonsunset 11mo ago
      [dead]
    - echelon 11mo ago
      Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result<T,E>, Option<T>, match, if let, functional predicates, mapping, `?`, etc. Go, on the other hand, has nil and extremely exhausting boilerplate error checking. Honestly, Go has been one of my worst languages outside of Python, Ruby, and JavaScript for error introduction. It's a total pain in the ass to handle errors and exceptional behavior. And this leads to making mistakes and stupid gotchas. I'm so glad newer languages are picking up on and copying Rust's design choices from day one. It's a godsend to be done with null and exceptions. I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile like Go, but designed in a safe way like Rust. I need it for my smaller tasks and scripting. Swift is kind of nice, but it's too Apple centric and hard to use outside of Apple platforms. I'm honestly totally content to keep using Rust in a wife variety of problem domains. It's an S-tier language.
      - nine_k 11mo ago
        > I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile It could as well be Haskell :) Only partly a joke: https://zignar.net/2021/07/09/why-haskell-became-my-favorite-scripting-language/ https://zignar.net/2021/07/09/why-haskell-became-my-favorite...
- deleted 11mo ago
  [deleted]
- password4321 11mo ago
  Single binary deployment was a big deal when Go was young; that might be worth a few percent. Also: automatically avoiding entire categories of potential vulnerabilities due to language-level design choices and features. Not compile times though ;)
- torben-friis 11mo ago
  Wild guess but, with the current JS/python dominance, maybe it’s just the benefits of a (modern) compiled language.
- NoboruWataya 11mo ago
  I guess the 80% would be a reasonably performant compiled binary with easily managed dependencies? And the extra 20% would be the additional performance and peace of mind provided by the strictness of the Rust compiler.
morshu9001 11mo ago
Language can be bottleneck if there's something huge missing from it that you need, like how many of them didn't have first class support for cooperative multitasking, or maybe you need it to be compiled, or not compiled, or GC vs no GC. Go started out with solid greenthreading, while afaik no major lang/runtime had something comparable at the time (Java now does supposedly). The thing people tend to overvalue is the little syntax differences, like how Scala wanted to be a nicer Java, or even ObjC vs Swift before the latter got async/await.
- ezst 11mo ago
  I'll be the one to nickpick, but Scala never intended to be a nicer Java. It was and still is an academic exercise in compiler and language theory. Also, judging by Kotlin's decent strides, "little Syntex differences" get you a long way on a competent VM/Runtime/stdlib.
  - morshu9001 11mo ago
    Kotlin's important feature is the cooperative multitasking. Java code has been mangled all these years to work around not having that. I don't think many would justify the switch to Kotlin otherwise.
    - ezst 11mo ago
      It's probably an important feature now, but it's a recent one in this context.
      - morshu9001 11mo ago
        Oh true, I thought it was older
roncesvalles 11mo ago
The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "partial method" or "generic delegate" means, and then keep reading that codebase if you still have momentum left.
- morshu9001 11mo ago
  This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.
  - jchw 11mo ago
    Just so we're on the same page, this is the current JS spec: https://262.ecma-international.org/16.0/index.html https://262.ecma-international.org/16.0/index.html I don't agree. (And frankly don't like using JS without at least TypeScript.)
    - goranmoomin 11mo ago
      While I might not think that JS is a good language (for some definition of a good language), to me the provided spec does feel pretty small, considering that it's a language that has to be specified to the dot and that the spec contains the standard library as well. It has some strange or weirdly specified features (ASI? HTML-like Comments?) and unusual features (prototype-based inheritance? a dynamically-bounded this?), but IMO it's a small language.
      - jchw 11mo ago
        Shrugging it off as just being large because it contains the "standard library" ignores that many JS language features necessarily use native objects like symbols or promises, which can't be entirely implemented in just JavaScript alone, so they are intrinsic rather than being standard library components, akin to Go builtins rather than the standard library. In fact, in actual environments, the browser and/or Node.JS provide the actual standard library, including things like fetch, sockets, compression codecs, etc. Even ignoring almost all of those bits though, the spec is absolutely enormous, because JavaScript has: - Regular expressions - not just in the "standard library" but in the syntax. - An entire module system with granular imports and exports - Three different ways to declare variables, two of which create temporal dead zones - Classes with inheritance, including private properties - Dynamic properties (getters and setters) - Exception handling - Two different types of closures/first class functions, with different binding rules - Async/await - Variable length "bigint" integers - Template strings - Tagged template literals - Sparse arrays - for in/for of/iterators - for await/async iterators - The with statement - Runtime reflection - Labeled statements - A lot of operators, including bitwise operators and two sets of equality operators with different semantics - Runtime code evaluation with eval/Function constructor And honestly it's only scratching the surface, especially of modern ECMAScript. A language spec is necessarily long. The JS language spec, though, is so catastrophically long that it is a bit hard to load on a low end machine or a mobile web browser. It's on another planet.
tptacek 11mo ago
I don't understand the framing you have here, of Rust being an asymptote of language capability. It isn't. It's its own set of tradeoffs. In 2025, it would not make much sense to write a browser in Go. But there are a lot of network services it doesn't really make sense to write in Rust: you give up a lot (colored functions, the borrow checker) to avoid GC and goroutines. Rust is great. One of the stupidest things in modern programming practice is the slapfight between these two language communities.
zer00eyz 11mo ago
I write a lot of Go, a bit of Rust, and Zig is slowly creeping in. To add to the above comment, a lot of what Go does encourages readability... Yes it feels pedantic at moments (error handling), but those cultural, and stylistic elements that seem painful to write make reading better. Portable binaries are a blessing, fast compile times, and the choices made around 3rd party libraries and vendoring are all just icing on the cake. That 80 percent feeling is more than just the language, as written, its all the things that come along with it...
- cwbriscoe 11mo ago
  Error handling isn't even a pain to write any more with AI autocomplete which gets it right 95%+ of the time in my experience.
  - zer00eyz 11mo ago
    You're not wrong but... there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. I keep using the analogy, that the tools are just nail guns for office workers but some people remain sticks in the mud.
    - 9rx 11mo ago
      > there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. This Go community that you speak of isn't bothered by writing the boilerplate themselves in the first place, though. For everyone else the LLMs provide.
    - bccdee 11mo ago
      Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. For non-trivial tasks, AI is neither of those. Anything you do with AI needs to be carefully reviewed to correct hallucinations and incorporate it into your mental model of the codebase. You point, you shoot, and that's just the first 10-20% of the effort you need to move past this piece of code. Some people like this tradeoff, and fair enough, but that's nothing like a nailgun. For trivial tasks, AI is barely worth the effort of prompting. If I really hated typing `if err != nil { return nil, fmt.Errorf("doing x: %w", err) }` so much, I'd make it an editor snippet or macro.
throw1111221 11mo ago
Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduce build times at Google. This is why unused dependencies are a compile time error. https://go.dev/talks/2012/splash.article#TOC_6 https://go.dev/talks/2012/splash.article#TOC_6.
- pkaye 11mo ago
  Doesn't Google use mostly C++?
  - throw1111221 11mo ago
    Just because it was a design goal doesn't mean it succeeded ;) From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby." https://research.swtch.com/gotour https://research.swtch.com/gotour
    - Measter 11mo ago
      It's interesting that I've also heard the same from people involved in Rust. Expecting more interest from C++ programmers and being surprised by the numbers of Ruby/Python programmers interested. I wonder if it's that Ruby/Python programmers were interested in using these kinds of languages but were being pushed away by C/C++.
      - estebank 11mo ago
        The people writing C++ either don't need much convincing to switch because they see the value or are unlikely to give it up anytime soon because they don't see anything Rust does as being useful to them, very little middle ground. People from higher level languages on the other hand see in Rust a way to break into a space that they would otherwise not attempt because it would take too long a time to reach proficiency. The hard part of Rust is trying to simultaneously have hard to misuse APIs and no additional performance penalty (however small). If you relax either of those goals (is it really a problem if you call that method through a v-table?), then Rust becomes much easier to write. I think GC Rust would already be a nice language to use that I'd love, like a less convoluted Scala, it just wouldn't have fit in a free square that ensured a niche for it to exist and grow, and would likely have died in the vine.
throwaway894345 11mo ago
Similar story for me. I was looking for a language that just got out of the way. That didn’t require me to learn a full imparable DSL just to add a few dependencies and which could easily produce some artifact that I could share around without needing to make sure the target machine had all the right dependencies installed.
throw-the-towel 11mo ago
Unfortunately, it's the remaining 20% of Rust features that provide 80% of its usefulness.
osigurdson 11mo ago
>> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort. By 20% of the effort, do you mean learning curve or productivity?
Someone 11mo ago
> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/aboutthelanguagereference/ https://docs.swift.org/swift-book/documentation/the-swift-pr...: “The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler.”) (Also, browsing golang’s spec, I think I spotted an error in https://go.dev/ref/spec#Integer_literals https://go.dev/ref/spec#Integer_literals. The grammar says: decimal_lit = "0" | ( "1" … "9" ) [ [ "_" ] decimal_digits ] . Given that, how can 0600 and 0_600 be valid integer literals in the examples?)
- neild 11mo ago
  0600 and 0_600 are octal literals: octal_lit = "0" [ "o" | "O" ] [ "_" ] octal_digits .
  - j-scott 11mo ago
    Never mind, I was wrong. Here’s a playground showing how go parses each one: https://go.dev/play/p/hyWPkL_9C5W https://go.dev/play/p/hyWPkL_9C5W
    - mseepgood 11mo ago
      > Octals must start with zero and then o/O literals. No, the o/O is optional (hence in square brackets), only the leading zero is required. All of these are valid octal literals in Go: 0600 (zero six zero zero) 0_600 (zero underscore six zero zero) 0o600 (zero lower-case-letter-o six zero zero) 0O600 (zero upper-case-letter-o six zero zero)
      - j-scott 11mo ago
        My bad! I was wrong; added a playground demonstration the parsing behavior above.
baby 11mo ago
It really is a lovely language and ecosystem of tools, I think it does show its limitations fairly quickly when you want to build something a bit complex though. Really wish they would have added sumtypes
Thorrez 11mo ago
Go is getting more complex over time though. E.g. generics.
benjiro 11mo ago
Funny thing is that also makes it easier on LLM / AI... Tried a project a while ago both creating the same thing in Rust and Go. Go's worked from the start, while Rust's version needed a lot of LLM interventions and fixes to get it to compile. We shall not talk about compile time / resource usage differences ;) I mean, Rust is nice, but compared to when i learned it like 10 years ago, it really looks a lot more these days, like it took too much of a que from C++. While Go syntax is still the same as it was 10 years ago with barely anything new. What may anger people but even so... The only thing i love to see is reduce executable sizes because pushing large executables on a dinky upload line, to remove testing is not fun.

tialaramex 11mo ago

> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort. I don't see it. Can you say what 80% you feel like you're getting? The type system doesn't feel anything alike, I guess the syntax is alike in the sense that Go is a semi-colon language and Rust though actually basically an ML deliberately dresses as a semi-colon language but otherwise not really. They're both relatively modern, so you get decent tooling out of the box. But this feels a bit like if somebody told me that this new pizza restaurant does a cheese pizza that's 80% similar to the Duck Ho Fun from that little place near the extremely tacky student bar. Duck Ho Fun doesn't have nothing in common with cheese pizza, they're both best (in my opinion) if cooked very quickly with high heat - but there's not a lot of commonality.

klodolph 11mo ago
> I don't see it. Can you say what 80% you feel like you're getting? I read it as “80% of the way to Rust levels of reliability and performance.” That doesn’t mean that the type system or syntax is at all similar, but that you get some of the same benefits. I might say that, “C gets you 80% of the way to assembly with 20% of the effort.” From context, you could make a reasonable guess that I’m talking about performance.
- Xeoncross 11mo ago
  Yes, for me I've always pushed the limits of what kinds of memory and cpu usage I can get out of languages. NLP, text conversion, video encoding, image rendering, etc... Rust beats Go in performance.. but nothing like how far behind Java, C#, or scripting languages (python, ruby, typescript, etc..) are from all the work I've done with them. I get most of the performance of Rust with very little effort a fully contained stdlib/test suite/package manger/formatter/etc.. with Go.
  - neonsunset 11mo ago
    [dead]
  - echelon 11mo ago
    Rust is the most defect free language I have ever had the pleasure of working with. It's a language where you can almost be certain that if it compiles and if you wrote tests, you'll have no runtime bugs. I can only think of two production bugs I've written in Rust this year. Minor bugs. And I write a lot of Rust. The language has very intentional design around error handling: Result<T,E>, Option<T>, match, if let, functional predicates, mapping, `?`, etc. Go, on the other hand, has nil and extremely exhausting boilerplate error checking. Honestly, Go has been one of my worst languages outside of Python, Ruby, and JavaScript for error introduction. It's a total pain in the ass to handle errors and exceptional behavior. And this leads to making mistakes and stupid gotchas. I'm so glad newer languages are picking up on and copying Rust's design choices from day one. It's a godsend to be done with null and exceptions. I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile like Go, but designed in a safe way like Rust. I need it for my smaller tasks and scripting. Swift is kind of nice, but it's too Apple centric and hard to use outside of Apple platforms. I'm honestly totally content to keep using Rust in a wife variety of problem domains. It's an S-tier language.
    - nine_k 11mo ago
      > I really want a fast, memory managed, statically typed scripting language somewhere between Rust and Go that's fast to compile It could as well be Haskell :) Only partly a joke: https://zignar.net/2021/07/09/why-haskell-became-my-favorite-scripting-language/ https://zignar.net/2021/07/09/why-haskell-became-my-favorite...
deleted 11mo ago
[deleted]
password4321 11mo ago
Single binary deployment was a big deal when Go was young; that might be worth a few percent. Also: automatically avoiding entire categories of potential vulnerabilities due to language-level design choices and features. Not compile times though ;)
torben-friis 11mo ago
Wild guess but, with the current JS/python dominance, maybe it’s just the benefits of a (modern) compiled language.
NoboruWataya 11mo ago
I guess the 80% would be a reasonably performant compiled binary with easily managed dependencies? And the extra 20% would be the additional performance and peace of mind provided by the strictness of the Rust compiler.

morshu9001 11mo ago

Language can be bottleneck if there's something huge missing from it that you need, like how many of them didn't have first class support for cooperative multitasking, or maybe you need it to be compiled, or not compiled, or GC vs no GC. Go started out with solid greenthreading, while afaik no major lang/runtime had something comparable at the time (Java now does supposedly). The thing people tend to overvalue is the little syntax differences, like how Scala wanted to be a nicer Java, or even ObjC vs Swift before the latter got async/await.

ezst 11mo ago
I'll be the one to nickpick, but Scala never intended to be a nicer Java. It was and still is an academic exercise in compiler and language theory. Also, judging by Kotlin's decent strides, "little Syntex differences" get you a long way on a competent VM/Runtime/stdlib.
- morshu9001 11mo ago
  Kotlin's important feature is the cooperative multitasking. Java code has been mangled all these years to work around not having that. I don't think many would justify the switch to Kotlin otherwise.
  - ezst 11mo ago
    It's probably an important feature now, but it's a recent one in this context.
    - morshu9001 11mo ago
      Oh true, I thought it was older

roncesvalles 11mo ago

The nice thing about Go is that you can learn "all of it" in a reasonable amount of time: gotchas, concurrency stuff, everything. There is something very comforting about knowing the entire spec of a language. I'm convinced no more than a handful of humans understand all of C# or C++, and inevitably you'll come across some obscure thing and have to context switch out of reading code to learn whatever the fuck a "partial method" or "generic delegate" means, and then keep reading that codebase if you still have momentum left.

morshu9001 11mo ago
This is also what I like about JS, except it's even easier than Go. Meanwhile Python has a surprising number of random features.
- jchw 11mo ago
  Just so we're on the same page, this is the current JS spec: https://262.ecma-international.org/16.0/index.html https://262.ecma-international.org/16.0/index.html I don't agree. (And frankly don't like using JS without at least TypeScript.)
  - goranmoomin 11mo ago
    While I might not think that JS is a good language (for some definition of a good language), to me the provided spec does feel pretty small, considering that it's a language that has to be specified to the dot and that the spec contains the standard library as well. It has some strange or weirdly specified features (ASI? HTML-like Comments?) and unusual features (prototype-based inheritance? a dynamically-bounded this?), but IMO it's a small language.
    - jchw 11mo ago
      Shrugging it off as just being large because it contains the "standard library" ignores that many JS language features necessarily use native objects like symbols or promises, which can't be entirely implemented in just JavaScript alone, so they are intrinsic rather than being standard library components, akin to Go builtins rather than the standard library. In fact, in actual environments, the browser and/or Node.JS provide the actual standard library, including things like fetch, sockets, compression codecs, etc. Even ignoring almost all of those bits though, the spec is absolutely enormous, because JavaScript has: - Regular expressions - not just in the "standard library" but in the syntax. - An entire module system with granular imports and exports - Three different ways to declare variables, two of which create temporal dead zones - Classes with inheritance, including private properties - Dynamic properties (getters and setters) - Exception handling - Two different types of closures/first class functions, with different binding rules - Async/await - Variable length "bigint" integers - Template strings - Tagged template literals - Sparse arrays - for in/for of/iterators - for await/async iterators - The with statement - Runtime reflection - Labeled statements - A lot of operators, including bitwise operators and two sets of equality operators with different semantics - Runtime code evaluation with eval/Function constructor And honestly it's only scratching the surface, especially of modern ECMAScript. A language spec is necessarily long. The JS language spec, though, is so catastrophically long that it is a bit hard to load on a low end machine or a mobile web browser. It's on another planet.

tptacek 11mo ago

I don't understand the framing you have here, of Rust being an asymptote of language capability. It isn't. It's its own set of tradeoffs. In 2025, it would not make much sense to write a browser in Go. But there are a lot of network services it doesn't really make sense to write in Rust: you give up a lot (colored functions, the borrow checker) to avoid GC and goroutines. Rust is great. One of the stupidest things in modern programming practice is the slapfight between these two language communities.

zer00eyz 11mo ago

I write a lot of Go, a bit of Rust, and Zig is slowly creeping in. To add to the above comment, a lot of what Go does encourages readability... Yes it feels pedantic at moments (error handling), but those cultural, and stylistic elements that seem painful to write make reading better. Portable binaries are a blessing, fast compile times, and the choices made around 3rd party libraries and vendoring are all just icing on the cake. That 80 percent feeling is more than just the language, as written, its all the things that come along with it...

cwbriscoe 11mo ago
Error handling isn't even a pain to write any more with AI autocomplete which gets it right 95%+ of the time in my experience.
- zer00eyz 11mo ago
  You're not wrong but... there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. I keep using the analogy, that the tools are just nail guns for office workers but some people remain sticks in the mud.
  - 9rx 11mo ago
    > there is a large contingent of the Go community that has a rather strong reaction to AI/ML/LLM generated code at any level. This Go community that you speak of isn't bothered by writing the boilerplate themselves in the first place, though. For everyone else the LLMs provide.
  - bccdee 11mo ago
    Nail guns are great because they're instant and consistent. You point, you shoot, and you've unimpeachably bonded two bits of wood. For non-trivial tasks, AI is neither of those. Anything you do with AI needs to be carefully reviewed to correct hallucinations and incorporate it into your mental model of the codebase. You point, you shoot, and that's just the first 10-20% of the effort you need to move past this piece of code. Some people like this tradeoff, and fair enough, but that's nothing like a nailgun. For trivial tasks, AI is barely worth the effort of prompting. If I really hated typing `if err != nil { return nil, fmt.Errorf("doing x: %w", err) }` so much, I'd make it an editor snippet or macro.

throw1111221 11mo ago

Well that's good, since Go was specifically designed for juniors. From Rob Pike himself: "It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical." However, the main design goal was to reduce build times at Google. This is why unused dependencies are a compile time error. https://go.dev/talks/2012/splash.article#TOC_6 https://go.dev/talks/2012/splash.article#TOC_6.

pkaye 11mo ago
Doesn't Google use mostly C++?
- throw1111221 11mo ago
  Just because it was a design goal doesn't mean it succeeded ;) From Russ Cox this time: "Q. What language do you think Go is trying to displace? ... One of the surprises for me has been the variety of languages that new Go programmers used to use. When we launched, we were trying to explain Go to C++ programmers, but many of the programmers Go has attracted have come from more dynamic languages like Python or Ruby." https://research.swtch.com/gotour https://research.swtch.com/gotour
  - Measter 11mo ago
    It's interesting that I've also heard the same from people involved in Rust. Expecting more interest from C++ programmers and being surprised by the numbers of Ruby/Python programmers interested. I wonder if it's that Ruby/Python programmers were interested in using these kinds of languages but were being pushed away by C/C++.
    - estebank 11mo ago
      The people writing C++ either don't need much convincing to switch because they see the value or are unlikely to give it up anytime soon because they don't see anything Rust does as being useful to them, very little middle ground. People from higher level languages on the other hand see in Rust a way to break into a space that they would otherwise not attempt because it would take too long a time to reach proficiency. The hard part of Rust is trying to simultaneously have hard to misuse APIs and no additional performance penalty (however small). If you relax either of those goals (is it really a problem if you call that method through a v-table?), then Rust becomes much easier to write. I think GC Rust would already be a nice language to use that I'd love, like a less convoluted Scala, it just wouldn't have fit in a free square that ensured a niche for it to exist and grow, and would likely have died in the vine.

throwaway894345 11mo ago

Similar story for me. I was looking for a language that just got out of the way. That didn’t require me to learn a full imparable DSL just to add a few dependencies and which could easily produce some artifact that I could share around without needing to make sure the target machine had all the right dependencies installed.

throw-the-towel 11mo ago

Unfortunately, it's the remaining 20% of Rust features that provide 80% of its usefulness.

osigurdson 11mo ago

>> I'm sure there are plenty of reasons this is wrong, but it feels like Go gets me 80% of the way to Rust with 20% of the effort. By 20% of the effort, do you mean learning curve or productivity?

Someone 11mo ago

> Which makes sense, it's got the smallest language spec of any of them I think go is fairly small, too, but “size of spec” is not always a good measure for that. Some specs are very tight, others fairly loose, and tightness makes specs larger (example: Swift’s language reference doesn’t even claim to define the full language. https://docs.swift.org/swift-book/documentation/the-swift-programming-language/aboutthelanguagereference/ https://docs.swift.org/swift-book/documentation/the-swift-pr...: “The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler.”) (Also, browsing golang’s spec, I think I spotted an error in https://go.dev/ref/spec#Integer_literals https://go.dev/ref/spec#Integer_literals. The grammar says: decimal_lit = "0" | ( "1" … "9" ) [ [ "_" ] decimal_digits ] . Given that, how can 0600 and 0_600 be valid integer literals in the examples?)

neild 11mo ago
0600 and 0_600 are octal literals: octal_lit = "0" [ "o" | "O" ] [ "_" ] octal_digits .
- j-scott 11mo ago
  Never mind, I was wrong. Here’s a playground showing how go parses each one: https://go.dev/play/p/hyWPkL_9C5W https://go.dev/play/p/hyWPkL_9C5W
  - mseepgood 11mo ago
    > Octals must start with zero and then o/O literals. No, the o/O is optional (hence in square brackets), only the leading zero is required. All of these are valid octal literals in Go: 0600 (zero six zero zero) 0_600 (zero underscore six zero zero) 0o600 (zero lower-case-letter-o six zero zero) 0O600 (zero upper-case-letter-o six zero zero)
    - j-scott 11mo ago
      My bad! I was wrong; added a playground demonstration the parsing behavior above.

baby 11mo ago

It really is a lovely language and ecosystem of tools, I think it does show its limitations fairly quickly when you want to build something a bit complex though. Really wish they would have added sumtypes

Thorrez 11mo ago

Go is getting more complex over time though. E.g. generics.

benjiro 11mo ago

Funny thing is that also makes it easier on LLM / AI... Tried a project a while ago both creating the same thing in Rust and Go. Go's worked from the start, while Rust's version needed a lot of LLM interventions and fixes to get it to compile. We shall not talk about compile time / resource usage differences ;) I mean, Rust is nice, but compared to when i learned it like 10 years ago, it really looks a lot more these days, like it took too much of a que from C++. While Go syntax is still the same as it was 10 years ago with barely anything new. What may anger people but even so... The only thing i love to see is reduce executable sizes because pushing large executables on a dinky upload line, to remove testing is not fun.