Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why We Switched from Python to Go (2021)

softwareengineeringdaily.com

Post reply on HN
Print view View original

291–300 of 301 posts

Re: Why We Switched from Python to Go (2021)

#291

Post by s17n »

dgb23 wrote: post #238
AnimalMuppet wrote: post #222

Earlier quoted context omitted.

I disagree. If you're managing programmers, you might be expected to have a bit of a clue about programming languages. If you can't tell how easy it would be for your people to pick up Go versus how easy it would be to pick up Lisp, you have no business managing programmers.

Well you can still manage programmers but you certainly shouldn't micromanage their technological choices then.

You can argue about whether enforcing language consistency across an organization is a good idea or not, but it isn't "micromanagement".

Re: Why We Switched from Python to Go (2021)

#292

Post by jvolkman »

0x008 wrote: post #246
jvolkman wrote: post #197

Earlier quoted context omitted.

In that case it seems like you could just have one all_requirements.txt that includes the individual files like: -r package_a/requirements.txt -r package_b/requirements.txt etc.

yes I get it. Good point. Is bazel also a good choice for managing the virtual environments of my developers? Do you have any examples?

At this point I would say no, but work is in progress to improve in this respect [1].

At my place of work we use some rules [2] to build virtual envs from Bazel dependencies. It's been a great stop-gap for us and allows us to use traditional Python tooling (e.g. PyCharm) with Bazel-managed dependences.

[1] https://github.com/aspect-build/rules_py [2] https://github.com/cedarai/rules_pyvenv

Re: Why We Switched from Python to Go (2021)

#293

Post by radicalbyte »

haihaibye wrote: post #251
bloblaw wrote: post #180

Earlier quoted context omitted.

Go debugging is nearly the exact same experience as Python. GoLand (from JetBrains ... same folks that make Pycharm) or VSCode with delve debugger work flawlessly. I don't think there is any difference between Go and Python when it comes to debugging. Support for both is widespread and high-quality.

The post you replied to mentioned an interpreter. Does Go provide an interactive REPL?

You don't really need a REPL with an IDE, you have excellent auto-complete which shows you the API (which is what I use the Python REPL for) and are unless you're writing pure framework code (or mapping etc - in which case integration testing gives more bang for the buck) then you're probably writing unit tests. I use a continuous test runner for those as the feedback is amazing.

Re: Why We Switched from Python to Go (2021)

#294

Post by tasuki »

MathCodeLove wrote: post #288
tasuki wrote: post #287

Earlier quoted context omitted.

> Maybe go is faster than any other language they've used? Quite possibly! That would be consistent with my point that they chose Go for practical reasons, rather than to learn for the sake of learning, as KaiserPro was suggesting. If you want to learn for the sake of learning, you'll learn a different paradigm, rather than rehash the same thing with a slightly different flavour. Also probably your productivity will…

Can it not be both? Someone can want to learn for the sake of learning, and then filter further using practicalities. I'd love to learn every programming language out there, but it wouldn't be possible, we only have a limited amount of time in this life, so I'll instead learn the ones that are the most practical to learn. Java, however practical, may not be interesting to me so I may not learn it. Piet is super inter…

Yes it can very much be both! Or even more reasons, as you say.

The original comment I was replying to said their reason was "I just wanted to learn a new language", which is what I disagreed with.

Re: Why We Switched from Python to Go (2021)

#295

Post by theshrike79 »

gkop wrote: post #157
sliken wrote: post #147

Earlier quoted context omitted.

Go has one, the same one used by the compiler, so there's no arguments, no multiple standards, etc. Python has a few options, and when a new language feature comes out the time to implementation may vary. Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed? Generally in the go community, contributions, patches, code, etc that's not f…

Thanks! More curiosity: How do humans that disagree with the One Format deal with it? Do they self-select away from Go? > Think of it this way, if you could all the python code on github and ran it though autopep8, what fraction of the files would be changed? How does the format evolve over time as the community discovers improvements (if it does), and what are the implications for code on github?

"Gofmt's style is no one's favorite, yet gofmt is everyone's favorite." - Rob Pike

This pretty much sums it up. Gofmt isn't perfect, but everyone uses it and deals with it. It's included with the language so there's no point in trying to create a "competitor".

Re: Why We Switched from Python to Go (2021)

#296

Post by theshrike79 »

gkop wrote: post #244
prepend wrote: post #240

Earlier quoted context omitted.

