I'm Coming Around To Go...

[@Thenderick]

Like a certain other programming youtuber once said: "GO MENTIONED!"

[@Vladythebest96]

LESGO!

[@jenwans3055]

"FIIIIIVVVEEE DOLLARS A MONTH"

[@vatsalyavigyaverma5494]

Primeagen

[@TheKastellan]

"Welcome to Cosco"

[@axMf3qTI]

Lua will always be the real party starter.

[@chepossofare]

TBH the real strong points of Go are: - single static binary (the EASIEST for deploy) - simple language (few keywords) - cross compiling is as easy as set GOOS and GOARCH - Pretty decent performances (not the best, not the worst) - MOST of the stdlib has consistent behavior - MOST of the 3rd party packages have consistent behavior - Simple and effective package manager - Perfect fit for backend services, literally, it is perfect - Absolutely perfect retrocompatibility (Rust, Python and TS haven't guaranteed it even with minor or patch version) About dev velocity: i have spent a lot of time time dealing with TS, npm errors and stuff. By that time, i finished two services in Go. That's subjective, but a consistent ecosystem is a great value to me.

[@chepossofare]

PS: esbuild is not going to solve the compilation problem, since the DX is slowed down by the TSC which is slow AF. Esbuild transpiles without type checking.

[@d3stinYwOw]

Rust also can build static single binary, but takes 10x more time, plus needs relying on muslc, which is not as loved as glibc in linux space :)

[@muhwyndham]

the single static binary is a killer feature that is underrated. currently working on something interesting where we're trying to tackle the "better than WordPress" problem where WP is so easy to install that non-tech can reasonably deploy their own instance of WordPress. Go is the strongest candidate as it compiles into a single portable binary, but it can also carry contentful stuff (like JS files, images, and many others) in its binary. So, a Go Binary program effectively becomes runnable zip files.

[@OnFireByte]

technically they do some breaking change on the stuffs with buggy behavior (fixing, to be precise). Yes, no one should use those buggy behavior anyway, but it also mean that you can't carelessly update the project without some checking where external package might use that thing.

[@maximotejedapozo9335]

Upvoted

[@ivan.angulo]

Go was literaly our only option. We use Go with AWS Lambda and is not only about CPU performance but RAM usage, even with Bun, JIT and interpreted lanjuages like JS and Python can't handle 1M+ records in a 256mb RAM container, even Java or C# have a memory overheat due to their VM. So basicaly Go was our only alternative to cheap microservices with a good support for AWS SDK and low learning curve. Also, cross-compiling works great, since we use ARM based Lambdas, reducing the cost even further, all in just a 10 - 16 mb binary.

[@jordanstewart225]

I've heard of teams using graalvm instead of the JVM with some success

[@steveoc64]

Yep Iterate fast and prove the solution with go Then optimize with zig once proven Win

[@arobie92]

@@jordanstewart225 My experience is a few years out of date and I didn't dive super deep, so you'll probably want to double check, but Graal isn't a complete replacement from what I remember. It definitely helps with cold start times, but it's still real chunky in terms of binary. I don't remember how memory consumption compared though. I'm very much not a fan of Go, but for lambdas it's 100% the choice I'd go with since anything else that hits all of thee pros Go has doesn't have anywhere near the same market share. Which now that I think of it is kind of just Go in a nutshell. The one pro of Go in lambdas versus Go on a server is that since lambdas are relatively small you don't run into some of the annoyances of scaling Go codebases.

[@user72974]

@@jordanstewart225 The thing that makes me anxious about the idea of using GraalVM is... am I going to run into a situation one day where my program doesn't run on GraalVM anymore because I need to use a library that can't run on GraalVM because it uses reflection? I suppose I could just switch from GraalVM to a traditional JVM at that point, but what if I'm really relying on the small memory footprint, small binary size, or fast startup? Is that going to be feasible? Is my project going to hit a brick wall because of a compromise that's impossible for me to make? And then it needs a rewrite?

[@talonhackbarth7652]

I will say, Go has one of the best AWS SDKs of any language I've used.

[@RoyRope]

I've been programming in Go for 2 years now, and the book 100 Go mistakes and how to avoid them describes it quite fittingly from my perspective: "simple to learn but hard to master". The language constructs can be learned very easily, but learning to write solid idiomatic Go is pretty hard.On first sight the pull requests from juniors and seniors appear similar, but at my job, in a team of around 30 developers with varying experience, it is also easy to identify who has more Go experience.

[@javiasilis]

Damn. Thanks fornsharing the book. I was looking for a good reference to prevent bringing my mind from other languages to go

[@manofqwerty]

I would expect this to be the case for almost any language. What language can you pick up and write like an experienced dev? Definitely not TS and definitely not Rust.

[@RoyRope]

@@manofqwerty I have not stated anything contradicting this.

[@GoddamnAxl]

