Hacker News Reader

Hacker News

Comment by tsimionescu | Hacker News Reader

Full thread

tsimionescu

Coming from the C# and JVM world to go, tooling looked like one of the worst parts of Go.

The debugging story is very limited:

- No function execution

- No edit-and-continue

- No conditional breakpoints

- No watchpoints

Package management works OK on the consumption side, though it is much more clunky than with classic package managers (e.g. set an ENV variable to get a custom proxy, but write something in go.mod file to get a per-package proxy). However, the publishing side is all over the place:

- Relies on source-control integration

- Horrible import paths for packages published from large repos

- Versioning based on source-control tagging, exact format undocumented

- Major version changes require source-code level changes in all files touching the package

- Multiple Go modules in same repo use-case is not documented (can you have separate versions from same commit? how do they reference each other?)

The source-code level tools/plugins available are extremely basic (except for GoLand):

- No refactoring support other than "rename variable"

- Reference-finding across modules rarely seems to work

- No way to automatically find all implementations of an interface - especially problematic in a language with implicit interface implementation

- The tools are pretty slow, constantly re-parsing large chunks of code; go pls has fixed some of that

View on HN

I agree 100%, and I pretty strongly dislike Go's tooling because of it. Especially due to the horrible debugging options (though something is far better than nothing, of course). I've bashed my head against every single item in your list multiple times, and they've made extremely little progress over the years so I'm quite pessimistic about them changing.

Though for completeness, what it does have that I find very useful, and has had from early days:

- pprof for cpu (tunable sampling rate) and memory allocations (sampling and I think tracing)

- a standard build system (as annoying as it can be (GOPATH, no file-as-input-list, etc)) so builds are indeed generally very simple and consistent: `go build .` (plus `glide install` or `dep ensure` in many cases, but that's easy too)

- race detector (trivially catches an incredible amount of issues in less-than-highly-skilled code, which is the vast majority that I interact with)

- `go fmt` spawned a whole ecosystem of "autoformat ALL the things" tools

- (I personally don't give them credit for vendor, as vendoring was a thing the community hacked together for years before they finally half-supported it, though now it's great. GOPATH should have died that day, but alas...)

.... though that might be my complete list tbh. And yeah, Goland's tooling is miles ahead of everything else, refactoring and find-usages is dramatically more accurate than all other tools I've tried.

---

Many of those have been built (far more powerfully) for other languages, but part of the "go has good tooling" claim is that it has those out of the box. It's nowhere near enough to be "great" IMO, though modules get it much closer, but it gets a "good job" sticker on at least a few things even if the whole isn't particularly impressive.

This nailed it for me. I came back to write some go last night after not writing it for a long time. The modules, go dep, etc stuff really put me off.

Whereas beforehand (been writing stuff for a few years, not hobbyist, just not super complex) it was intriguing..now it seems like they've just moved on in one direction for packages. However, that direction is not really super well documented, intimidsting, and sure as hell doesn't work as well as nuget or npm.

No way to automatically find all implementations of an interface - especially problematic in a language with implicit interface implementation

This is fundamentally a problem with duck typing, and it creates a massive amount of cognitive effort when trying to understand an unfamiliar code base.

I don't have the qualms you have about the rest of the Go tooling, which is pretty good IMHO. The fact that it comes out of the box is a significant bonus too.

I understand duck typing of interfaces to types imposes some limitations, but it is by no means an absolute limitation. Given a set of Go source files, you can absolutely automatically find all types in those source files which match an interface. Sure, there could be implementations in other places as well, but the same is true for Java or C# or C++.

Also, note that the compiler already does this check whenever you try to use some type as a specific interface type, this is not dynamic binding at runtime.

I understand that, but it means I need to rely on tooling (which has limitations) to do something that is zero-effort in other languages, and that impedes easily understanding unfamiliar source code. It's not so much "Which types implement this interface", but rather "Which interfaces does this type implement".

For this reason, I'm not at all convinced that duck typing contributes to the fundamental need to write easily understandable and maintainable code. What does it add, or what problem is it trying to solve?

One commenter recently suggested putting, eg:

    var _ MyInterface = MyType{}

at the top of the file to assert explicitly the interface implementation. This works but is a bit of a hack.

Duck typing is my main gripe about Go, but generally I like it very much, and find it very practical, especially (funnily enough given the article) it's tooling.

Oddly enough I've never needed to look up "what implements this interface" in Go. I've been writing Go professionally in a senior/team lead roll for over 4 years.

Usually I know what implements a given interface, as in the package I'm writing, I know what I've imported. Packages are usually small/narrow enough that there isn't ambiguity (i.e. I'm not reaching for some arbitrary implementation).

The only pain point that comes to mind is the bytes, io, and strings packages where there are many common interfaces and many implementors, but it's never really headache inducing.

