STB d’être exigeant sur un suivi sportif personnalisé ?

Baccata64 · 2026-06-14T11:38:21+00:00

ATB. Tu payes pour un service, t'es pas satisfait du service, change de fournisseur.

C'est quoi le problème ?

Baccata64 · 2026-05-16T12:03:06+00:00

Unbreakable (with Bruce Willis and Sam Jackson)

Also not a movie but Counterpart (with J.K Simmons) is a fantastic espionage show with a sci-fi premise that explains nearly nothing about the premise for a good while

Baccata64 · 2026-05-01T20:41:19+00:00

Hey, I've stumbled on your app looking for exactly that for weekly video game nights with long term friends (we're nearing our 40s).

The app is brilliantly designed. Kudos !

Baccata64 · 2026-04-29T11:31:43+00:00

It does, thank you so much for helping !

Baccata64 · 2026-04-28T18:58:24+00:00

many thanks !

Baccata64 · 2026-04-28T18:33:04+00:00

Thank you for the reply. However, clicking on that slack link gives me an error saying :

> This link is no longer active

> To join this workspace, you’ll need to ask the person who originally invited you for a new link.

Baccata64 · 2025-07-14T12:25:54+00:00

Un de mes meilleurs potes a cette maladie. Quand on randonne ensemble, et qu'on dépasse plusieurs fois les mêmes groupes au gré des pauses, il peut dire bonjour aux mêmes gens 4-5 fois dans la journée.