Absolutely agree. Because Go's ecosystem isn't absolutely dominated by one paradigm (think about Java's Spring, .Net for C#, React for TS/JS...), it's infinitely easier to write shit Go code than any other high level language I have worked with.

[@DeanRTaylor]

So what you're saying is, people who have more experience in the language are better? This is truly a revolutionary and unique thing about go.

[@bertangundogdu]

I see your points about type system and other choices Go made but in general I’d say Go has even greater velocity than JS/TS. My justifications are as follows: - You don’t need to worry about the tooling around your dev environment, such as prettier, test runner, package manager, etc. because all of them come with the language. - The language itself is really small and one can learn all of it in one day. It’s even possible to read the whole specification doing that. - If you use something like htmx, then you can even get away with not touching any JS. - The one way of doing things is especially important when you want to read an open source project’s code. Also, the community mostly shares the simplicity mentality, so projects are mostly higher quality and easy to pick up. So, in my mind, the Go streches to the end of the velocity spectrum and they are exploring if they can also stretch to the perf end of it. The hesitation is mostly around not messing the dev velocity/ simplicity part.

[@xbmarx]

Compilation speed does matter. I worked on a team that used Go, and I could push to a dev branch and it tested, built, and deployed to the dev environment before I could bring up the CICD page lmao.

[@ijazkhan3335]

I started with GO last year and came to love it so much. It is so easy if you are already familiar with another language. For web apps, I would recommend building some boilerplate and keeping it as a repo that you can pull whenever you want to start a new app. The biggest plus point is how simple it is to set up a Go project, there is no complexity behind the scenes and things can be managed with ease because you control almost everything about your application.

[@dhammi]

exactly !. That what I don't like langues like java. it hides so much with magic and anything goes out of the boilerplate java way , good luck fixing that .

[@ttdat89]

I heard people say Go is Node on steroid, is it correct?

[@ijazkhan3335]

@@ttdat89 there is some sense to it if you are starting a node web project from scratch using express and installing several third party packages to get things going. You might as well spend the same amount of time building a Go project.

[@ijazkhan3335]

@@ttdat89 but yeah if you know node then learning golang isn't a going to be a big deal. You are already familiar with fundamentals of any project and you only need to learn how to do things golang way

[@merc.5802]

can you tell me some other stuff that can be build with go?

[@BogdanTheGeek]

I think you hit the nail on the head with "Writing Go doesn't make me feel clever." This is IMO why so few people contribute to Go projects, there is nothing to learn. Go is the perfect language to just get shit done. Its the Toyota Corolla of programming languages. Sure, some people turbo and race their Corollas, but most people just go from A to B and couldn't care less. PS: This is why I like Go so much. C++ and JS show the personality of the lead programmer in the codebase, no 2 codebases look the same.

[@PhilipAlexanderHassialis]

Coming from an enterprise space, trust me, we *don't* want "clever" people. We want predictable results built in a predictable manner to deliver in a predictable timeframe. Go fills nicely that very important role. And yes, I 've been just checking out a bit Rust, and yes, toying around with it just a bit always made me feel "turbo hacker". But you know what? Most companies and most services and most situations don't need - or even worse - don't want turbo hackers. They want engineers who build proper stuff in a proper manner. Remember children, "boring is good".

[@nanonkay5669]

​@@PhilipAlexanderHassialisthank you. Go is the manifestation of the KISS rule. If you don't like a programming language just because it doesn't allow you to flex how clever and senior you are, then your head is in the wrong place.

[@joshmo3611]

​@@PhilipAlexanderHassialis Being a "turbo hacker" and also an engineer who properly plans and executes on projects aren't mutually exclusive. The company where I work is entirely Rust based and I don't think there has been any point where the engineering team has not at least planned a whole project out before executing on it

[@Patmorgan235Us]

Its perfectly and bureaucraticly mid, and we love it that way

[@MiklosGalicz]

@@joshmo3611ahh... to be a part of the select few... most companies/projects aren't like that.

[@shapelessed]

One great concept GO has implemented is errors as values, yes, they are annoying, but one day I decided to implement the concept in al my TS code with a simple helper return type that forced me to handle the error first before the actual return values were considered completely defined types, and from that moment I *never* had anything crash on me. I don't even need so many tests now because the control flow is so much better. When you throw and catch errors, you actually have no idea where the error will be caught and how it will be handled, which in itself could cause subsequent errors and crashes.

[@trapfethen]

Yes! it makes error-handling explicit and defined in the function signatures. I did the same thing you did and it made my life so much better.

[@SandraWantsCoke]

I do that too in JavaScript, I return an array, one value of which is an error (oftentimes just a boolean whethere there is an erro). And below the call is Just handle it like in Go. I still have try catch inside that thing that I call, but it's better this way, and in React/Nextjs which re-renders, you instantly have access to the error and not on the next render. Because with only try catch you need to set some error state inside the catch and that is only available on the next render, but what if it's a checkout button and you don't want your user to go further if there's error. It makes it easier to handle.

[@ebert7955]

Yup, errors as values are the way to go. I copied the Either type from fp-ts, doing isLeft everywhere is kinda annoying but it is worth it

[@belkocik]

where can I find an implemention of this error handling in TypeScript?

[@SandraWantsCoke]

@@belkocik const myFunction = async () => { try { await do stuff and get data return [data, null] } catch (err) { console.log(err) return [null, err] } } //usage: const [data, error] = await myFunction() if (error) { handle error }

[@Gisleburt]

I haven't done much Go, but I use TS and Rust regularly and _strongly_ disagree with the developer velocity thing, not because it's subjective but because we often forget what it takes to make software other than "just writing code". Correctness, edge cases and error handling, maintenance and even just "reading the docs" are all things we software engineers have to do a lot of, and all of them are easier in Rust. Can I write a bit of software faster in Typescript than Rust, sure, if I don't care about bugs and weird behaviour, telling people what I've done or whether this will still work in a few months time.

[@araozu]

I think that's the general mindset of theo/startups: get an mvp out the door, worry about safety later. However when not in a startup I'd say that Rust is overall faster than TS, considering everything that goes in sw dev. I wrote a bankend for a new project in Node, and sure it was "available" faster, but then a lot of my time went into debugging and catching errors and transpiling and managing dependencies and so on. So I decided to rewrite it in Rust, and the initial version took more time, but it worked without errors (except some minor logic errors).

[@Gisleburt]

@@araozu ​ Definitely agree, that's what I've seen working at a lot of "start ups" but it _can_ also be very short sighted. The two most egregious examples I've seen in my career: - Code that's broken, but no one realised it was broken because when you use `as` in TypeScript it doesn't actually convert from one type to another, which is what everyone seems to think it does (please never use "as" and also, dear TypeScript devs, please change Json.parse() to return "unknown" instead of "any") - Teams ballooning under the stress of trying to add new features while dealing with the interest payments on mountains of technical debt. This is still a problem in Rust, but much much less exaggerated than TypeScript It really doesn't cost as much as people think to do things... maybe not "right", but "better" the first time and you save yourself so much time later. As an aside on short-sightedness in start ups, I recently interviewed at a company who took pride in not writing tests because they wanted to go fast, but also talked about how developers were frustrated at having out of hours incidents and I literally couldn't believe the person interviewing me couldn't put those statements together. `as` is definitely the example I was going to use in my OP. Using "as" makes type casting seem trivial, but it doesn't actually check that you're right and in the best case, you get errors at runtime (but probably not where you did the "as" but where-ever you tried to use the data), and in the worst case, its just right enough that you don't get any errors, your code simply does the wrong thing and you may not use it. To do it correctly in TypeScript you need a type predicate which can be huge and easy to mess up and then you still need to generate an error when you use it. The Rust equivalent in a library like Serde is `from_str(data)?`

[@rand0mtv660]

@@araozu keep in mind that you already solved most issues during your first version (in TS) and then rewritten it to Rust. You probably would be even slower starting from scratch in Rust just because you would have to think about more things, not just porting existing logic where you already solved things. And on the topic of "being faster working with a language" is not really a language thing, but your familiarity with it. If I write TS for 3 years and switch to Rust for a month, I'm quite sure I won't be faster in Rust because I have all this TS experience under my belt. Developer experience and velocity is a subjective thing really, but objectively yeah Rust does solve some things better depending on your use case.

[@SandraWantsCoke]

@@rand0mtv660 Great points! Gave me goose bumps. I personally think one should write everything first in TS, it's fast enough with bun and elysia or fastify and get it out there quickly. If the money starts rolling it, rewrite it in Rust or Go. I also think writing a proof of concept in Rust is a mistake, it's just too slow to use.

[@ColinFox]

I've been developing in Go for a bunch of years now - 6? 7? Anyway, I love it. I came from Assembler, then C, C++, Python and now Go. I've started to learn Rust, but I learned Go to a usable level in an hour, whereas Rust is like walking with rocks in your shoes - you can do it, but it's painful every step of the way. I'm excited by rusts possibilities, and I love the correctness and efficiency of it, but it has a super steep learning curve. As for the difficulties of writing serious projects in Rust, I've seen a number of devs, famously Prime, who discuss programming challenges that are trivial in Go but become trait monstrosities when it comes to Rust, particularly around databases and shared data. Since you haven't done much go, why not actually spend a week and try to write something useful and productive. I'm sure you'll surprise yourself with how easy it is, and how fast you can go.

[@massy-3961]

Go’s dev velocity is by far better than Typescript’s when you are trying to build a production grade tool with robust fault tolerance and synchronization. You might go faster in typescript, but are you confident you are handling every error graciously? Are you sure if you need to change a library or two it’s not going to take weeks? Are you sure that the new developers can read through your codebase and understand in an efficient manor. This is where I feel Go has the edge. Also it’s quite amazing to not think about asynchronous code at all. No function coloring is one the of best things about Golang. Sometimes making a function async in Typescript propagates all over the codebase requiring major refactoring.

[@rerere1569]

How do I make structs with required fields in go? I remember trying it for some time and it was such a deal breaker with it's zero values

[@emilia-miki]

@@Nekroido the most wrong statement ever

[@asetjilkibaev3308]

@@rerere1569 type person struct { age int name string surname string } // Required to use New function because the person struct is not exported func New(age int, name, surname string) person { return person{ age: age, name: name, surname: surname, }

[@r4s3]

@@rerere1569 You could use the validator/v10 library to label the fields with validate:"required"

[@KManAbout]

@@asetjilkibaev3308 honestly no point of doing this, just export the fields and you do not need to write a new function. if there are some logic that occurs during construction then that makes sense.

[@agusaris5031]

Go is simple and practical. You don't overcomplicate it with like what formatter, linter, or framework you use. A wise man said "Less is more"

[@bronzekoala9141]

Imo that "uncanny valley" you described... also contains C# and Java themselve (+Kotlin), which all have very good tooling. Granted C# and Java arent exactly "Shiny" modern languages, but they do deliver.

[@gro967]

Java is just horrible, but I am totally agreeing on C#. C# also goes way to the left as .Net can perform even faster than native code in some cases.

[@KerchumA222]

I really agree. C#'s and Kotlin's syntaxes are very similar to Typescript (if you aren't already going absolutely insane with Types in TS), but the performance ceiling is significantly higher. The performance wins in dotnet over the last few years have been pretty significant and also don't require large changes to the application to adopt those new wins.

[@muhwyndham]

I cannot really say wholeheartedly that JVM has "good tooling" as much as it trying to save us from itself. Just today, I tried to have usable Java setup that does not revolve around Jetbrain's IDE. Basically almost impossible without us spending time managing heap allocation and VM Daemon on every occasion. Skip that and you'll have unusable mess where 80% of your system memory eaten up by idle Daemons..

[@viniciusmachadorodrigues1724]

Problem is the mentality with c# devs, they have this oop/patterns everywhere mentality that sucks

[@OnFireByte]

literally every static typed language with GC. JVM based, C# based, Haskell, swift, dart, even JS with the new static Hermes is literally in that "uncanny valley".

[@zsytssk5176]

When you watch theprimeagen videos too often, you will feel JavaScript is too low and TypeScript is just a JavaScript linter and Rust is too hard and Go is just fit for my level.

[@adicandra9940]

Golang is so trivial, I've built simple video server to play random video/music on my harddisk in browser. I did it in 5 minutes or so. No dependecies, just plain go and it's stdlib. not even http framework like echo or something. And you know what, it only cosume less than 10mb of memory, even when playing videos

[@JohnnyThund3r]

Reading this stuff... I'm really getting sold on Go, I'm also seeing game Devs remaking their game engines in Go and getting the same performance as they do in C. Go might be the perfect programing language for the current meta.

[@Goalatio]

@@JohnnyThund3r I think game dev in go is starting again because they recently dramatically reduced the FFI overhead with C. It's still slower than Java/Rust/Etc but it's fast enough now, in my opinion. There's people that say GC has no place in game dev.. but even unreal engine's C++ uses a GC.

[@keyboard_g]

For those not anti microsoft, you can write zero garbage collection C# and go extremely fast. Like the kestrel web server with does zero allocation request handling.

[@todorelax1793]

remember silverlight? Xamarin??

[@emreaka3965]

@@todorelax1793 yeah right, but he's also right

[@merkelizer9940]

I've been loving go. Pointers are weird, but once I realized they are an "opt in to mutability" flag, it all clicks. I find the Go code I write is easy to understand 6 months later. The language pushes me towards simplicity. Delightful! I just wish the type system could catch nil pointer mistakes.

[@LeePowell-z7o]

THIS. I wish it had type guards against nil pointers, interfaces etc.

[@arobie92]

What do you mean by opt in to mutability? To clarify, I fully understand how references work in Go. I'm just not sure how exactly thinking of them as a mutability marker makes them make more sense.

[@merkelizer9940]

@@arobie92 The point about mutability comes from Jon Bodner's *Learning Go*, a great intro to the Go idioms. Initially, pointers seemed foreign to me. What Bodner clarifies is that other languages also use pointers, they just hide them from the user. Consider this Python code: class MyThing: def __init__(self, name): self.name = name def rename(thing): thing.name = 'a totally different thing' def main(): thing = MyThing('steve') print(thing.name) rename(thing) print(thing.name) main() python3 main.py steve a totally different thing In Go, the syntax of pointers make mutability explicit. By default, function arguments are immutable copies: package main import "fmt" type MyThing struct { name string } func rename(thing MyThing) { thing.name = "a totally different thing" } func main() { myThing := MyThing{name: "steve"} fmt.Println(myThing.name) rename(myThing) fmt.Println(myThing.name) } go run main.go steve steve The explicit syntax, I realized, has my best interests in mind! The design clicked, the mystery around the asterisk went away. Anways, I am still very junior, and will likely run into some quirks. But for now, I'm enjoying Go.

[@user72974]

@@LeePowell-z7o One thing worth noting is that you can use interfaces as a guard against nil pointers. If you define an interface and use value receivers instead of pointer receivers for the methods defined in the interface, it results in only values being able to implement that interface. It would be impossible to use a pointer to an instance of that struct for that interface. It would only be possible to use a value of that struct. The compiler would guide you.

[@user72974]

@@arobie92 It sounds like what they mean is that mutability is the thing that is enabled for them when they use pointers. In reality, what people are opting into when they use a pointer is for memory to be shared (e.g. from a calling function to a called function). That can help with things like memory efficiency (not copying around big chunks of data needlessly) and allowing a called function to mutate something. It's the mutation that they really care about.

[@deefdragon]

the biggest reason I'm an advocate for making a full breaking change go v2 is to allow for the breadth of that uncanny valley it covers to widen. expanding the type system coverage to make it better to use, as well as adding performance things like arenas, or better methods of excluding the gc and forcing more efficient memory. the fact that go has calcified as it has, is both it's biggest feature and it's biggest detriment imo. also, today I learned that there's a good chance I've worked on the same code as Theo, given the tiny bits of exlixer I've touched at twitch lol.

[@nitzanbs]

I adore GO and still was interesting to watch your video, theres no need to make things complicated when they’re absolutely simple. But yeah like any language out there, there are better and worse choices. Just wanted to correct you, there is a way to poll on a channel and realize if it’s closed or not: regularly u get one value from a channel, but much like a map u can actually do this: value, isOpen :=

[@st-jn2gk]

on his ts v go v rust video, prime said golang was the language he had the least experience in and the one it took the least amount of time to write. He said rust was his most used language, and that i took around 5x the time to write it. and go won in that performance comparison, because apparently he didn't write rust the "correct" way, which just shows that in most cases, go actually ends up being faster eventhough rust has the potential to be faster.

[@michaelbobbitt6235]

My experience has been Python for the past few years because the tasks at my job were able to be done in an afternoon with it. Incredible velocity and happy management. What I learned was having to dig up one of these projects to add a new feature was painful. Moving fast in a dynamic language is a blessing and a curse. I used go for advent of code and was impressed that it compiled to windows and Linux out of the box and it was fast. Both in performance and velocity. This year I have replaced 2/5 of my python services in an etl pipeline which allowed us to turn off half the VMs. Adding additional features has been easier with less bugs.

[@boredstudent9468]

IMO C# is one of the best Languages for the "Valley", I've used it for a CAN-Bus Hardware driver as well as a Blazor SPA, and work mostly with process control, and desktop applications

[@emreaka3965]

Agree, I believe the best language for this spot is csharp. it allows you to use both jit and aot. it has a ton of features and a cool web framework.

[@mariogutierrez4989]

Go is 90% the speed of Rust and 90% the productivity of dynamic languages.

[@chrikke]

That's just not true if you are a decent Rust developer

[@emreaka3965]

@@chrikke It is true :P

[@chrikke]

@@emreaka3965 depends. It is, if you write bad code

[@chrikke]

​@@emreaka3965then you're not a decent Rust dev lol

[@Frankablu]

@@chrikke Rust/C++ developers tend to think they ship features quickly (and when they try to use TypeScript/Python they ship features at the same speed as they do in C++/Rust) but once you compare them to dedicated TypeScript/Python software developers the dedicated TypeScript/Python software developers will typically ship features 3x faster. What you believe to be "shipping features fast in Rust" is dog slow in the eyes of the dynamic language users.

[@kurt7020]

Rust compile times - are sloth-slow only if you're compiling for the first time, often every time fresh, inside a Docker container. Instead, if you're repeatedly compiling on a development machine during normal development, incremental compilation times are pretty fast. Not Go fast, but pretty quick. As for time-to-market, yeah Rust has quite a bit more friction than Go, and even slightly more than C++ I'd argue.

[@womiro]

As for C++ vs. Rust, I'd argue that developer velocity / friction with C++ varies a lot with boundary conditions. If your project uses a package manager and employs decent tooling (static analysis, sanitizers) to mitigate most common footguns, and you have a small and decently experienced team, I agree that C++ will be more nimble than Rust. If you manage dependencies with CMake or some "bespoke" build environment, without state of the art tools and have a more heterogeneous team in terms of experience, I would bet that you get things out the door significantly slower than in Rust.

[@MrJonathandsouza]

Yes GO is a programming language. Thank you for coming to my TED talk.

[@Lemmy4555]

I'm confused by the take that python can be faster than js because it's significantly slower in all the benchmarks, maybe the only exceptions are libraries that are wrapping c++ code but you can accomplish the same in node so i really don't see python being any faster than js in any situation.

[@proudkinglion2215]

He just talk nonsense. Maybe it's for some reason, but he make a lot of this mistakes

[@currentspw]

Could be thinking of Mojo?

[@fluud7220]

Depends on the interpreter. For example PyPy is much faster than CPython. Also, there are projects such as Numba which actually compile Python into native machine code, so you are still writing Python even if it's technically another tool written in C++ that's making it fast. The argument that "X language is not fast because really it's just C/C++ under the hood" does not make sense. You could argue in the same fashion that C or C++ are not really fast languages, acskhually it's the machine code generated by the compiler that's fast. When comparing Python vs. JS/TS performance you have to take all of these factors into account. Which Python interpreter are you using? Which JIT, if any are you using? Which JS runtime are you using? Just making blanket statements that one language is faster than the other one is not useful for much of anything.

[@Lemmy4555]

@@fluud7220 i'm talking about CPython that is the "default" vs NodeJS that can be considered the "default" as well.

[@dan-garden]

Wait did you just call Terraform a bad thing? Do you have a video on your opinions about why?

[@maazmunir9213]

yea that caught me off gaurd too

[@gro967]

The longer you work with it, the worse it gets… Especially in enterprise environments it’s just a pile of technical debt and let’s not even start with hcl 😅

[@d3stinYwOw]

OpenTofu, search that up.

[@nicks8129]

@@gro967 the enterprise cloud-infra function I belong to is heavily invested in Terraform. It's how we manage landing zone, and infra patterns application teams consume. It's been a challenge but after 5 years -- at scale -- we're doing great. But it has taken much planning, a lot of thought, good design, and making the right decisions to get to where we are. I know what you're saying, and it's defo possible to get it wrong and end up with tech debt. We had that for a while. The inconvenient truth though, is that Infra is hard and what else is there that is fit for purpose?

[@nicks8129]

It's cold here in Theo's shade XD

[@roccociccone597]

Let’s goooooooo, Go mentioned. But imma be honest, go’s simplicity is what I like. My team was able to migrate from Python to Go quickly with me being the only experienced Go guy.

[@LucaAlexandreCabrera]

Go is simplicity. Currently, this is gold

[@MelkeyDev]

I will enjoy reacting to this :)