The interface assertion you mention is useful for implementors to catch at compile time if they didn't implement a given interface (rather than find it at call sites), and catch where implementations break when an interface definition changes. You could put it in a test file, if you like, for the same effect.

> What does it add, or what problem is it trying to solve?

In Java, if you get a type from a library, and it doesn't implement a particular interface, you're stuck. You have to wrap it up in some intermediate type. It's useful to be able to use types that don't know about a particular interface even if they happen to conform to that interface.

However, I would agree that it would be useful to be able to specify which interfaces you intend a particular type to implement. (Or maybe Go allows this? I'm just talking about duck typing here, as I don't know Go very well.)

The worst? What exactly other language has:

- built in race detector ( go build -race . )

- multi-platform / multi-os easy compilation ( GOOS=windows GOARCH=amd64 go build . ) <- you can even do that from your Rapsberri pi

- very easy and powerful profiling with pprof

- go fmt / go vet

Yes it's not perfect but it's better than most languages so I woudn't be that harsh on tooling, especially since most of your issues are not related directly to Go tools (Packages publishing side ) and for the last part Goland works fine and is the most popular IDE with VSCode.

Go overall has good tooling for a relatively young language compare to more matures ones like Java and C#.

Let's not forget most of the good JVM tooling, especially early on in Java's history, was and is 3rd party and most cost money. Even today, it's still a sea of confusion, especially if you are new to all of this. For example if I search for "best JVM profiler", I get a list of 10 results all claiming some form or fashion of being "the best" or "most popular"

As someone who spent the first half of their career on the JVM and now is mostly Go, I don't understand how someone who has been on the JVM most their life can say Go's tooling is "the worst" Most of the things you have to configure and tweak on the JVM and profile for aren't even considerations in Go, because they are either simply non-issues in Go, or don't exist (because Go does not have a virtual machine to begin with)

Sure, but whether a tool is 3rd party or 1st party matters less if there is significant difference in the advantages that tool brings. Being free and/or open source is more important, but at least currently, there are many excellent free and open source Java tools in all the categories I mentioned.

Also, I didn't say that Go's tooling is the worst. I said it's one of its worst aspects. I still miss Maven, jmap, VisualVM, and the Java debugger almost everyday, not to mention IntelliJ.

> Most of the things you have to configure and tweak on the JVM and profile for aren't even considerations in Go, because they are either simply non-issues in Go, or don't exist (because Go does not have a virtual machine to begin with)

I'm not sure what you are thinking of specifically here, but in general the same considerations apply between Go and JVM, it's just that Go doesn't allow you to tweak things like GC algorithms and parameters. JIT is the only other area where I remember spending time thinking about Java performance that is truly a non-consideration in Go, but Go has other performance considerations to worry about (pass by copy vs pass by pointer, number of system threads off the top of my head).

The race detector is nice, and can be a massive boon to productivity.

Mulți-platform/multi-arch compilation is simply not relevant to most common languages in use today. Still, it's nice that it exists, though it is only so simple because of Go's (flawed) static-linking-only model.

Go fmt is a nice tool, but is very low impact in my experience. Go vet is OK, but there are better static analyzers. The fact that it comes out of the box is a plus, but it's not the most important characteristic in a static analyzer.

Profiling with pprof is nice for very simple problems, but it can't match a visual profiler for complex issues, and its memory profiling is extremely bare bones. Java heapprof and VisualVM are equivalent or superior, and they also come out of the box with the JDK. Similarly, the kinds of memory analysis you can do by collecting heap dumps and analyzing them in GDB is much more powerful (and has many more uses) than what pprof offers on that front.

Go overall has decent tooling, especially for its age. But its tooling compares unfavorably to what is available for free (not to mention if you are willing to pay) for any other popular language except maybe python.

As a final note, package publishing is absolutely related directly to Go tools - it is go mod download/go get that define what it means to publish a go package, how you specify its version and everything else I raised.

Imagine how much worse other popular programming languages' tooling is, given Golang is constantly praised as having great tooling.

When integrating into a new dev team, half the work is grokking their local tooling choices. In an ecosystem with strong "one best way to do it" tooling, that effort is almost non-existent.

But then, that is the question : which language is that? C# and Java are not it. C and C++ have excellent dev tools and debuggers, though it's true package management is essentially non - existent. Python, JavaScript and TypeScrpit have better tools than Go, even with the limitations of a dynamic language (the package ecosystem of npm is horrible, but npm itself is a pretty decent tool, definitely much simpler than go mod).

Rusts tooling is pretty stellar.

Depends. Package Management, compiler errors? Absolutely. IDE support? Not so much. I don't think it's fair to compare it to C# / JVM languages, but even compared to other languages, I wouldn't say the tooling is all that great.

Macros make IDE support a lot harder than in other languages, the atrocious compile times sure do as well. While IntelliJ Rust and rust-analyzer both try to do their best (kudos to the teams working on them!), it's still nowhere near anything I'd call "stellar".

