6 ms·
You could think of the Go dev team's last ten years as trying to find the right balance between features (asked for by the expert devs that use Go) and simplici
by vessenes 2y ago
You could think of the Go dev team's last ten years as trying to find the right balance between features (asked for by the expert devs that use Go) and simplicity (a value that the designers hold, but that most expert devs making feature requests don't care about). Generics always felt to me like this dynamic in a nutshell. Lots of good reasons to prefer generics when you need them, and it feels like a nearly ecosystem-killing amount of complexity to implement a type system like Rust on top of Go - there's literally almost no reason to use Go in that case.
Anyway, I like seeing this slight reversion in favor of simplicity, I think it's the right call for where Go's targeted: being a better Java for teams of mid-tier engineers.
- deleted 2y ago[deleted]
- maccard 2y ago> there's literally almost no reason to use Go in that case. I work in C# and C++ day to day now, and in $PREV_JOB I used Go and C++. my go builds on a similar size project were quicker than the linter in my C# project is right now. Go's killer feature IMO is that it's _almost_ scripting level iteration speed.
- vessenes 2y agoI too like this feature of go quite a lot. But I think it's supercharged by the major reason I'd pick go for a mid-size team; the language is exceedingly easy to parse, code in and understand even if you're not a genius. I think the testing support and very moderate type support hit a valuable place in development ecosystems -- as you say, you get near instant linting feedback about a lot, and it's also pretty easy to read and write in. Basically, the mental model required for coding in go is low load. That's a great feature.
- maccard 2y ago> as you say, you get near instant linting feedback about a lot Sorry, it wasn't clear. I could run `go build && ./myapp` and have my application running quicker than `dotnet format` finishes. Linting in .net is slower than compiling in go. Agree on everything else. It has it's share of footguns, for sure, but so does every language.
- neonsunset 2y agoFWIW dotnet format is not a linter, it's just a formatter and yes it is slow (I guess because it's ever so slightly neglected, I'd expect most developers use IDE-provided or Roslyn-provided (for VSC) auto-format instead). Overall, the tooling could be faster but because it is JIT-based and performs heavy unbound reflection, it's not very amenable to the NAOT compilation in its current form if you are used to frequently running 'dotnet build' and 'dotnet run' where startup latency imposed by JIT is most noticeable. Also keep in mind that both invoke the full build-system. It's closer to what Cargo does than what Go tooling does. Are you using .NET 9 SDK? Another feature I suggest looking at is hot-reload with 'dotnet watch'. It can shorten iteration cycles for doing the back-end work substantially.
- maccard 2y agoHonestly I don’t care why it’s slow. It’s up to dotnet to sell itself. It’s not my problem if dotnet invokes the full toolchain to run an incremental tool - my point is that go’s entire compilation is still quicker and that’s a huge boon.
- neonsunset 2y agoThe tooling itself is not _slow_ (are you intentionally misreading this?). It is slow_er. Why are you using dotnet format? Try CSharpier instead. It does not matter on CI, it matters locally where you should be using something else. And of course if you are looking for an excuse to use Go (which is a worse language), fixing this or any other "issue" will not help - there will always be another reason.
- parliament32 2y agoDo real organizations actually use C#? Every time we've evaluated it we concluded it's a worse, MS-flavor Java rewrite so we didn't take it too seriously. Does it have any actual advantages over Java?
- pjc50 2y agoIt is IMO better than Java these days, although they're pretty close. Whenever I have to go back to Java I find odd things missing, like unsigned long. AOT is pretty good when it works.
- CharlieDigital 2y agoLots of real orgs use C#. StackOverflow survey (self reported) for 2024 shows it at #5 leaving out HTML/CSS, and SQL[0] DevJobsScanner shows it at #4 via scraping job postings[1] It definitely has heavy adoption; well above Rust and Go despite what we see here on HN. > Does it have any actual advantages over Java? The language evolves faster and is more akin to Kotlin than to Java, IMO. The DX is fantastic and there are a few gems like LINQ, Entity Framework, and Roslyn source generators. Modern C# can be very dense yet still highly legible. C# switch expressions with pattern matching (not switch-case), for example[2], are fantastic. [0] https://survey.stackoverflow.co/2024/technology https://survey.stackoverflow.co/2024/technology [1] https://www.devjobsscanner.com/blog/top-8-most-demanded-programming-languages/ https://www.devjobsscanner.com/blog/top-8-most-demanded-prog... [2] https://timdeschryver.dev/blog/pattern-matching-examples-in-csharp https://timdeschryver.dev/blog/pattern-matching-examples-in-...
- alemanek 2y agoIt has been 8 years since I last wrote any C# code and I still miss LINQ to Objects. It felt so natural building up queries against collections and very readable.
- CharlieDigital 2y agoThey've made the language much more terse, IMO, taking a lot of cues from TypeScript/JS as well as other languages. Constructs like primary constructors, record types, pattern matching, and destructuring continue to improve ergonomics, IMO. For a quick comparison, check out https://typescript-is-like-csharp.chrlschn.dev/ https://typescript-is-like-csharp.chrlschn.dev/
- LtWorf 2y agoI can't trust any programming language where there's data structures I can't implement myself.
- jimbokun 2y agoGenerics really reduced the sets of data structures you can’t implement yourself by a lot.
- divan 2y agoWhat data structures can't be implemented without generics?
- bsaul 2y agoi guess maps and array ? ( if you wanted to reimplement your own in a typesafe way, that is)
- vessenes 2y agoI think anything could be implemented, since you’ve got byte arrays in the language, which I imagine is your point. It’s more what you must implement along with your new data structure to make it usable in the language that was the cry of the generics advocates.
- jerf 2y agoI don't think there's anything you "can't" implement that the language reserves for itself anymore. There may be some edge case or something but in general it's no longer an issue. The language reserves syntax for itself; you can't overload a[b] to mean anything other than either array/slice indexing or indexing into a map. You have to write methods like ".Get" or something, there's no __getattr__ or anything.
- ts4z 2y agoGo has good (enough) built-in arrays and maps. But if you want a tree, without generics, you're really limited. With generics, you can get a nice containerized type, but you don't get the nicer syntax that the builtins have. It's not just types, either. Look at the signature for the built-in sort, which is amazingly cumbersome to use. A generic wrapper around it hides all the ugly.
- devuo 2y agoIt's interesting how simplicity so often gets mistaken for a lack of sophistication. Designing a language for clarity and maintainability is a laudable goal, and so is choosing to use one. Chasing complexity, or reaching for the latest trendy language that lets you "express yourself" in ten different ways to do the same thing, isn't what makes someone an S-tier engineer. Simplicity isn't a concession. It's a hard discipline.
- dwattttt 2y agoIn exactly the same way, complexity you don't understand the purpose of is often disregarded as complexity for complexities sake. It's easy to get things simple and wrong, and hard to get things simple and right. And sometimes complexity is there for a good reason, but if you don't work hard to understand, you'll fall into the "simple and wrong" camp often.
- bb88 2y agoOne problem with simplicity is that it often moves the complexity elsewhere, particularly if you're designing things that others use. Brainfuck the language is simple to use and implement. It has only 8 commands. Brainfuck programs are virtually unreadable, unless you can get your head around it. The advantage of trying to solve complexity is that if you can solve it, you've solved it once and exactly once for everyone involved.
- valenterry 2y agoBut each line of Brainfuck is very simple and easy to understand! - is the type of argument that I often here from folks that like Golang...
- int_19h 2y agoThing is, it's not even necessarily true for Go. E.g. that whole `iota` thing is hardly a good example of "simple and obvious" language design compared to enums in... just about everything else. Or we could talk about the difference between a nil interface value vs interface value wrapping nil.
- trentnix 2y ago> being a better Java for teams of mid-tier engineers. That cuts me right to the bone.
- karmakaze 2y agoThis explains why I lost interest in Go right after it got generics and went back to Java (or Kotlin actually). I do like to dabble in F# still.
- zik 2y agoIn the end it was a dumb comment by one of the Go devs which got jumped on by all the Go haters. Contrary to the popular meme, Go's not just for mid-tier programmers - it never was (and to be fair to Rob Pike, they've twisted what he said). But sure, it makes it easier for programmers at all levels to get started, and to get real work done. That includes advanced people as well as the inexperienced. I think the ultimate goal of making a programming language is to cause the least friction for a programmer trying to get real work done, and in my experience Go's great from that point of view. Language bells and whistles may be exciting, but often don't pay their way in terms of real world productivity, IMHO.
- karmakaze 2y agoIt may have been a dumb comment, but there's some truth to it. Go was to solve a Google problem of devs that needed to write system management programs, not systems themselves. The choices of Python or C/C++ left a large gap that Go filled. I used Go for most of my own projects and as I got deeper into it began to realize its warts, but the worst was that you can't get performance by "share memory with communicating"--channels are slow. Reading the non-idiomatic stdlib implementation shows the difference of who it's made by vs who it's for (which isn't the authors).
- 9rx 2y ago> Go was to solve a Google problem of devs that needed to write system management programs, not systems themselves. What's the difference? The opposite, so to speak, of system is script, and I don't think system management falls into the scripting category. A system management system is a system too. But that isn't what they were talking about anyway. They were talking in the context of building servers (think like a HTTP server). That was clearly spelt out. I understand that the Rust crowd has reimagined system to mean something akin to kernel, much like they have reimagined enums to be akin to sum types. Taking established words and coming up with entirely new meanings for them is what they like to do. But that reimagining has no applicability outside of their little community. This is not how the industry in general considers it.
- somezero 2y agoNot sure simplicity of spec translates into simplicity of user code. This change is backward compatible and will allow things that previously were disallowed.