[@oblivion_2852]

The thing that fits in the middle right is going to be Java/C# (virtual machines that can have pretty good optimisers). The thing middle left is Golang. It's a compiled language with a garbage collector but doesn't have access to creating your own good data types.

[@elephant_888]

Types are great in Go! It was a conscious choice to leave out inheritance which makes a mess of types anyhow. Most people know at this stage that Composition has proven to be much better than Inheritance when constructing more complex types.

[@capability-snob]

"if you look at this contribution graph" wow, that reflects exactly how much I want to contribute to someone's Go codebase 🙃

[@Malix_Labs]

Theo Go back-to-back You know it's because of the mustache

[@orcofnbu]

go also provides good tools for code quality. i just love built in test solution. it make scalability way higher than js and python. i also do not want to do extra work with rust or c++. i think go sits in great place and it will be next big thing in web dev

[@EvertvanBrussel]

Can I just say, I think Swift would span the farthest in that diagram from both having very solid performance and being very easy to learn and use. And in its latest versions it's focusing a lot on adding better and better compiler guaranteed safety against data race conditions in concurrent and multi-threaded code.

[@francesay8478]

1:06 "if you disagree with this, you haven't worked in both languages for long enough" It's black and white statements like this that really discredit what someone has to say. That isn't how things work at all, and I think you know that deep down, Theo. It depends on your use-case and specific needs. And even beyond that, it also depends on the developers themselves. Some devs move faster in some languages compared to others even with equal knowledge and skill. I think it would do you good to try to be less authoritative and black-and-white when you're making these types of videos.