There are mitigations being worked on right now, like compiling macros to WASM[0] and Cranelift[0], but these endeavours, while very promising, I wouldn't call production-ready yet.

[0] https://github.com/dtolnay/watt [1] https://github.com/bytecodealliance/cranelift

EDIT: Also, debugging. I'm not sure of the current state of it, but last time I checked, it was pretty much just GDB integration that was working. CLion (which I think uses GDB?) is able to give you a nice UI for basic debugging, don't know about VSCode integration.

Still, even if it works, it's not at all comparable to debugging in C#/JVM, you're limited to very basic stuff compared to these languages / the well-known IDEs for them.

So, again, it may be "fine" or even "good", but imho it's not exactly stellar :)

Re compile times: in nearly all cases I've seen, un-optimized builds (opt-level=0 or 1) are still quite fast. Do you know of any counter-examples? I'd love to see what the cause is.

Optimized builds though, yeah, you routinely hear about multi-hour builds. As long as there's a dev-friendly fast mode though, slow optimized builds don't bother me all that much.

In my experience, the problem is that debug builds (which, I assume, are not optimized) are still annoying. I recently built a new PC and got a Ryzen 3900x, so I'll probably have to check again with that :)

Now, "atrocious" may have been bad wording without context: I think it's just taking very long to finish the normal edit-start-debug cycle, compared to other languages (Go, Java, C# for example). I don't have any numbers right now, but I'll try to update my post once I get home, I've done a few basic emulator projects in Rust :)

At least, it was long enough to be annoying to me. Maybe I'm just too used to C#, which I use at work.

I've seen some pretty long compile times in C#, at my previous job building a local copy of the whole solution was around 40mins to an hour (400+ csproj).

I guarantee that a 400+ module Go program or 400+ Rust crates will build much slower (if no other reason, simply because Go or Rust compilers do a lot of work that is deferred to runtime in C#).

What counts as "quite fast" for you? If you're talking about multi-hour builds, then you might not be talking on the same scale as others. I would consider 10 seconds to be pretty slow for a small/medium sized project.

Yea, fair. But for compiled languages, a few seconds is still fast for the field - Go takes that long on anything but tiny projects. My job's main Go binary takes about 30 seconds for a rebuild, for instance, and I know of other projects here that take well over a minute.

Many of the hours-long optimized builds for Rust projects that I've seen have turned to <10 seconds without optimizations on a clean build (possibly libraries are still cached tho), and even fairly large ones are still less than a minute. Tiny projects are around a second or less. I'm usually looking at pathological cases though, so I'm not sure how well those hold up in general.

So I'm not looking for interactively fast - very few languages achieve that on even medium-sized codebases, even if they're interpreted. But under a minute for a couple million lines of code in the project and libraries fits in my "reasonable" range.

VSCode with gdb at the backend gives you IDE like debugging.

VSCode with RLS gives you decent IDE support - not Visual Studio for C# standard, but much better than a large number of languages.

At the caveat that RLS is a bit fragile - I have a project with a moderately large proc macro that generates multiple items and RLS falls over on that project now. Rust Analyzer is more robust but doesn't have a debugger or as comprehensive a feature set yet.

Rust copied tooling from Go and Python. Also its tooling cannot work without internet and need to download MB's of data for simple development, and on the other hand proclaims itself to be systems programming language to replace C and C++ which doesn't require active internet to work.

Also C++17 is much better version taking away the deficiencies of earlier versions and if not better at least provide similar run-time guarantee and safety as Rust (which also needs to rely on unsafe code to do anything meaningful with systems programming).

So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. Just with C++ you will not have to climb the mountain of learning just to do simple things.

I think Rust gets a lot of hype because it's syntax is complex and learning curve is much higher than C or C++ and programmers see new shiny language which got some traction as Panacea for all the programming problems.

Did you forget how much apt-get build-essentials is going to take in terms of space?

> So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees.

As a C++ Dev who's done some rust on the side this is utter horseshit. Regardless of which C++ version you use it is utterly trivial to write code with undefined behaviour. Even if you're extremely diligent you will eventually be hunting down a bug caused by undefined behaviour.

Kind of, if one belongs to the developer category that doesn't use static analyzers as part of the compile/build cycle.

> which also needs to rely on unsafe code to do anything meaningful with systems programming

Rust allows you isolate such instances of unsafe-ness to specific parts of your code base. When you're auditing for safety, you only need to audit those specific parts because everything else is safe by default. For example, the implementation of std::vec::Vec uses unsafe, but it exposes a safe interface. So once you've audited the few hundred lines of std::vec as being safe, you're sure that the millions of lines of code relying on it are transitively safe.

> which doesn't require active internet to work

cargo build, cargo clippy, rustfmt, rust-analyzer, rustc all work without internet. If you want to fetch dependencies from the internet, you need an active connection. If you're in a situation where internet isn't available, you can work around this by writing all the libraries you need. Same with rustup - it needs the internet to download new versions of rustc and cargo.

> you will not have to climb the mountain of learning just to do simple things.

I'm sorry you felt this way. Learning materials are improving all the time and the language is improving too. For example, future combinators were a pain but with the advent of async-await it's easier to write and read code that deals with Futures. Give it another try :)

