mattetti

Series of modular synthesisers produce real-time audio, minimising memory load. Miniature speaker is acoustically tuned through internal air spacing to amplify and clarify sound within the LEGO SMART Brick’s enclosure. Responsive audio effects are tied to live play actions; there are no pre-recorded clips.

Very interesting!

The Unreal Engine editor also uses the UE engine which is pretty cool (but I wouldn't recommend writing desktop/mobile apps in UE)

Adding more context: Fluid uses a mix of CRDT + OT to maintain state across multiple clients. I wrote a quick high level explanation of how Fluid uses eventual consistency and why it matters for real time collaboration: https://matt.aimonetti.net/posts/2020-09-solving-real-time-c...

Elm has a low entry barrier

Sorry Vincent, you lost me there. Elm is interesting for sure, but it's far from having a low entry barrier. Something has basic has having a button play a sound takes forever to figure out. You almost have to learn everything all over again. It's a cool project and I'm glad it's working out well for you, but Elm has a serious learning curve.

Same as Tom for both TypeScript and Go. Can't be happier (I don't use the vim plugin tho, even tho I was a vim user for many years)

167912 LOC

Thanks to the Go team, getting such an improvement without having to do anything is awesome. And I can't believe there is more coming in 1.8

The faster compilation time & speed up is quite real in our real life prod application.

From Go 1.6 to 1.7: Test suite (CI), from 3:34 to 1:48 Docker image building, from 3:05 to 1:50

https://twitter.com/mattetti/status/763913903600349184

yes buffered io, you use readers to read/write small chunks at a time instead of loading everything at once. Go offers way to do both since in some cases, such as loading an entire file in memory can be fine/better/faster.

We've been running splice.com on Go for 3 years now and handle 5TB of audio/binary data per day. Our memory usage is around 10-15MB per server and the GC pause time has been really low. You do need to stream your IOs instead of reading everything in memory. In regards to dependency management, we honestly had no issues and now with vendoring, it's even easier. We do use a main repo with lots of smaller packages and only a few 3rd party dependencies that are vendored or available via private git repos. We don't use Google cloud but I heard they have 2 repos, one that has auto generated code and one that has hand written code (but less complete).

the main changes are related to the SSA compiler backend and smaller binary files. 1.7 should also better support binary only packages (so vendors can sell compiled packages without providing sources, it kinda works right now but was hacky/buggy).

Stability increases, in our case, we just update Go on our CI and we get smaller binaries, better performance as updates come in. The code is always backward compatible so our code always compile. We obviously make sure our test suite passes and don't see any regressions. It was nice to get http/2 for free in a recent update, especially with cloudFlare now supporting http/2 push.

Progressive switch, we use TypeScript for new code and everything we touch old code, we try to convert from JS to TS. The tooling is amazing, even the skeptics in the team wouldn't go back to js now. Defining interfaces, using types really reduced the feedback loop and sped up our dev time. The one thing that is wish is that templates could verified by the compiler instead of waiting for runtime (react uses views written in code and therefore you get that for free when using react + TS)

We've been slowly migrating https://splice.com from Angular 1 to Angular 2, so far it's been great. We switched to TypeScript, we cleaned up our code organization. We are writing new components in ng2 and migrating old code we we go. The betas have been somewhat painful with bugs and breaking changes, but that's the price to pay. When it comes to performance and consistency, ng2 is a big winner. Why not React you might ask? React is great, but having to figure out/argue for each piece of the frontend stack isn't something we were willing to do. ng2 has its quarks bug at least it comes as a whole and that's super useful for us at this moment.

Did the compiler get even slower on tip? I know that was a concern with this change

Made using a mix of Angular 1 and 2 + TypeScript and a WebAudio engine we wrote also using TypeScript. It's powered by Splice Sounds library and meant to showcase the service and be a fun web app for desktop and mobile!

This is a fun project, I'm looking forward to seeing how far you can take it. One thing to note is that Go doesn't have TCO so performance when using a lot of recursion might be pretty bad or the compiler has to be smart and use loops and states.

We updated Splice's CI to 1.5 and rolled out our code to prod. The total GC pause time improvement is quite drastic for us: https://twitter.com/mattetti/status/634114976362291200

Throughput hasn't changed and average performance is about the same for us (slightly faster actually)

Since my free/open source ebook didn't make the cut, please excuse the self promotion: http://www.golangbootcamp.com/

I hope it will help some of you :)

Splice is in Santa Monica (West LA, by the ocean), most of the team walks or bikes... and we are looking for an iOS dev, feel free to drop me an email if interested (matt at splice.com)

Splice | Santa Monica, CA | JS developer - iOS/OSX developer

Splice is rapidly changing the world of music by offering free cloud version control, backup, collaboration and distribution to artists. Our backend is in Go and our frontend is JS (Angular) and our apps are in ObjC and C#. We are looking for a talented JS developer and a passionate ObjC/Swift developer to join the team and help us shape new user experiences for musicians.

https://jobs.splice.com or email me, matt+hn@splice.com

Extremely talented team, ocean view, adjustable height desks and a bunch of really awesome office perks (daily awesome breakfast being one of my favorites).

Excuse my pedantry but these aren't technically memory leaks, great article nonetheless :)

Go challenge author here, really glad to see this post and a great read for Go and not Go developers.

Java is totally fine, just not a language I expect the fancy HN crowd to pick for a programming challenge (Note that I also didn't mention Python, C# and plenty other good languages).

Awesome story thank you so much for sharing!

We don't actively advertise this position, maybe we should. You or other candidates should feel free to contact me at matt/at/splice.com and dont forget to attach your challenge solution.

Yes Splice uses Go for everything backend related (web APIs, file parsers/decoders, audio processing) AngularJS for the frontend, ObjC & C#, C & C++ for native desktop/mobile apps.

We are always looking for talented backend engineers to join our exceptional team.

Challenge author here. There is nothing Go specific to the challenge itself. I really want to encourage everyone to try solving the problem. If you don't like, know or care to learn Go, try solving the challenge using Rust, Ruby, Scala, Elixir, JS, Pascal, asm or whatever language you want to play with.

While only Go submissions will be evaluated and rewarded, I would personally be glad to look at solutions written in other languages.

The way I will always remember Ezra: https://www.flickr.com/photos/adelcambre/2932034431/in/photo... (MerbCamp, 2008)

I see that as a good problem to have, if Exercism gets big enough that it's an issue Katrina will be able to adapt her product to respond to the request.

Remember that this is a side, open source project, run by one person ;)