[@rusmaakatupal4723]

C# can run fast as f. Import dll from win32 api, unsafe blocks, struct pointers, fixed buffers, pinned arrays, marshalling, native memory offset attributes . On the other hand it has functional programming features and insanely abstracted libraries for high level stuff.

[@johanrg70]

For a majority of projects, the difference between Go and Rust will not be as great as you made it out to be, it all depends on the memory usage in the project and other factors. I agree with several of the points here regarding Go, but that scale is just wrong and places Go in a category it doesn't belong in.

[@hanseichel4327]

I started out with Rust about a year ago. As in starting to code in my 30's without much prior knowledge. As you talk a lot about velocity/speed, i wanted to say that i think Rust might be slower to code, but in my experience its actually a language to learn coding with pretty fast! And i don't even think its over complicated since I didn't learn any other language really :D And the Rust compiler taught me everything I know about coding by now

[@jaymarksum6542]

As a former Go hater myself, I’ve come around to it and I am far more productive in Go than I ever was in TypeScript. I do disagree with many of your views but you do bring up some valid points to consider

[@joshring8563]

I don't know many orgs that re-wrote all their stack, so I think this seems like a strange discussion talking about a line to rewrite at. Can't be too far out either way if you Go for the middle. I found that it's really easy to make large changes in Go so the type system is really helpful to finding errors before you even need to compile, it also helps you at runtime, something python, JS, TS need extra libraries to achieve with greater complexity which comes along with them