> If you're in a situation where internet isn't available, you can work around this by writing all the libraries you need.

Why can’t cargo be simple enough like pypi where all the dependencies are in intranet and private or another way is all the dependencies are in my own simple folder and can update it separately whenever I need rather than relying on an internet connection.

Rust cannot match C and it will always need to interface with C code, so in the end it will only be as safe as the C code it is interfacing.

I do not understand why to create complex syntax and semantics and difficult to learn language in spite of so much development in compiler world. Like Swift which is similar to Python style syntax. Also Swift is performant and secure enough to provide replacement for objective-c.

Hopefully FP (functional programming) becomes more mainstream and take away all this burden of imperative languages like Rust. But being pragmatic understand for hardware C will be there at least for the foreseeable future and Rust and any FP language can only do so much.

On a personal level Python made code beautiful by white-spaces, pep-8 and cultivated a habit of trying to write beautiful code. It did not succeed completely in writing every library beautifully because in the end it needs to interface with C libraries where practicality beats purity.

Rust copied gofmt and introduced rustfmt. Still Rust has miles to go until it is just able to be as clean as Python for beautiful code and cultivate it as very important habit like Python. It will take Rust may be another 30 years or more to come close to it, given its syntax and reliance on C interface.

Any other language I see at present with safety guarantee and as clean as Python is Swift.

I like lisp, Haskell and other FP which can achieve a lot with very little code, easier to refactor and maintain in the long run. Rust is just opposite of it. It’s as difficult to learn as Haskell with complex syntax and semantics, but less powerful than C.

Swift is not a competitor for Rust. It may be a competitor for Scala/Kotlin native or Go, but definitely not in the same performance league as Rust or C++.

> Hopefully FP (functional programming) becomes more mainstream and take away all this burden of imperative languages like Rust.

Pure FP is overrated. It is a nice academic model of computation, but it doesn't reflect the way how hardware works. Hardware is mutable and memory is limited.

> It’s as difficult to learn as Haskell with complex syntax and semantics, but less powerful than C.

This is a subjective opinion, not a fact.

> as clean as Python

:D :D :D

Why would we need to limit our programming language abstractions to how the machines work underneath? Are there some stateful objects running around in the hardware? Just because the abstractions are detached from the hardware doesn't make these design patterns useless.

It is nice to have a connection between abstractions and hardware, because it makes it easier to reason about performance, which in turn makes it easier to achieve great performance.

Now, not everybody actually need great performance, so some distance between hardware and abstraction is ok, but the amount depends on the use case.

Well, I agree, that's why we have both low and high level languages. High level languages, setting you free from the actual constraints of the underlying machine, allow you to define abstractions that can increase productivity greatly - that's their whole point of existence.

I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions.

> I mean I don't see people complaining how you don't need to manually manage memory in SQL expressions.

Well, they don't complain about not having to manually control the low-level bits of query execution, but later they frequently complain about performance problems. And then they add hints, setup buffer sizes, indexes, etc.

Also, Rust (and to some degree C++) shows that you can have both very high-level, productive abstractions and low-level control. They call that zero-cost abstractions. The price to pay is a steeper learning curve, but not actual productivity or final performance.

This is the most exciting part about Rust actually. I know how to write Kotlin, Scala, Java or C# code that's close in performance to C or C++. But this will be ugly, unsafe and hard to maintain, non-idiomatic code. Rust gives ability to write code that has almost Python-like expressivity but is still fast as if it were hand-optimised loops and pointers.

I'm not sure what your point is. I feel we may have a different idea of what very high level abstraction means in programming languages.

Just about everything in software engineering is a compromise of sorts. Not knowing Rust or C++, I doubt they're as high level as something like Haskell or domain specific languages like SQL. Are monads first class citizens on C++? Type classes? Generalized Algebraic Data types? Parametric polymorphism & pattern matching? And so on.

Would you really achieve the same amount of type level guarantees, equally concise control flow and concurrency on C++ with an equal amount of lines of code as would be possible on Haskell? If not, then there obviously is a productivity penalty. Just like on Haskell there is that performance penalty for not being able to drop down close to the metal.

From what I can tell, these languages are not aiming to be very high abstraction level languages but instead solid systems level languages with some convenient abstractions and design patterns baked in from higher level languages.

Sticking only to some zero-cost abstractions limits how high level abstractions it is possible to bring to the language. This in turn limits productivity.