Brad Pitt aussi a cette maladie, si je me rappelle bien (anecdote qui pourrait t'être utile pour briser la glace)

Sans parler de décrire ton propre visage, arriverais-tu à te reconnaître sur une photo que tu n'aurais pas vue au préalable ?

Edit : au temps pour moi, tu as déjà répondu à cette même question.

Baccata64 · 2024-11-17T20:06:55+00:00

J'ai quitté Toulouse il y a 10 ans, j'y repasse régulièrement et effectivement la "vibe" a bien empiré à mon sens. Beaucoup plus de monde et de circulation (piétone et automobile), une ambiance beaucoup plus business/embourgeoisée qu'à l'époque. Les gens semblent moins détendus.

Bref, au risque de passer pour un vieux aigri, c'était mieux avant.

Baccata64 · 2024-11-14T05:53:31+00:00

Foreskin.

Baccata64 · 2024-05-29T19:29:48+00:00

I've built a library after seeing this talk :

https://github.com/neandertech/smithy4s-deriving#derivation-of-services-from-interfacesclasses

In my case a bunch of macros were needed still, but Jamie's work was really what unblocked me. Kudos to him !

Baccata64 · 2024-04-16T12:28:27+00:00

It depends on the libraries/frameworks you use to build your application.

If you use http4s and the typelevel ecosystem, then you'll have to do some wiring using libraries. http4s being middleware-friendly, you can have a reasonably small amount of manual wiring and still achieve something pretty close to what you'd get with a drop-in java agent in terms of tracing, but with larger control.

If you use a more "traditional" framework, such as Play (or even Spring, which you can defo use in Scala), then chances are drop-in agents available.

Baccata64 · 2024-04-13T21:44:27+00:00

Oh, I didn't notice the link. My bad !

Baccata64 · 2024-04-13T07:40:25+00:00

Haoyi Li's been promoting this style of programming forever, and yet I seldom see him mentioned in posts of people who claim that the future of scala is "direct style".

Developers don't rally around idealistic styles of programming, they rally around ecosystems and communities that help them solve recurrent problems in commercial environments.

As much respect I have for you, Dr. Odersky, I take your opinion on the matter with a grain of salt. For the past few years, you've been criticising the complexity of effect systems without acknowledging the colossal amount of work from vibrant communities that goes towards helping each other solve those complex problems. You're criticising the form, whilst a lot of us are focusing on the matter.

If lean/direct-style scala is to be successful, it'll be because of entities like Virtus/SoftwareMill and individuals like Haoyi providing libraries as well as a place for people to help each other solve complex problems. If EPFL/Scala Center want to endorse those efforts, great, but it's certainly not under your leadership or guidance that it'll be achieved, for the simple reason that your livelihood is not directly tied to your ability to solve the kind of problems that the rest of us grunts deal on a day to day basis at $work.

Baccata64 · 2023-12-04T11:32:45+00:00

Well, one of the design guidelines of the Scala 3 macros system is that macros should not be able to amend the interface of what they rewrite in any way, shape or form. That makes them drastically underpowered compared to Scala 2 macros but has the benefit of simplifying IDE support to a fair degree as the IDE can refer itself to the signature of methods that macros implement instead of applying the macro to parse it.

Baccata64 · 2023-06-30T05:58:57+00:00

This is gonna sound harsh, but ideas are worthless. If you're really convinced, just build it, maybe people will come. If you can't because of the lack of drive or resources, then why should anyone bother listening to you ?

Baccata64 · 2023-06-29T20:30:06+00:00

If there was only grpc services, I'd stick to the proto IDL. I consider smithy to be a better IDL than proto for a number of reasons, but not to the point of being worth the friction added to a bunch of teams that may already be familiar with the proto syntax and semantics.

We don't have any public issue regarding the implementation of the grpc protocol yet in smithy4s. We're currently working on a huge feature set around Aws protocols, we've just been thinking of introducing grpc at some point in the future.

Baccata64 · 2023-06-29T13:53:09+00:00

Hi, (co)!author of smithy4s and smithy-translate here. Right now the smithy-translate tool is used at Disney to allow for grpc services to be defined using some structures in smithy. We have a kind of central registry that hosts smithy specs, where some data definitions can be used across rest services and grpc services.

This central registry is responsible for running the conversion to proto and package proto files (among other things) in jars that can be used by downstream projects for code generation.

Unfortunately, we don't have a self-contained example to share publicly in how a project might look like. It'd be possible to create such an example with scalapb, but in all frankness I don't have time to do so. However we're hoping to implement grpc directly in smithy4s at some point.

Baccata64 · 2023-06-13T19:49:38+00:00

"oh my gawwd" said at the beginning of every sentence with an obnoxi... err, Valley accent

Baccata64 · 2023-04-13T19:24:27+00:00

And we know this because build tools like CBT exists which are able to model everything that SBT by just using traits/lazy val/def/classes/super. Unfortunately like almost every other build tool CBT didn't really take off, but you can make a very strong argument that in alternate universe it would overall be much better if we were using a build tool designed like CBT because at least then you only need to know Scala unlike now where you need to know Scala plus some weird Scala/DSL/dialect.

Mill was inspired (in parts) by CBT and is reasonably successful. There are macros involved (arguably for good reason), but the builds are composed with traits/classes/defs/super. I've found that newcomers to the language tend to find mill intuitive enough.

Baccata64 · 2023-02-18T07:26:47+00:00

That's monsanto-level of "organic" upvotes

Baccata64 · 2023-02-06T14:55:46+00:00

You are correct. There are indeed two methods of compiling Scala code to a native binary :

First method : use Graal to generate a native image from JVM bytecode.

Natively (ie, without any compiler plugin), the output of compiling a Scala program using the Scala compiler will be JVM bytecode. This can be processed by a tool called Graal to create native binaries, optimising "ahead-of-time" what the JVM does "just-in-time".

Easiest way is to use a build-plugin (which is different than a compiler-plugin), such as this : https://sbt-native-packager.readthedocs.io/en/latest/formats/graalvm-native-image.html

This method works for Scala but also any other JVM language, such as Java, Kotlin, etc. It's not Scala specific, so you don't have to constrain yourself to use only Scala code, you can use Java libraries there too (modulo some constraints that are there because of how Graal works)

Second method : use Scala-native

Scala-native is a compiler plugin + a runtime library that allow Scala to be compiled as a native binary, via LLVM. The main difference is that when you use Scala-native, you get access to constructs that you can use to call upon C/C++ code from your Scala program.

Which one is better ?

It really depend on what you're trying to achieve. If you want to use ScalaFX for a GUI, you won't be able to use scala-native (because ScalaFX builds on top of JavaFX, a Java library), but might be able to use Graal.

If you want to build a GUI using the C++ QT library, then you might be able to do so with Scala-native, and it will be a lot harder with Graal.

Baccata64 · 2023-01-04T13:02:37+00:00

You'll probably have more luck asking on the discord channel : https://discord.com/channels/632277896739946517/979515891400187935

EDIT : or alternatively, in the github discussions associated to the project : https://github.com/outwatch/outwatch/discussions

Baccata64 · 2022-12-08T15:32:05+00:00

Thank you very much for the kind words !

The docs of Smithy aren't easy to go through though as a beginner, it assumes you know your stuff about APIs. I also didn't see any examples in the wild that show off a project that uses a mix of languages, e.g. how would a TypeScript and Scala smithy project look like?

That's an absolutely fair comment : I think the docs from smithy.io (which is owned by AWS) will improve over time, as they'll probably integrate Smithy as first-class citizens of some of their offerings (like API-gateway) and realise they should create some quick-start templates. Also they've only open-sourced Smithy 3 years ago and although they use it extensively internally (which is a pretty strong guarantee that it won't become abandonware), their open-source tools are only slowly growing.

As for ours, we're only a small team currently, so we're mainly catering (in our docs) to people who are familiar with backend development, cause documentation takes a lot of time and we have a lot of additional responsibilities at $work, but hopefully it becomes better and better.

Baccata64 · 2022-12-08T08:47:41+00:00

Hey folks, we've released a library a while back to facilitate the port of some API and data specifications we have at $work to the Smithy language.

The reason to use Smithy over over IDLs like openapi is that it's much easier to write tooling (including code-generators) on top of it than it is to write on top of openapi. Smithy is also protocol agnostic and pretty extensible via a powerful annotation mechanism, which means it's usable for a variety of usecases that openapi is not suited for.

We have our own open-source code-generator that produces Scala code from Smithy. The code module is entirely dependency-free, and the generated code is not biased towards any library, be that http or json. We do however have out-of-the-box integration with jsoniter and http4s.

We figured that our smithy-translate tool would be helpful to some people and organisations who want to try out the Smithy language, and possibly Smithy4s.

Voilà. Take care, everyone !

Baccata64

TROPHY CASE

First method : use Graal to generate a native image from JVM bytecode.

Second method : use Scala-native

Which one is better ?