[@tineocedric]

ok, this is a level of eloquence and clarity that has completely surprised me. Respect!

[@tobyzieglerrr]

i need to go as far as i need... that's go, it is just good enough for most and easy enough to go fast. no type massaging, no massive frameworks in the way

[@LiveErrors]

From what I can tell nobody enjoys writing go, but they enjoy the result of it

[@MrLordLowbob]

the fun thing is, i always want to go back writing go whenever I have some weird issues with typescript or tons of complex java dependencies or whatever. sure, go isn't exiting and in some cases annoying, depending on what you wanna do, but the simplicity is nice in its own way.

[@LiveErrors]

@@MrLordLowbob the "fuck it, ive gotta get this done" moment though i wonder why Theo barely acknowledges the standard GC langues in his graph explenation

[@vicentebravocabezas]

For me, I don't hate writing go, its just meh, but i enjoy the results and enjoy seeing whatever i'm doing work much more with GO because of how fast i get to that point. I also think its worth mentioning that other languages can be frustrating in a way that GO simply isn't. You might say at that point that switching to GO can be a net positive in enjoyment! That's subjective of course...

[@Pipe0481]

I do

[@ShrirajHegde]

If you don't like writing Go, you don't have to endure it a lot. Rust has the opposite problem, you juggle the types around like a chief for an hour just to produce lemonade 😂