Rust is very strong in its ability to build extremely powerful abstractions. With built-in compile-time procedural metaprogramming I could risk a statement that in some domains it may be actually even higher level than Haskell. Maybe its type system can't prove all the same guarantees as Haskell, but on the other hand, Haskell can't prove some guarantees that Rust can. They offer different set of abstractions with some overlap (e.g. first class type classes and ADTs). If is really hard to say which one is higher level. They are just different.

Anyway, type safety is not the same as productivity. If it was, then nobody would use Python or Ruby and everybody would use Idris. I became much more productive quickly in Rust than Haskell.

Interesting, what kind of guarantees does Rust give that Haskell's abstractions cannot do?

Haskell also has metaprogramming in terms of Generics and Template Haskell, allowing you to create custom DSLs and such. Sadly, it kind of leads to pretty ridiculous compile times and mixed editor support so I'm trying to avoid that.

We should remember productivity is really subjective and not the same thing as high level abstractions. We're typically the most productive on the language we have the most exposure to, whatever it may be.

> We should remember productivity is really subjective and not the same thing as high level abstractions. We're typically the most productive on the language we have the most exposure to, whatever it may be.

I agree with you on this we are most productive in the language with most exposure.

Indeed many in Rust community do not realize that the LLVM infrastructure they use for Rust to make its code executable by real hardware is itself written in C++.

Rust is still miles away to compile itself and may not happen. So survival of Rust is dependent on progress of C and C++. So I doubt it is even be viable to call it their replacement.

> Indeed many in Rust community do not realize that the LLVM infrastructure they use for Rust to make its code executable by real hardware is itself written in C++.

And the operating system is written in C, and the CPU in VHDL (or sth similar). Compiling itself is a property that only academics take care of. LLVM and C are not going anywhere anytime soon. There are more important things to do now. That's why Rust is already much more loved and popular language than Haskell - because it focused on important stuff and getting job done, not theory that looks only nice on paper, but doesn't match how hardware (and generally the world) operates. Real stuff is mutable. Not being able to mutate stuff in Haskell directly is a productivity killer. Many of the "abstractions" you can build in Haskell exist solely to workaround this limitation.

Exposure has nothing to do with this. Rust is new and Haskell is since forever, yet Rust already far surpassed Haskell in terms of adoption.

Not all OSes are written in C, thankfully a couple have moved into C++.

Template Haskell is not standard Haskell, it is an extension. But even with it, Haskell type system can't reason about lifetimes of objects. It doesn't give any guarantees about object destruction nor even object construction, due to laziness. Hence, you can't prove anything about resource usage of a Haskell program. Which makes it usable only for cases where you don't care about resources and where the program doesn't interact with external systems.

Well Haskell's prelude is purposefully small and extended by a variety of extensions in the GHC. Prelude + libs + extensions effectively make what we call Haskell today.

Just like with Elixir and many other high level languages I don't think it's meant for building low level systems where you're heavily constrained by resources.

But why wouldn't it be able to interact with external systems? I'm not having any problems building an API that interacts with a database, caching layer etc.

Bartosz Milewski's blog is a source of knowledge about Haskell and how to apply that knowledge in C++.

https://bartoszmilewski.com/2014/10/28/category-theory-for-p...

Sure, I didn't say "useless". The post I was responding to was worded in such a way as if FP was the only suitable paradigm everybody should be using. FP is a nice and useful abstraction, but in some areas it is just too inefficient and despite all the great compiler progress of the last decade, it is still not there yet.

FP languages are not in the same problem domain as system programming languages, so claiming FP should replace Rust is just ridiculous (and as a side note: Rust borrows many things from Haskell/Scala as well, so some FP is there).

Swift is replacing Objective-C (a systems programming language a dialect of C). So indeed it is a direct competitor to Rust as it also provides hardware abstraction in a safe manner to replace C dialect.

I will wait and watch when Rust will be used to control Apple or Android hardware as performant with similar safety guarantee like Swift or now Kotlin.

It's also same as C++ used by Microsoft to provide underlying abstraction of hardware on Windows.

Kotlin and Swift fall short on memory management and both need runtime and GC. Currently Kotlin native is an order of magnitude slower than Rust, and Swift is also losing in benchmarks sometimes by 10x (although, not always - purely numeric Swift code is the same speed, because it is going through the same optimiser).

As for hardware abstraction - not sure what is your point - Rust can use any C API.

It doesn't matter if improvements are still required, Apple is doing Swift, and Google is doing Kotlin on their mobile OSes, not Rust.

Swift and Kotlin are used for application programming there, not systems programming. Also, Google does Rust as well. And Microsoft is slowly switching some pieces to Rust as well. These are big companies with many teams and use many different tools.

Don't know how iOS, but Android does offer native APIs, so Kotlin is not the only officially supported choice there. Actually for anything that needs performance, e.g. games, Kotlin is a nogo.

Swift is used for systems programming on Apple platforms, as already replied on another thread.

Google already mentioned a couple of times at Android Fireside Q&A sessions that it is weighting Kotlin/Native adoption on Android.

