Live data from Hacker News

Open-sourcing Sonar, a new extensible debugging tool

code.facebook.com

41–47 of 47 posts

Re: Open-sourcing Sonar, a new extensible debugging tool

#41
post #39
post #38

Earlier quoted context omitted.

It's right there in the first paragraph: > With Sonar, engineers have a highly flexible, intuitive way to inspect and understand the structure and behavior of their iOS and Android application ...and the top of the post is tagged as "Mobile", "iOS", and "Android".

I think he meant appending "for mobile apps" in the title instead of burying key constraint in midst of wordy paragraphs. There is quite a distance between clarity and fine prints.

Sure, but it's not accurate to say

> I had to wait for the third section, not very helpfully titled "An open source architecture", to find any clues.

Re: Open-sourcing Sonar, a new extensible debugging tool

#43
post #29
post #25

Earlier quoted context omitted.

There was also another language called Go beforehand: https://github.com/golang/go/issues/9

Golang is the worst because there is already a very popular game called Go. That's why I always call Golang Golang and not Go.

And for Swift, there are Swift Messenger and SWIFT code.

1. https://swift.org 2. https://swift.im 3. https://www.swift.com

Re: Open-sourcing Sonar, a new extensible debugging tool

#44
post #7

The attached video only supports mono audio in the left channel. Evidently no one involved in this release process listened to the video with headphones. Stuff like this is always humbling to me, that you can have a big release with dozens of people involved yet mess up something simple.

Sorry about that, it has now been fixed

Re: Open-sourcing Sonar, a new extensible debugging tool

#45
post #32
post #15

Congrats, Emil and team! I'm most excited for this as an extensible platform for further desktop tools, built on FB's robust stack of front-end tech. Although I must admit, I'm disappointed that they didn't use react-native-web to build this app in a cross-platform way. I agree Electron is a good choice for the current landscape, but I'm hopeful that we will be able to move past it. If Sonar was implemented with Reac…

what about linux users? Like I get that people don't like Electron because of it's resource heavy nature but it's been a boon to us Linux users who have finally been getting a lot of cross platform apps and I truly appreciate that. getting a Mac is generally not an option - it's too expensive just for a few GUI apps (and overall pushes the bar of development quiet a bit higher) and in all honesty, it's not great for…

Gtk+, Qt, wxWidgets, JUCE, Eto, ....

There are quite a few options without packing a browser engine with the application.

If that is the only way to get applications on Linux, then we should just all move to ChromeOS and dump the Linux desktop attempts as is.

Re: Open-sourcing Sonar, a new extensible debugging tool

#46

Earlier quoted context omitted.

Glad to hear the tool works well for FB employee's. As always the contribution to the community is much appreciated. But as others have pointed out, the tool name could use a rebranding. The popular SonarCube is just one example where confusion can arise.

Seems FB has a pattern of releasing open source projects that have naming conflicts. Another example: yarn

Looks and sounds very much like 'yawn'.

Re: Open-sourcing Sonar, a new extensible debugging tool

#47
post #13

I agree unique naming is one of the fundamental pillars of modern coding , or else we would have chaos with stupid generic completely unrelated names like Python, C, Java, Go, Swift, Ruby, Assembly, Basic, JavaScript ... It would have been chaos. Obviously none would like that, would they ?

Those are arguably some of the best examples of software naming and branding done right, with the notable exception of JavaScript, which isn't unique or accurate. Sonar would arguably make a bad name for anything that isn't underwater SOund Navigation And Ranging.
Post reply on HN