[@demmidemmi]

This video seems to solely focus on Go being exactly what it sets out to be. Go aims to be simple and plane while bringing a good balance between performance and velocity, I really think you are under valuing Gos velocity. Yes Go does not have as much top end development speed as TS or Python but it really reels it back in in the long run on consistency. For me at least my job being a marathon rather than series of sprints has really increased the quality of my work life, yes you miss out on some of the excitement but over all the outcome is better.

[@vicentebravocabezas]

Im not disagreeing with you but I do think the performance points are misleading. The difference in performance between go and ts (even with bun) is massive, while the difference between go and rust is insignificant for a great number of applications. Its also worth mentioning that writing performant rust is much harder; bad rust can be slower than go

[@ShrirajHegde]

Yeah, the investment benefit of writing Rust takes quite some time to pay off. This comes at a severe hit to iteration time. I would prefer 90-95% performance of C in Go with fast feature addition and good contribution in open-source than 98-99% performance of C with Rust. Majority of the projects just don't require that last bit of performance pinching. And the reward ratio for that last bit of performance is terrible and rarely required. For example, Rust in Linux kernel, good choice (let's ignore Zig for now). Rust in Cloudflare's Pingora framework, great choice. But rust in package managers, linters, build systems make no sense. The advantage from going from Go performance to Rust performance is not noticeable for 98% of the times. This also comes a cost of less features since iteration is slower in rust. Rust craze is extremely misguided and might harm Rust in the long term. Rust is not cut out to be a general purpose programming language even with better build times. Rust is in a unique niche of safety guaranteed systems programming language. Making it more than it is and advertising "Machine learning in Rust" or "Rust for data science" is stupid. All those have a good enough ecosystem figured out and switching to Rust is just waste of effort in every sense.

[@ShrirajHegde]

Regarding bad Rust, seems like Linux kernel made a mistake in choosing Rust instead of Zig as the C successor. Linus Torvalds' reasoning to keep C++ out of the kernel was that it could enable multiple ways of stupid code. Rust allows things like Arc and Rc which are absolutely incompatible with Torvalds' standards. Zig seems to be a great choice here. Seems like Zig just missed the Bus for Linux kernel

[@nevokrien95]

I am learning a bit of go. Honestly very nice languge and a lot of the patterns you would use In C still hold. You also have very good c Interop. So I can see a world where you use go and when you think you need preformance you take out c. With unsafe go and c you can probably do stuff very close to full manual memory managment.

[@praveenperera]

The borrow checker doesn't slow you down if you just clone everywhere

[@kelvinclark3474]

😆

[@eduardozepeda1972]

Underrated comment

[@kerimzunic]

real

[@traydrdev]

I would love to see you and Low Level Learning go into the rust compile time rabbit hole!

[@OninokosInferno]

Great video! But I am missing C# in this list. Performance-wise, C# is often even faster than Go and has a lot of semantic sugar, allowing it to develop fast.

[@arryemoji]

You're coming around to go? Go where??

[@elieobeid77]

A better question is why would you come to go, why not just go

[@smort123]

Go Theo! But stay there!

[@crism8868]

He's going to come around to go come around to going Infinite loop detected

[@havokgames8297]

This is a good take. I listened to a presentation on Zig - and for one-shot CLI command's, memory safety isn't necessary at all. In fact, you can purposefully leak memory and just let the operating system clean it up once you are done. So if you want maximum possible speed, but a better developer experience than C or C++ then Zig would potentially be a better choice than Rust. But I'm also really interested in Go too. Maybe Go is an easier transition for Javascript devs if they want to help contribute - although this hasn't been the case as you pointed out for esbuild.

[@nathanfranck5822]

Yeah... Zig is pretty easy to get going especially if you just leak or use a giant arena. There's some annoying first-time user edges that will piss off some people, which is unfortunate, but you can model your types almost as well as typescript (expressive but simple), and crank the speed to 11 when you need to optimize.

[@TheTmLev]

People griping about Rust's compiler being slow just don't get how much heavy lifting it does for you, saving you from endless hours of sorting out weird bugs that pop up all the time in other languages.

[@fish3977]

Just because it is awesome doesnt change the fact it *is* hella slow

[@TheTmLev]

@@fish3977 first compilation - maybe so (but even on medium sized projects it takes one and a half minute on my machine). But the key thing is incremental compilation on the second and all the following runs - it usually takes a few seconds.

[@galus377pl]

Language for writing compilers is another problem. Go does not really have anything specific to support building the compiler, I remember needing to have interfaces with one empty method to mark structs as AST nodes which just felt so wrong. Rust on the other hand initially seems really attractive with ADTs. Later down the line you might get stuck with Rust, for example if you want to represent recursive types in your compiler in Rust you will have to implement some kind of handle system as references are not really an option. That gets a bit annoying, in Go you could just hold a pointer. When choosing the language to write compiler in I think people tend to focus on the start or end of the process (parsing, simple analysis, vm) in which case Rust is really attractive but forget about data representation for typechecking and so on. But as compilers prefer immutable data structures and visitors/folders to operate on code I wonder how much that is actually a problem. I can tell from my experience of writing compiler in Rust that it slows down my development time initially as I need to think about central database that holds all the types so that they can be queried later. But maybe i would need to do this thing with Go anyway later and Rust just shifted it left?

[@Jak132619]

I was hovering between liking and disliking this video and ultimately went with liking it. I don't necessarily agree that working in JS/TS will make you faster and "Dev Velocity" as a metric is very subjective. It can feel fast using JS array operations to break down data quickly. For example array.map().filter() feels like a more elegant solution and is much faster to write than writing for loops, but when you're debugging issues it's much easier to do that with for loops than functional operations. Yes JS/TS has a richer third-party ecosystem, but how much time are you spending having to audit and upgrade your various packages? This is less of a problem with Go due to its rich standard library meaning a lot of these packages are less necessary (and less tempting to automatically reach for when you need to left pad). I do think this is a good breakdown of the tradeoffs between these different languages, and well worth a watch though. One of the reasons I stay subscribed is it's nice to get a perspective from someone I often disagree with but still has valuable insights. Keep up the good work :)