And even if not, Rust isn't taking C++ and Java place on Android, specially after Project Treble changes, where drivers can even now be written in Java.

Google and Microsoft are indeed adopting Rust, with some products already in production, although they are also among the major ISO C++ contributors, so it remains to be seen how much Rust love from their security teams will spread into the OS development teams.

For example, I still look forward to the day that Azure Sphere actually offers something else other than C, in spite of its security sales speech.

I would put it in another way, Rust is not a competitor to Swift on Apple's ecosystem.

Apple is not adopting Rust to replace their C and Objective-C code, rather Swift, as they quite clear mention on the Swift documentation.

> Swift is a successor to both the C and Objective-C languages.

https://developer.apple.com/swift/

> Why can’t cargo be simple enough like pypi where all the dependencies are in intranet and private or another way is all the dependencies are in my own simple folder and can update it separately whenever I need rather than relying on an internet connection.

It does have registries[1] and vendoring[2].

[1]: https://doc.rust-lang.org/cargo/reference/registries.html

[2]: https://doc.rust-lang.org/cargo/commands/cargo-vendor.html

> you only need to audit those specific parts because everything else is safe by default

This deserves clarification. You only need to audit those specific parts because everything else is safe IFF those parts are safe.

> I think Rust gets a lot of hype because it's syntax is complex

Rust syntax is simpler than C++. Rust is a much smaller language. To me it appears much more like a mixture of C and Haskell, rather than C++.

What on earth did Rust copy from Python, toolingwise?

Just based on what I see rustfmt is copied from gofmt which borrowed it from Python. Cargo is just another pypi with certain improvements.

Rust RFC's process is also from there.

Hopefully rust can have something like PEP-8 in Python to inculcate habit in programmers to write beautiful readable code.

Eh, what part of gofmt is borrowed from python? Python hasn't even bothered to have all parts of its standard library formatted to follow PEP-8..

As for pypi, it is Perl that (as far as I know) invented language specific packaging. Then Bundler, a Ruby project took and improved the situation and let people easily create repeatable and predictable installs. Some of the people behind Bundler then went on and built Cargo. Packaging for Python is and has always been a mess, which people shy away from rather than copy. There are some signs of improvement in later years, but it is not from pypi.

As for RFCs, I would assume the RFC process should reasonably be attributed to IETF. They were a bunch of decades ahead of Python there..

> So if you use either modern incarnation of C++ or Rust, you will get same safety guarantees. Just with C++ you will not have to climb the mountain of learning just to do simple things.

This is absolutely, completely wrong. If you want to write safe C++, you must follow a very strict discipline, essentially equivalent to appeasing the Rust borrow-checker. The main difference is that straying from this discipline in Rust leads to a compile-time error, while straying from this discipline in C++ leads to unsafe, but probably working, code, that you will only discover is unsafe after much work.

And in both languages, you sometimes need to drop from the safe subset to do some things. In Rust, that is signaled explicitly with `unsafe`, in C++ it just means using more C-like constructs.