I’ve found it’s nice for detecting people who care about unimportant things. I can’t imagine ever picking a language based on this feature and seems weird to even mention it. This has never caused me a minute of headache and the only time I care is when conflicting styles are used in the same file. I always thought it was kind of dumb of Go to care about this but don’t care enough to affect my language choice. I don’…

In candor I dabbled in Go in 2016 and found the community leaders arrogant and rude. I hope the community has evolved since then to expect more from leaders, but would need to see evidence of this before touching Go voluntarily again.

I've used a good dozen languages and I don't know the "community leaders" of any of those.

Re: Why We Switched from Python to Go (2021)

#297

Post by MathCodeLove »

tasuki wrote: post #294
MathCodeLove wrote: post #288

Earlier quoted context omitted.

Can it not be both? Someone can want to learn for the sake of learning, and then filter further using practicalities. I'd love to learn every programming language out there, but it wouldn't be possible, we only have a limited amount of time in this life, so I'll instead learn the ones that are the most practical to learn. Java, however practical, may not be interesting to me so I may not learn it. Piet is super inter…

Yes it can very much be both! Or even more reasons, as you say. The original comment I was replying to said their reason was "I just wanted to learn a new language", which is what I disagreed with.

Fair enough!

Re: Why We Switched from Python to Go (2021)

#298

Post by Tozen »

bloblaw wrote: post #206
didibus wrote: post #200

Earlier quoted context omitted.

Ya, and if you look at the language space, there's nothing else that offers #1. That set of features isn't related to the language itself (though the language was designed to allow those features). This is where Go is appealing, it's not the language itself, it's the properties it brings with it. Cross-compilation, multi-spec, reasonable performance and low memory footprint. Single binaries. And I'd add fast compilat…

That's a great point, and one I hadn't considered. One language feature that Go brings is first-class multi-threading and communication amongst and with child threads. The only languages I know that can compete with Go with similar properties are Nim, Zig, and Rust. I'd like to include Delphi / Free-Pascal, but cross-compilation can be a bit of headache at times.

Well, when it comes to cross-platform desktop apps, Lazarus (Free Pascal) and Delphi (payware) do very well. There is nothing in Nim, Zig, Rust, or Go that I know of that can compare to the Lazarus or Delphi IDEs (for Object Pascal). As a matter of fact, there is an effort among Golang users to copy Lazarus. But, for Lazarus and Delphi, things get a bit shaky when we start talking about mobile or desktop and mobile development.

Delphi incorporates a mobile solution that was bought for the purpose, called FireMonkey, that doesn't completely integrate with their desktop solution (VCL). Each new version of Delphi is making progress with integrating the different solutions more tightly, but we are still talking about payware that is priced above what most individuals would want or feel comfortable paying for.

Lazarus, for various odd reasons (or even suspicious reasons), their developers appear to be dragging their feet with making a mobile solution. They should be able to incorporate technologies such as OpenGL ES with LCL and their custom drawn interface, but don't. A 3rd party developer came up with their own solution, that works for Android only (LAMW), but doesn't integrate with the desktop solution (LCL) nor is a part of Lazarus. So for Lazarus, outside of desktop development, things get a bit confusing. However, if team Lazarus ever got their act together and took mobile development more seriously, they probably would have among the best solutions out there.

Re: Why We Switched from Python to Go (2021)

#299

Post by [deleted] »

theshrike79 wrote: post #296
gkop wrote: post #244

Earlier quoted context omitted.

In candor I dabbled in Go in 2016 and found the community leaders arrogant and rude. I hope the community has evolved since then to expect more from leaders, but would need to see evidence of this before touching Go voluntarily again.

I've used a good dozen languages and I don't know the "community leaders" of any of those.

[deleted]

Re: Why We Switched from Python to Go (2021)

#300

Post by haihaibye »

radicalbyte wrote: post #293
haihaibye wrote: post #251

Earlier quoted context omitted.

The post you replied to mentioned an interpreter. Does Go provide an interactive REPL?

You don't really need a REPL with an IDE, you have excellent auto-complete which shows you the API (which is what I use the Python REPL for) and are unless you're writing pure framework code (or mapping etc - in which case integration testing gives more bang for the buck) then you're probably writing unit tests. I use a continuous test runner for those as the feedback is amazing.

API autocomplete and unit tests are not a replacement for a debugger, it's a separate use case.

Being able to evaluate code while in the middle of a breakpoint is extremely useful.

You don't need to say it doesn't matter. Your language has features Python doesn't have, there can be tradeoffs

Post reply on HN