[@dan-garden]

Is he coming or going?

[@crism8868]

yes

[@gageracer]

what about zig? from my understanding zig fits between rust and go space with better velocity than rust and almost same performance as rust.

[@keithjohnson6510]

Yeah, from a TS dev, Zig seems a much better choice, and from what I can gather, not only is Zig almost the same performance, from what I've read it seems in a lot of things it actually faster.

[@nathanfranck5822]

Definitely the Typescript -> Zig pipeline is real, especially with Bun existing and clueing people into the existence of zig. All the fancy type magic you can do in Typescript is kinda actually possible (it IS all doable, just don't get any IDE help) Great thing about zig vs. typescript is the sudden relief from worrying if your code will port to a platform (consoles? Sure. Embedded? No problem!). As well as the feeling that your code once written is probably fast and light enough to use anywhere. Also the auto formatter is awesome - Just try adding a comma to the end of any initializer and watch the magic!

[@2teaspoon]

Thank you very much Theo for this insight with the Performance versus Developer Velocity spectrum. As a web dev myself leaning towards C++ thought of learning manual memory management language so that "I have easy time" with high level languages. This video will help me decide what to do after I am done with what I wanted to learn from C++. If the thing I am making is super rigid sure I will pick Rust or C++, if the thing demands constant iterations safe bet would be TS/JS but if this thing is amphibious like we will have iterations but not as much as a JS framework and not as rigid as some OS firmware in this term Go becomes a lucrative option.

[@jenreiss3107]

maybe sending to a nil channel should return something like Result where the Err indicates an IO error and the Option indicates whether or not the channel is closed

[@willworth9610]

Even just learning the tradeoffs exist between languages is a massive help for newer devs. Thanks for all your insights. I'm coming to go from js/ts, and view rust as a YAGNI language. All depends on use case, of course. Time will tell.

[@thebutlah]

Something you're overlooking is that developer velocity is also impacted by how easily/confident one can be doing changes in a large codebase. Typescript is a massive improvement over JavaScript there, but it's just not at the level that Rust is.

[@charliecarrot]

What diagramming software are you using on that "Go and its place" visual you built? Love how simple and fast it looks

[@OldKing11100]

Excalidraw. Has a VSCode plugin also.

[@mattbettcher]

Excalidraw

[@charliecarrot]

@@mattbettcher thanks!

[@mattbettcher]

@@charliecarrot I saw your question while I was searching through for the same answer! Pretty cool tool.

[@crism8868]

I'm certainly interested in that rust compile time video. What an irony, it can compile other languages faster, but not itself... Also sending to a nil channel blocks forever, lmao cut to me laughing for an entire day like Mr. Burns in that Simpsons scene

[@PpVolto]

I love to use Golang and Svelt/Vue since what i need is the ease to style and build a Dropdown that works like i expect inside the "Templates". I can accept that i need spinup a "Frontend" server but integrating the backend server and have Request and Response Types is a Pain when the Backend is not in Typescript.

[@araozu]

I think that and SSR are the only reason for having a backend in TS: we need a TS framework for the frontend, and we can reuse the type definitions. Because otherwise there are a lot of better languages for backend. I haven't done a lot of Go, but in Rust I can just declare structs with the expected datatypes and serde deals with (de)serialization. I imagine Go must have something similar. Then the only pain point is maintaining those definitions up to date in both sides.

[@neneodonkor]

Have you ever used Vue and Go in the same project?

[@BozCoding]

I'm certainly in the C# camp for Dev velocity and through to Uncanny for backend

[@vsolyomi]

Where do more obscure things like OcaML and Elixir land on the chart?

[@coffeeintocode]

ONE OF US,ONE OF US,ONE OF US,ONE OF US - Really nice overview of Go's use-cases. Thanks a lot

[@JessicaFEREM]

there's this saying that "Perfect is the enemy of the good enough" and I think that applies here.

[@BrianJorgensenAbides]

On your (brilliant) spectrum diagram, I think lisp would be a black cube suspended in a translucent sphere. Or a phase-shifting keytar. Is SBCL fast or slow? Is it super productive to work directly in ASTs or is it the very definition of mental stack overflow? The answer mu surprise you.

[@nicolasguillenc]

The first thing you mentioned for not liking Go is exactly one of the reasons it’s so good 😂 it’s a preference I guess. But I like that you learn Go and you can work on any Go project, you don’t have to be a “framework engineer”

[@n-xs8up]

Exactly, the senior junior thing doesn't exist in Go. Its just imperative programming paradigm. That's why its often debugging C is lot easier than C++

[@starmechlx]

5:30 I'm incapable of reading articles for myself now. Where's the Prime video where he reads those to me?

[@AlexanderMoon]

Uncle Theo does know how to visually express his thoughts! I wish I had this perk too.

[@albert91tgn]

The issue with this diagram is that the scale is logarithmic. Go is 90% of Rust performance and 90% as productive as JS, but JS is 10% of the performance. That last 10% almost never matters, so instead of starting with TS knowing a rewrite is inevitable if you succeed, you can start with Go and stay with go to any scale.

[@zvibtm1]

Questions that come to mind: Why not just stick with Elixir\Gleam instead of Go when ever you can? What about Zig instead of Rust?

[@GaraEkz]

I think the contrast is that the middle is a perfect place to have a performant enough language and overall ok velocity, we don't invest too many time on building the project and it doesn't stink on performance

[@markpw1]

I've been learning Go for a week and have quicky rolled a basic API. As my front-end is expo react native and I'm familiar with TS, I'm second guessing my decision use Go over node for the back-end (which I have no experience in). Do I stick with Go or learn node?

[@EdouardTavinor]

if the task i'm solving is reactive or has other forms of concurrency then i always choose go.

[@СлаваВолошин-ы3с]

I've tried Rust and it's really hard to do stuff in Rust when your knowledge is not strong enough, but I think it is great. I have Python background and on big projects it's dynamic type system is not your friend. So no I want to try Go :)

[@manofqwerty]

Is the TS developer velocity not biased to the devs experience. I.e is it a skill issue? If you are more proficient in Go I would expect that Go would be very near to if not in the same spot as Go here.

[@rev4324]

Great video. Describes my love-hate relationship with Go really accurately

[@LeandroPiccilli]

Go was conceived when the landscape was different. It solves issues with the main options at the time: java (packaging, memory), python (packaging, perf, dx on big projects), c++ (packaging, dx, dev speed), ruby (packaging, perf), etc

[@germandavid2520]

Regarding development speed, I don't think Go is very far from JavaScript/TypeScript, in Go I don't have to fight with a lot of configuration files for tooling.

[@sebred]

The reasons for Rust's compilation time are very interesting. It is a combination of the extensive type system, static analysis, and relatively little parallelization. Take a look at it, the Rust compiler is really fascinating.

[@aymenmt1]

the way you explain stuff Theo is just perfect .

[@RichardGarber]

Axis of reliability would also be interesting on the other end, where I'd argue writing very fast developer velocity Python will often be way slower than fast velocity JS/TS, since you're almost never running in a JIT. I often first write something as a simple for loop just to test out ideas, then rewrite the loop with Numpy functions. (Could be skill issues) That first version will definitely be slower than Node code.

[@ghun131]

Your video sparks my interest in go. When I heard code from junior devs and senior devs was not much different, my tiny brain was just filled with joy

[@ghun131]

When people rebuild tools in Rust, I think they were afraid that Go would eventually become the performance roadblock

[@cole5981]

For sure. I think the fact that esbuild is maintained effectively by one person, yet the newest latest and greatest rewrites are struggling massively, says a lot about progress within the space. It's just like you said above dev velocity. It's interesting to see Rust excel in other parts of the space, like WASM, though. It wouldn't take more than a TS to Rust translation layer to have me writing Rust fulltime.

[@apffer]

Excelent insights. Thank you. I am in a startup using typescript /NextJS and adopting Rust for backend services and desktop apps integrated with local llms and vector databases and Rust seems like an excelent choice. Also, Rust makes me feel just like you felt about Elixir. Totally agree that rust is not for prototyping or testing approaches or concepts. I do it in typescript then write in Rust. Amazing how, if it compiles, it works with no bugs. At least it gives me that strong impression. Regards from Brazil.

[@ckalleee]

Would be cool to see how elixir fits in that scale, is the reason it’s not included bc it’s not an extreme point language and is therefore not relevant for the vid focused on Golang or is there something about elixir that makes it not relevant?

[@screwyourrules]

I agree! Elixir is a little different because it's far less "general purpose" than these languages. You'd probably want that 2D axis Theo mentioned. That said I'd love if he covered it since he always speaks so highly of the language

[@connormc711]

The typescript developers problem is with the garbage collector is the wildest take I could have imagined. Thank you for keeping us guessing what the your going to say next

[@nubunto]

TS's "developer velocity" means you get to screw up way faster in production than other languages....... also, this "Rust is slow because of the borrow checker" is just... not true????? I get it, a steeper learning curve, but I wouldn't say it's THAT much steeper than, say, ES5 JS.

[@hotbbqsauce5134]

mans gonna make us a go + react framework ;)