It would also be very interesting to see what subset of modern C++ vs Rust could be used for safety-critical code. Given that several C++ idioms like RAII depend to some extent on exceptions, and those are not permitted in safety-critical code (per Bjarne's own standard), I would not be surprised that Rust will become very attractive in this sector once it matures.

You can get the compile-time error when using tooling like Visual C++, or Eclipse CDT with static analyzers turned on.

Not for all the things that Rust catches. And not for the most important things.

Static analyzers typically catch trivial stuff like returning a pointer to a stack from a function. Which is easy to spot during code reviews. But they don't catch more sophisticated UB that can result from bad interaction of code in different units. And this it the kind of UB we're the most interested in being protected from.

If you mean lifetimes, yes you can, with the latest Visual Studio 2019, although it is WIP.

And compiling in debug does enable bounds checking for arrays, vectors and iterators invalidation.

Rust still needs to define what actually is UB in unsafe blocks, how multiple implementations might affect the language and a memory model.

Not saying that it is perfect, rather that it can be made safer than how many make use of it, which is important, because there are plenty of codebases out there that will never get rewritten into something else.

In C++ lifetimes are not encoded in types. Therefore I seriously doubt it can do the lifetime analysis with such accuracy as Rust can, particularly if the whole source code (e.g. libraries) is not available.

> C# and Java are not it.

This needs elaboration. Those languages pretty much are the canonical example of "not a great language, but stellar and unmatched tooling".

Unfortunately I was pretty confusing. The G-GP had said 'imagine how much worse other languages are', and I was pointing out that I don't know which those other languages with worse tooling are. That phrase was meant to say 'Java and C# are obviously not languages with worse tooling'. That is, I agree with you, and considered it obvious that Java and C# have stellar tooling.

> not a great language

it really depends on how you define a great language. btw. C# can do everything that golang can, but has a different inheritance interface. Also C# has some stuff that golang does not can, like an easier way of working together with C++.

Btw. Java is nearly in the same boat. It has a different inheritance interface and can nearly do all things that golang can (except maybe csp/channels and can not be as memory efficient than C# and golang). But the point still stands. Golang basically can do less than both.

I remember using a 4 year old programming language on the JVM. When you installed the Eclipse Plugin you could do all the code navigation, refactoring, etc. This was a custom written plugin specifically made for this programming language so it didn't really take advantage of copying the Java plugin and extending it. It also had a fully fledged package manager, build system, code formatter and all the fancy bells and whistles. The tooling was amazing and it shows that whether tooling for a given programming language is good or not merely depends on how much the community values good tooling. Especially in python the community gives a crap about good tooling. There is a lot of tooling with which you can cobble something together but it never leaves you feeling that it was worth the time investment or that the solution was particularly elegant.

Deploying applications is a problem on which most people just give up and just ship a virtualenv to production... or they waste a week on finding a better solution. One might argue that this one week will save me time in the long run but then you start thinking about all the python programmers who don't give a crap and they clearly don't want to invest that week worth of time and so the cycle of bad tooling continues.

Actually I do 100% automated deployments with Ansible roles. I don't use the ansible commands though, I wrapped it in my own command which fixes all my problems with ansible: https://yourlabs.io/oss/bigsudo

My roles: https://galaxy.ansible.com/yourlabs/

I'm extremely happy with it. Currently I'm writting my own Docker/Compose on top of podman and buildah in order to remove all `Dockerfile.` and `docker-compose..yml` from my projects in favor of a single pod configuration file, which can variate depending on a "profile" (default, dev, prod, review...). Once that is solved I will continue my life with 100% satisfaction of the tools I use for my CI and deployments.

But yeah, prior to going crazy like that and rewriting the world, during years, I was actually doing my best to not invent new tools, and get the best out of every tool that was out there, I can easily imagine that's how most people would practice their craft, by just focusing on what they are supposed to ship, considering that "if I could make a better tool for that then somebody else would already have, so I'll just use anything and not really bother, perhaps try to contribute or wrap in bash scripts".

Does bigsudo have a license? I admit I only glanced quickly, but I didn't see one in the repository.

GoLand solves many problems though, for example they have conditional breakpoints and function execution in debugger (though not that powerful). And code refactoring/navigation is also pretty good.

In my experience, the debugging story isn’t as bad as most think, because compilation times are so fast. If I need to run some code at a random location to see what’s going on, I just add it and rerun the unit test, usually it takes less time than configuring a debugger to do the same thing, and I’ve also now got a place to put a UT to cover whatever the problem was.

Edit-compile-rerun is as fast or slower in Go compared to Java, C#, Python, Ruby and many others, and it's still an option in those languages. Comparing to C, C++ or Rust, or, surprisingly, JS, instead, you're probably right.

However, unit testing is not by any means a substitute for all uses of a debugger. You can add unit tests to reproduce an error in any language, but once your problems start crossing module boundaries, a debugger (or printf debugging at least) often becomes indispensable. And having an edit-and-continue debugger is extraordinarily helpful when dealing with bugs that only reproduce in complex application states (when your cycle becomes edit-compile-rerun-send50CommandsToPutAppInCorrectState-reproduce).

Refactoring is a bit more advance than just renaming though. gofmt can transform one pattern to another. https://spf13.com/post/go-fmt/

I wonder what the future of package management will be. The author of the Node-revamp language Deno (https://deno.land) chose to basically follow a strategy not unlike Go and forego package.json and similar dependency manifests, while also adding things like explicit network access flags to prevent, I believe, NPM-type package hacking vectors.

I just don't see what deno is going to build with access flags that couldn't be solved by writing off local code and wrapping everything npm does into containers.

There's nothing special to install in linux for a long time to use containers and once WSL2 is done, if it's made available to all windows either that or native containers it can just be the way npm works, managing containers.

Agree with a lot of that especially this part:

> Major version changes require source-code level changes in all files touching the package

I've always thought the tooling was half baked but would get there eventually. The introduction of modules has caused a split and put the tooling either further behind IMO.

Pretty sure `go guru' satisfies reference finding across modules/packages and finding all implementation of an interface. It is slow because go guru (and gorename) needs to search all packages in modules and GOPATH but it is also correct.

Go also doesn't compile as quickly as people make you think. A regular sized project will compile more slowly than a similar sized c# project.

Do you compare it with C# AOT compilation?

Why would you?

Because compiling to executable machine code and compiling to abstract high-level bytecode is a completely different things.

It's part of Go's typical "we assume/declare that we do better/simpler without checking what/how other languages do" schtick.

Take error handling and package management for example - different approaches, hacks piled, etc, instead of just going with the program, seeing how others do it successfully (e.g. Maybe/Optional error, exceptions, etc), and get on with it...

Do you think Go's developers and users are simply unaware of exceptions, optionals etc? Or is it that the trade offs that they made aren't net positive for most use cases? Even if the second was true, that isn't necessarily a bad decision; since C# continues to exist, there may be more use for a language targeted to some niche than just a copy of C#.

I've used C# and Go extensively and like both languages. In some big ways they are similar: garbage collected, (fairly) fast compile times, large ecosystems, good tooling (if you include the JetBrains tooling for Go), built in lightweight concurrency, etc. It's not surprising people compare them.

For the areas where they differ, Go in general is more explicit and more low level. Handling errors as return values instead of exceptions is more typing, but I find it easier to check that error handling has been done correctly in my own code and in third party libraries. Instead of the class/struct dichotomy pointers are explicit and any type can be used as a value type (there's also more flexibility in using Go types with unmanaged memory, and the ability to take interior pointers). The way interfaces are implemented they can be used in more places without boxing.

C# has generics but I've run into frustrating limitations with them, for example not being able to write numeric code that works with either 32 bit or 64 bit floats. Go's generics are currently limited to some built in types but the proposals being iterated on seem like they'll be more useful to me than C#'s implementation if they make it into the language.

Other things: Go has a single concurrency story so the ecosystem isn't divided into sync/async worlds, is a less complex language overall, and is a bit less verbose aside from error handling (no public static void etc). Overall I probably prefer Go, but I like C# also and could easily imagine projects where it might be a better choice especially in areas where the lower level aspects of Go aren't useful.

Reading HN, it seems like a lot of people believe that people who use Go (and even the language designers) are simply ignorant. I'm open to the possibility, but can you flesh it out for me a little bit more? What am I missing here?

Proof? have you tried to compile Kubernetes and compare that to a 1M lines C# project?

> No way to automatically find all implementations of an interface - especially problematic in a language with implicit interface implementation

C-c C-o-i (go-guru-implements)

Go guru is extremely slow, go pls is faster but doesn't implement this (yet, hopefully).

Having multiple incomplete tools that do the same thing in the official tooling is another problem with Go tooling.

Yes it's always amazing how these new environment skimp on debugging support. After all that's the activity most of us doing real software spend the most time on, and no, no amount of "safe programming" will avoid debugging. I guess debugging is just not cool.

Agree!

> Coming from the C# and JVM

Not that I disagree with you but comparing C#/JVM to go is like comparing a commercial airliner to a single seat monoplane. These projects are diametrically opposed from the get go in every way I can think of.

There are only two languages I ever liked working with C and go. Because they're simple, full of compromises, but simple. I can't say that of C# or java, you probably need a PhD just to be able to use 1/3 of c#/java tooling and IDE features.

> I can't say that of C# or java, you probably need a PhD just to be able to use 1/3 of c#/java tooling and IDE features.

That is absolutely incorrect. The whole point of having tooling at your disposal is to make the process of writing and reading code dead simple.

Ypu don't need a PhD to pause the debugger, edit some code, hit continue, and have the new code executing. You don't need a PhD to select some text, click Extract Method (or press the shortcut), type in the method name, and have the new method/function on the screen.

By the way, C has excellent tooling on all of these sides as well - C IDEs and debuggers are extremely powerful, unlike Go.

Yes, _commercial_ C (an Java) IDEs are extremely powerful, but it's a bit unfair to compare them to _open source_ Go IDEs/editors. From what I heard, the only commercial Go IDE available so far (GoLand) is extremely powerful too...

Not that I buy this argument in the slightest but:

https://code.visualstudio.com/docs/languages/csharp

(Are you going to say, it's unfair to compare something with the commercial backing of Microsoft, because Google backs Go)

>because Google backs Go

The degree of backing is completely different though. They appear to only do the minimum effort that they need for themselves. Microsoft provides good C# tooling because they want you to stay in the Microsoft ecosystem.

They want you to stay in the Microsoft ecosystem is why they made an open source IDE and great tooling for it that competes directly with an IDE they sell for up to 1000$/seat/year that actually tries to get you to stay in their ecosystem with things like free Azure credits, preferential Azure pricing, free Windows Server and MSSQL licenses

Not that I think any of this is not entirely tangential to the original point...

Eclipse is far more powerful of a C and Java IDE than any non-commercial Go (I)DE. NetBeans is also a great Java IDE. They're not as powerful as IntelliJ or VS, but they are still miles ahead of any Go plugin I've used.

Also note, for C you have gdb, you have ctags, you have all sorts of great plugins for Emacs or Vim or whatever. You also have stellar plugins for Javascript and TypeScript, for VSCode, for Emacs, for vim and many others.

I'm not just comparing VS with vim+go plugins.

Can't agree here. Go is going for simplicity of the language but definitely not for simplicity of tooling. If anything, I would say golang tooling is more complicated then c#, with all that myriad of small tools. Debugging story is just objectively better in c# and it's pretty easy to use.

Reply on news.ycombinator.com