[@whitefluffycloud]

I don't see that gap in velocity between TS and Go, even in smaller projects. The amount of time I'm regularly spending dealing with issues around configs in a decently large TS codebase is ridiculous. Always slowed down by things not working properly in an increasingly fragile infrastructure.

[@SandraWantsCoke]

Agree, dealing with all the packages and updating them and all the config files adds up. And all the extra tooling one needs to have, that too.

[@armoredchimp]

I'm a jobless beginner who just spend the last year learning standard full stack web development and AWS. Since the job market is so awful I'm looking to specialize and I've been heavily considering making the transition to Go. I think the simplicity would appeal to me, and I think I'm better at backend than frontend anyway.

[@SandraWantsCoke]

All backend jobs around here are in Java. There are literally no Go jobs. So, be careful what you learn. If you want a backend job, go through Kunal Kushwaha course on youtube and you will have a backend job in a year or two. I don't know Java and I program Go btw, but that would be my recommendation.

[@canowyrms]

I was hoping to see where you would rank Elixir on that chart

[@wcrb15]

I really like this video, but I think dev velocity is a lot more subjective than you lead on here. I feel like every time I spin up a TS project I have to faff around with configs and dependencies for far too long before even starting the project. I can move much faster with Go because of how much is built into the core. It really depends on what you are most comfortable/experienced with

[@ryangamv8]

I didn't think I'd love it and there are a fair few very strange decisions made in the language design (no immutability? that weird loop variable footgun which has been fixed now, small thing but gofmt not putting spaces in 1+1, etc.), but the concurrency is just so easy and fun. Building with Go feels like a breath of fresh air coming from TS as well. Everything is just so... simple, and fast! I always thought the whole if err == nil would bother me more as well but it sure beats exceptions. Copilot helps a lot with that stuff as well. It also is kinda nice to go back to writing just regular ol procedural code when everyone else is going in the functional direction. It feels cool at first to write arr.filter(...).flatMap(...).reduce(...) etc. but it does hurt me deep down knowing how much memory I'm wasting

[@CasparRubin]

You've explained your thoughts very clearly and they make a lot of sense, thanks theo

[@MrDadidou]

The diagram at 00:40 is kinda misleading because it make it looks like the distance between each item is equivalent from one column to another.

[@al0jo]

As a python dev for a couple of years now, ive said multiple time that if i need speed and higher performance in my very high lvl language i can always work out integrations with very low system lvls languages to build performance without slowing down dev speed ( libs in c or rust ). I 100% agree with the feel of Go living in the middle. However when looking to explore a language that can give me a consistent ecosystem when building a monolithic project with frontend and backend as an experiment i found myself gravitating towards Go because of that mid consistent behavior. That gentler approach in dev speed you get from Go allows for still having a product with enough performance in general without making a huge compromise of the dev experience and in that sense i can see it being a great tool for integrated applications that may need to live as monolithic services. So there may be a space in market products for Golang after all

[@benjaminhon86]

wonder if we just restrict ourself to use a subset of rust and enforce immutable copy using functional programming maybe much of the complexity can be avoided by code style